What Does a Deployed Project Need for a Recruiter to Trust It in 30 Seconds?

A recruiter's 30 seconds is three separate questions, not one. Here is what a live project has to answer, and the one-minute test that catches every failure.

By Howard Davner

Quick Answer: Three things, in this order. It opens without a login. It shows a finished result before the visitor touches anything. And it says who built it. A recruiter's thirty seconds is not one judgement, it is three separate questions, and most deployed projects fail on the first one before the other two are ever asked.

Everyone tells students to deploy the project. Almost nobody tells them what happens in the thirty seconds after someone clicks the link.

Those thirty seconds are not a single impression. They are three questions, asked in a fixed order, and each one has to pass before the next gets asked at all:

1. Does this open?
2. Does it do something, without me having to work out what to type?
3. Did this person actually build it?

A live URL answers none of them. It only proves that something exists at that address. Here is what each question really tests, and why the first one fails far more often than anyone building the project expects.

Question one: does it open?

This is where most projects die, and the student almost never finds out, because the project opens perfectly for them.

Your app is probably asleep. Free hosting plans suspend idle applications to reclaim capacity. Render's documentation is specific about it: a Free web service is spun down after 15 minutes without inbound traffic, and spinning it back up takes about one minute, with a loading page shown to whoever is waiting. Read that against how a recruiter actually arrives. They are opening your link at some arbitrary moment, hours after anyone last touched the app. They are not a normal visitor who benefits from a warm server. They are, essentially always, the request that has to wake it up. You test your project by clicking it repeatedly while you work on it, so you never once see the slow path that is the only path they get.

You have two honest options. Put the project on a host that does not sleep the app, or accept the wake-up and make the loading state say something useful instead of showing a blank screen for a minute.

Your link might not be your project. This one is quietly common and completely invisible until someone points at it. Vercel generates several URLs for the same project, and they are not interchangeable. A deployment built from a specific commit gets a URL shaped like project-name-unique-hash-scope.vercel.app. A deployment built from a branch gets project-name-git-branch-name-scope.vercel.app. The production deployment is the short one, without the hash and without the git- segment.

So: look at the link on your resume right now. If it contains git-, or a run of nine random-looking characters, you have put a preview build on your resume. Previews are for reviewing changes. They can sit behind deployment protection, which means the recruiter clicks your project and gets asked to sign in to an account they do not have. They will read that as your project being broken, or private, or fake. They will not email you to ask.

Nothing should ask them to sign up. If the first screen is a registration form, the thirty seconds are gone and they have seen nothing you made. This is worth stating plainly because it is the single most self-inflicted version of this failure: a student builds a genuinely good tool, adds authentication because real products have authentication, and in doing so ensures that nobody evaluating them ever sees the tool. Put the demo in front of the login wall, or take the login out.

Question two: does it do something on its own?

Assume it opened. The visitor is now looking at your first screen with no idea what they are supposed to do.

A blank input box and a Submit button is not a demo. It is homework. The recruiter has to invent a plausible input, guess at the format you expect, and hope the result means something to them. Most will not. They will look at the empty box, conclude that they cannot evaluate this quickly, and close the tab.

The fix is small and almost nobody does it: make the first screen already show a worked result. Load with a real example pre-filled and its output rendered, then let the visitor change the input if they want to. The difference is between handing someone a tool and handing them a finished piece of work that happens to be interactive. One of those can be judged in ten seconds.

The same applies to anything that needs a key. If your project asks the visitor to paste their own API key before it will do anything, it does not work, for the purposes of every person who will ever evaluate it. Keep the key server-side and give the demo a usage budget you control. This is the same discipline that keeps a key out of the browser's network tab, which is a separate problem worth reading about in what employers actually look for in a CS portfolio.

Question three: did you build it?

This is the question no page-one article covers, and it is the one that has quietly changed the most.

When anyone can generate a working application, a working application stops being proof on its own. A recruiter who has seen four identical-looking tools this week is not asking whether the code runs. They are asking whether there is a person behind it who can talk about it. And they are asking that in the same thirty seconds, from the page itself, because they are not going to open an interview to find out.

What resolves it, in descending order of how fast it reads:

• A line on the page in your own voice. Not a README. One or two sentences, visible on the deployed site, saying what the thing is for and one decision you made while building it. "Uses a stored snapshot rather than live scraping, because the source changes format without warning" tells a reader more about you than the entire application does.
• A date. Something on the page that shows when it was built or last updated, ideally predating your application.
• Your name, linked to somewhere real. The deployed project should point back at you, not sit anonymously on a subdomain.
• The repository, linked from the app rather than from the resume. This inverts the usual order for a good reason. Sending a recruiter to a repo first makes them do the work of finding the live thing, which is exactly the failure described in why your GitHub is not a portfolio. Sending them to the live thing, with the code one click away for whoever wants it, serves both readers in the order they arrive.

Using AI to build faster does not weaken any of this. Being unable to say why the thing is built the way it is does.

The one-minute test that catches all of it

You cannot evaluate your own project from your own laptop, because your laptop is the one environment where it always works. Your browser holds a session, your passwords autofill, your server is warm because you just deployed to it, and your screen is the size you designed for.

So reproduce their conditions exactly. Open your project on your phone, in a private window, having not touched it for a few hours.

That single minute catches every failure above at once: the cold start, because the app has genuinely gone to sleep; the login wall, because you have no session; the preview-URL problem, because deployment protection will stop you too; the blank first screen, because you are seeing it the way someone who has never seen it sees it; and the layout, because a good share of first clicks happen on a phone.

Do this before the link goes on the resume, not after.

The tradeoff worth naming

The most impressive version of a project is usually the most fragile one, and this is a genuine tradeoff rather than a rule.

A project wired to live third-party data is a better build and a worse demo. Keys expire. Rate limits trip. Upstream endpoints change shape. None of that fails loudly, which is the real problem: nothing alerts you, the project simply starts returning nothing, and it does so weeks after you tested it and shipped the resume.

For anything a stranger will click cold, ship a stored snapshot with a visible "data as of" date, and put the live call behind a button they can choose to press. You lose a little credit for freshness. You stop losing everything to a silent failure on the one click that counted.

If you do not have one to test yet

All of this assumes there is a deployed project to check. If there is not, that is the actual problem, and it is a smaller one than it looks, because the thirty-second standard above is mostly a checklist rather than an engineering challenge.

The build is what takes the time: choosing something specific enough to be worth showing, scoping it to one input and one output, getting it onto a URL that stays up. Provieo's project builder takes a job description and walks that whole path, from the idea through to a deployed URL, which is the part that turns a repo into something a stranger can open. Free to use, and your first project build and deploy is free. What you do with the thirty seconds after they click is still on you, and it is the part of this that is worth getting right.

Once it is live, a deployed project on a resume is only as good as its first thirty seconds. Go test yours from a phone.

The bottom line

A live URL is the beginning of the argument, not the end of it.

The thirty seconds a recruiter spends on your project are spent answering three questions in sequence, and the project has to survive all three: it opens, it shows something on its own, and it reads as the work of a specific person. Most projects fail on the first because the student has never once seen their own app the way a stranger does.

Open yours on a phone, in a private window, cold. Whatever happens in that minute is what a recruiter sees.

Put a working link in your next application.

Paste the job you're applying to. Provieo designs a project against that exact listing and walks you through deploying it — so what a recruiter clicks is the work itself, not a description of it.

Free to use, and your first deployed project is free. Or tailor your resume to the same posting.