The frontend portfolio that actually gets replies

A hiring manager spends somewhere between forty seconds and two minutes on your portfolio before deciding whether to keep reading. That is not cynicism, it is arithmetic — a single opening can draw hundreds of applications.

So the question is not "does my portfolio show that I can code". It is "does the first thirty seconds give someone a reason to keep going".

Why the todo app fails

There is nothing wrong with building a todo app. It is a fine exercise. The problem is what it communicates when it is the headline item on your site.

A reviewer has seen this project several hundred times. They already know exactly what is in it, so it tells them nothing they did not already assume. Worse, because every applicant has one, it signals that you followed the same tutorial as everyone else rather than choosing anything for yourself.

The same goes for weather apps, calculators, and clones of a well-known product built by following a video.

What reviewers are actually checking

Having read a lot of these, the checks are fairly consistent:

1. Does it run? A live link that loads in under three seconds. Not a screenshot, not a video, not a repo they have to clone.
2. Did you make decisions? Anything that shows a choice was made and could have gone another way.
3. Is the code readable? They will open one or two files. Not to audit them — to see whether your naming and structure suggest you would be pleasant to review.
4. Did you finish it? A small complete thing beats an ambitious abandoned one every time.

Notice that "uses an impressive number of technologies" is not on the list.

Three projects worth building

You need three. Not ten.

One that solves a problem you personally have

This is the single strongest item you can have, because it cannot be a tutorial. Something that tracks a hobby, automates a chore, or organises something you care about. It does not have to be original in the world, only original to you.

The interview value is enormous: you can talk about why you built it and what you would change, and it will not sound rehearsed, because it is not.

One with real, awkward data

Take a public API and build something on top of it. The value is in the parts that go wrong — the endpoint that is slow, the field that is sometimes null, the list long enough that you have to think about rendering it.

Handling loading states, errors and empty states is precisely the everyday work of a frontend job, and almost no junior portfolio demonstrates it.

One that is visibly well made

One project where the craft is the point. Keyboard navigation that works, focus states you can see, sensible behaviour at every screen width, motion that respects prefers-reduced-motion.

Frontend is the discipline where quality is visible without reading any code. Use that.

Write a real README

For each project, three short sections:

• What it does, in two sentences, aimed at someone who has never seen it.
• Why you built it — the actual reason, not a mission statement.
• What you would do differently, which is the section that most reliably gets you a follow-up question in the interview.

Skip the badge collection. Nobody has ever been hired because of a build badge.

What to remember

• Three finished projects beat ten half-built ones.
• A live link, loading fast, is the price of entry.
• Choose projects that force you to make decisions you can talk about.
• Say what you would change — it reads as experience, not weakness.

Build the thing you would be happy to be asked about for twenty minutes. That is the whole heuristic.