What to Build for Your Internship Portfolio as a Singapore CS Student

Every year around this time I get the same message from a polytechnic or university student: "I need a portfolio for internship applications and I have nothing." The mid-year break is the window to fix that, and the good news is that what actually gets you shortlisted is more achievable, and more specific, than most people think.

What a reviewer actually does with your portfolio

Assume the person screening you has fifty applications and ninety seconds for yours. They are not reading your code line by line. They are scanning for evidence that you can build something real and finish it. That means, in rough order: a project that is actually deployed and works when they click it, a GitHub profile that is not a graveyard of half-day tutorials, and one thing that makes them think "this person has initiative."

Everything else is noise at the screening stage. A long list of technologies you have "used once" helps you less than a single working link.

What not to build

The weakest portfolio is a pile of tutorial clones: the same to-do app, the same weather app, the same chatbot wrapper that everyone submits. In 2026 this is worse than ever, because a reviewer assumes, correctly, that AI generated most of it in an afternoon. It shows you can follow instructions, which is not the bar.

A close second is the project that is huge, unfinished, and never deployed: a sprawling repo with an ambitious README and no live version. Reviewers read that as "cannot ship."

What to build instead

Aim for two or three real projects rather than ten shallow ones.

1. One small thing, fully finished and deployed. It can be modest. What matters is that the link works, the code is clean, and it is genuinely done. Finished and live beats ambitious and broken every time.
2. One project that touches real data or a real API, because wiring up messy external data is most of what the job actually is, and it shows you can handle reality rather than a tutorial's tidy inputs.
3. One project that solves a problem you actually have. This is the one that signals initiative. It does not need to be original to the world, just genuinely yours. People can always tell the difference between a project you cared about and one you built for the portfolio.

Make it legible

A good project badly presented still fails the ninety-second scan. Each one needs a README that says what it does and why in three lines, a live link where that makes sense, and a commit history that looks like steady work rather than a single "initial commit" dump. If you can record a thirty-second demo, do it. Most people will not click through, but the ones who do are the ones deciding.

The part AI cannot do for you

You can generate a project. You cannot generate the ability to explain it. The interview is where portfolios are won or lost, and the question is always some version of "walk me through why you built it this way." If the honest answer is "the AI did," you are finished, because the whole point of the exercise is to show judgment, and judgment is exactly what you would be outsourcing.

So build things you understand. Use AI to go faster, the way every working engineer now does, but make sure that for every decision in the project you can say why. That is the difference between a portfolio that gets you the internship and one that gets you caught out in the room.

If you want a second opinion

If you have a rough idea but are not sure it is worth building, or you want help turning a half-finished repo into something you can actually show, message me on Telegram. I would rather help you scope one project worth submitting than watch you build five that a reviewer skips past. For larger builds I quote the work as a fixed-price piece; rates are on the pricing page.