The ninety seconds that decide it

A shortlisting engineer has a spreadsheet of applicants and a link from each. They are not evaluating your project on its merits; they are looking for a reason to move on. Understanding that is not cynical — it tells you exactly where to spend your effort.

The order they move in

Watch anyone review a portfolio link and it is almost always this:

1. Open the live URL. Not the repository. If there is no live URL, most reviewers stop here.
2. Look at the first screen for about five seconds. Is it obvious what this does?
3. Click the one main thing. Does it work, and does it feel like it was finished?
4. Open dev tools, briefly. Console errors? Anything obviously broken on a narrow screen?
5. Then, maybe, the repository — for the README first, and only then the code.

Almost every student optimises step 5 and neglects steps 1 to 4. The code is the last thing looked at and often not looked at at all.

The four things that end a review

No live link. A git clone, npm install and a missing .env is thirty minutes you are asking a stranger to spend. Deploy it. Free static hosting is universally available; there is no acceptable excuse in 2026, and "it runs on my machine" reads as unfinished.

It is broken on a phone. A large share of reviewers open the link on a phone at some point. A layout that overflows sideways or a button that cannot be tapped signals that you never tested outside your own laptop.

Errors in the console. Red text says nobody checked. It takes one minute to look, and hardly anybody does.

It is a tutorial project, unmodified. A reviewer who has seen the same to-do app forty times recognises the forty-first instantly. If you built from a tutorial — which is fine — change the domain and add one thing the tutorial did not have. A to-do app becomes a lab-report tracker; the weather app becomes a bus-timing board for your campus.

What to put on the path

Given that order, four changes deliver more than a week of new features.

A one-line explanation on the first screen. Not a logo and a hero image — a sentence that says what this is and who it is for. Reviewers should never have to infer your project's purpose.

Seed data already loaded. An empty dashboard with "no items yet" wastes the entire review. If the app is only interesting with data in it, ship it with data in it.

One obvious primary action. Make the thing you want them to try unmissable. If your project's best feature is three clicks deep behind a signup form, it will not be seen — put a demo account button on the login screen, or skip auth entirely.

A README that answers three questions in its first screen: what this is, what it is built with, and what you would do next. That last one is the closest thing to a covering letter you have, and it is where you name a real limitation — the same move that works in an interview.

What actually differentiates

Not the framework. Everyone has React on their resume; it is table stakes, not a signal.

What differentiates, in rough order:

• It is deployed and it works. Half the field falls at this.
• It solves a problem the reviewer recognises, ideally a local one. A campus lost-and-found board is more memorable than a generic e-commerce clone, because you clearly chose it.
• The edges are handled. Loading states, empty states, a sensible error when the network fails. Almost nobody does this, and it is the clearest evidence of someone who has shipped rather than demoed.
• It is small and complete rather than large and half-built.

The last point is worth restating. Three finished screens beat twelve half-finished ones, every time — the same principle as scoping a project in the GenAI course. A reviewer cannot distinguish "ambitious and incomplete" from "unable to finish".

The check before you send it

Open your live link on your phone, on mobile data, in a browser you never use, logged out. Then open the console. Most students discover something in this exercise, and every reviewer would have.