Open enough frontend portfolios and a pattern appears fast: a todo app, a weather widget pulling from a public API, and a recipe site with a search bar. All three are genuinely useful for learning React or Vue for the first time. None of them tell a reviewer anything, because they have seen the same three projects hundreds of times, built from the same tutorials, with the same three states: it loads, it works, it looks fine in the screenshot.
The problem is not that these projects are bad practice. It is that they stop exactly where the interesting engineering starts, which means they cannot function as evidence of much beyond "I can follow a tutorial".
What a reviewer is actually checking for
A frontend project reads as real work when it shows the parts a tutorial usually skips.
- Real interaction states. What does the screen show while data is loading, when a request fails, and when there is genuinely nothing to display yet. A todo app with three items typed in for the screenshot never has to answer any of these.
- Data that changes under you. A live API, a websocket, or any source that is not a static JSON file you control yourself. Handling data you cannot predict is most of what separates application engineering from a static page.
- Something measurable. A Lighthouse performance score, an accessibility audit result, a load time you can actually state. A number a reviewer can check themselves is worth more than an adjective in your README.
- A deployed link and an honest README. Not a link to a repository someone has to clone and run. A working link, plus a short, accurate description of what the project does and what you would improve given more time.
None of these need a bigger project. A small project with all four beats a large one with none of them.
Ideas that clear the bar
Swap the subject, not the shape. A dashboard over a real, changing dataset clears the bar a todo app cannot, because the data forces you to handle loading and error states honestly. A small tool that does one specific job well, converts something, checks something, tracks something, with a genuinely deployed link and a clean interaction flow, reads as more finished than an ambitious app that is only half wired up. A game or interactive experience with real state management, scores, rounds, a result that depends on what the user actually does, shows you can handle complexity a static form never will.
A second angle worth trying is rebuilding something that already exists, on purpose. Recreating a well-known interface, a checkout flow, a booking calendar, a media player, forces you to solve problems the original designer already solved once, which is a fast way to notice the states you would otherwise skip past. It also gives a reviewer an instant point of comparison: they already know what the real thing does, so they can see immediately where your version handles the awkward cases and where it quietly does not.
The predict-the-cup project is a useful example of what beyond the todo app looks like in practice: you are building a frontend for a live prediction game, which means you cannot avoid loading states, changing data, or a result that depends on what actually happens rather than a value you hardcoded for the demo. It is graded, so you also get a rubric telling you exactly where your interaction handling held up and where it did not, which a self-run tutorial project never gives you.
A small project with a loading state, an error state and a number you can point to beats a big one with none of them.
The funnel that actually gets you an interview
Once you have a project with real states, changing data and a measurable result, the last step is making sure a reviewer can tell that from thirty seconds on your portfolio page, not from reading your code.
That is almost entirely a documentation problem, not a code problem. How to document a project README covers the shape a good one takes: what the project does, what decisions you made and why, what the measurable result was, and what you would change with more time. That last part matters more than most students expect. Naming a limitation you are aware of reads as more senior than pretending the project has none.
It is also worth being upfront with yourself about what a self-built, self-hosted project can and cannot prove on its own. Verifiable projects vs self-claimed goes into why a project graded against a transparent rubric, ending in a certificate a recruiter can check by link, carries a different kind of weight than a repository you are simply asking someone to trust.
If you already have a todo app, a weather widget or a recipe site sitting in your portfolio, you do not need to delete it. You need one project sitting above it that handles a loading state, an error state, and a number you can point to. Build that one next.
