Two failure modes sit either side of this decision, and they are equally expensive.

The first is launching too late, polishing something in private until the money runs out, protected from the only feedback that could have improved it. The second is launching into a broken funnel, getting a bad result, and concluding the idea failed when what actually failed was the sign-up form.

Readiness is not a feeling. Nobody feels ready. It is a short list of things that have to be true so that the launch produces evidence you would be willing to act on.

The test that settles it

Before the checklist, the principle underneath it.

An MVP is ready when a stranger can complete the core journey without you, and you can tell what happened.

Both halves matter. "Without you" rules out a product that only works when a founder is on a call talking someone through it. "You can tell what happened" rules out launching blind, which turns the entire exercise into an anecdote.

If both are true, further delay is usually fear wearing the costume of quality.

The eight things that must be true

1. The core journey completes, on a phone, for someone who has never seen it

Not the happy path in a demo. A person who found you today, on whatever device they happen to hold, with no explanation. Watch someone do it. Do not help.

2. New accounts see something sensible

The empty state is the first impression for every single user, and it is the screen teams most often forget, because everyone testing has data. An account with nothing in it should explain what to do next, not present an empty table.

3. Failure is handled

Wrong password, expired card, lost connection, a file that will not upload, a required field left blank. Each one needs a message that says what happened and what to do. Silent failures are worse than error messages, because the user blames themselves and leaves without telling you.

Account recovery deserves a specific mention: people will lock themselves out in the first week, and if they cannot get back in, they are gone permanently.

4. You can see what people do

Instrumentation is the one item on this list that cannot be added retroactively. You get exactly one chance to observe the first cohort's behaviour, and if you are not measuring when they arrive, that data does not exist afterwards.

Keep it narrow — the events that answer your learning question, not a general dashboard. For most early products that means: arrived, signed up, completed the core action once, came back, paid, cancelled. Six events, defined precisely enough that two people would count them the same way.

5. The page does not sabotage you

If the product loads slowly or shifts under the user's thumb, you measure your infrastructure rather than your idea. Google's Core Web Vitals give usable thresholds: largest contentful paint within 2.5 seconds, interaction to next paint at 200ms or less, cumulative layout shift at 0.1 or below, assessed at the 75th percentile of real visits.

Check on a mid-range phone on a normal connection, not a laptop on office wifi.

6. You can fix things without a deployment

Copy will change in the first fortnight, because the first fortnight is when you discover that the words you chose do not mean to customers what they mean to you. If every wording change requires an engineer and a release, those changes do not get made.

Getting content out of the code — into a CMS or at minimum a single configuration file — is a small piece of work that pays back within days.

7. Someone is watching

A named person, checking errors and messages daily, for the first two weeks. Early users who hit a problem and get a reply within the hour frequently become the most valuable people in your entire pipeline. The same users, ignored for three days, leave and tell someone.

8. The legal minimum is in place

Privacy notice, terms, cookie handling, and an accurate statement of what data you collect and why. Not glamorous, not optional, and much cheaper to do before launch than after a complaint.

What does not have to be true

Explicitly, so that these do not become reasons to delay:

  • Every feature you discussed exists. Most should not.
  • The design is finished. It needs to be comprehensible, not resolved.
  • It scales. It needs to hold fifty users, not fifty thousand.
  • Onboarding is self-serve. Doing it by hand for the first twenty is better research anyway.
  • Every device is perfect. The common ones are enough.
  • You are proud of it. Useful signal, poor gate.

Launch narrow, then widen

The distinction that saves the most grief: the launch that tests your product and the launch that announces your company are different events, and they should not be the same day.

First, a private group. Twenty to fifty people from your validation work, brought on individually, with a conversation attached. This is where you find the things no amount of internal testing surfaces. Expect to fix something significant.

Then a quiet public launch. The product is available, the site describes it honestly, search engines can find it. No campaign. Watch the funnel with strangers in it, which behaves differently from a funnel full of people who know you.

Then the announcement. Communities, press, whatever channels you have — once you know the thing works and you have language that has been tested on real people.

Teams that compress these into one day get a spike of traffic against an unproven funnel, and cannot separate "people did not want this" from "people could not work out what it was."

The go / no-go conversation

Sit down a week before the intended date and answer these out loud:

  1. Can a stranger complete the journey unaided? Demonstrate it, do not assert it.
  2. What question is this launch answering, and what result changes the plan? Written down beforehand.
  3. What are we measuring, and is it working right now? Test the events in production.
  4. What is manual, who is doing it, and what happens if fifty people sign up on Tuesday?
  5. What is the worst realistic failure, and what do we do about it? Data loss, payment failure, a security problem. Have an answer.
  6. Who is on support, and for how long?

A no on questions 1, 3 or 6 delays the launch. A no on the others is usually a conversation rather than a blocker.

After the date

The first two weeks are not a marketing period. They are a research period, and they are the most information-dense fortnight the company will have for a long time.

Watch where people stop. Read every message. Call the users who signed up and did nothing — they are more informative than the ones who converted, and they are much easier to reach than you expect. Resist shipping new features in the first fortnight; almost every impulse to add something is better served by understanding why the existing thing did not land.

Then, with a month of behaviour in hand, the question stops being "is it ready" and starts being "is it working" — a different discipline entirely, and the point at which Grow becomes the relevant conversation rather than the build.

Most of this checklist is about protecting the quality of the evidence rather than the quality of the product, which is a distinction that gets lost when a launch date approaches. A launch that produces an unreadable result costs the same as one that produces a clear answer.

The build and launch work — the funnel, the performance, the instrumentation, the content system that lets you change your mind quickly — is the core of what we do in web design and development for early-stage teams.

If your product is late because it is not finished, launch it. If it is late because a stranger cannot get through it, that is a different problem, and it is worth another week.

Common questions

How do I know if my MVP is ready to launch?

Two conditions. A stranger can complete the core journey on their own device without help, and you can see what happened when they tried. If both are true, further delay is usually fear rather than quality. If either is false, that is a real blocker.

Should I do a soft launch or a public launch?

Both, in sequence, on different dates. Start with twenty to fifty people from your validation work, with a conversation attached. Then a quiet public launch with strangers in the funnel. Only then announce. Compressing these into one day makes it impossible to separate "nobody wanted it" from "nobody understood it."

What analytics should I set up before launch?

Six events, defined precisely enough that two people would count them the same way: arrived, signed up, completed the core action once, returned, paid, cancelled. Narrow and reliable beats broad and vague. This is the one item that cannot be added retroactively — the first cohort's behaviour is observable exactly once.

How long should I wait before adding new features?

At least the first fortnight, and usually longer. Almost every impulse to add something in the first two weeks is better served by understanding why the existing thing did not land. The first month after launch is the most information-dense period the company will have.

Do I need legal pages for an MVP?

Yes. A privacy notice, terms, cookie handling and an accurate statement of what data you collect and why. It is unglamorous and considerably cheaper to do before launch than in response to a complaint.

What if nobody signs up after launch?

Check the funnel before concluding the idea failed. Slow loading, a confusing sign-up, a broken email or an unclear headline all produce the same flat number as genuine lack of demand. Rule out execution first — then talk to the people who arrived and left.

Sources and further reading