Launch feels like a single decision, and framing it that way is what makes it so hard. One date carries all of the risk, the criteria are vague, and nobody wants to own the yes. So the safest-looking answer is always to wait another two weeks, which is an answer available indefinitely.
Organisations that ship large digital services regularly do not work this way. They break launch into stages with different bars, which turns an unanswerable question into several answerable ones.
Why the single-decision framing fails
Worth understanding the mechanism, because knowing it makes the staged alternative feel less like process for its own sake.
When one date carries all the risk, the incentives around it are badly aligned. Nobody is ever blamed for a delay. Everybody is blamed for a bad launch. So for each individual in the room, the expected personal cost of saying wait is close to zero, and the cost of saying go is not. That asymmetry produces delay reliably, without anybody making a bad decision.
It also makes the criteria impossible to settle. Ready has no definition, so each person supplies their own, shaped by whatever they are accountable for. The designer's version involves the interface being right. The developer's involves the known bugs being closed. The salesperson's involves the feature promised to a client. None is wrong, and no discussion reconciles them, because they are answering different questions.
Staging fixes both problems at once. The bar for releasing to twenty invited users is low, definable and carries little risk, so agreeing to it is easy. And because the stage has a stated purpose, learning from real use, the criteria follow from that purpose rather than from each person's anxieties.
The second effect matters more. Once launch is a sequence, the argument stops being about whether the product is good and becomes about whether it is ready for a specific, limited exposure. That is a question with an answer.
Borrow the staged model
UK government guidance for building digital services defines distinct phases and is unusually explicit about what each is for [1][2][3].
An alpha is not available to the public at all. You build things just complex enough to test ideas rather than to production quality, and you expect to throw away code and ideas at the end of it [1]. It typically runs six to eight weeks.
Private beta invites a limited number of people to use the service, so you can gather feedback and make improvements [2].
Public beta opens it to anyone who needs it, and the stated condition for moving there is that you have improved the service and are confident you can run it at scale [2].
Live is about supporting the service sustainably and continuing to iterate, including addressing constraints identified earlier [3].
Formal assessments sit between those stages in the government version. In a business the assessment can be a thirty-minute internal review. The sequence is the part that transfers, and it changes the question from "are we ready to launch", which nobody can answer, to "are we ready for the next stage", which somebody can.
What has to be true at each gate
To release privately: one complete path through the product works end to end, you can tell when something breaks, and you can fix things quickly.
Not that everything is finished. The purpose of a private release is learning from real people doing real tasks, and you cannot learn from a group who cannot complete anything, or from failures you never find out about.
To release publicly: you have seen it work with real users, you have fixed what they hit, and you are confident you can run it at the volume that will actually arrive.
That last item is a capacity question rather than a feature question, and it is the one most often skipped. Our guide on systems breaking when you grow covers what to check, and the short version is that the limits you will hit are usually in services you depend on rather than in your own code.
To call it live: it runs sustainably, somebody owns it, and there is a plan for continuing to improve it rather than an assumption that the work has ended.
Unfinished is fine. Broken is not.
This distinction does more work than any readiness checklist.
Unfinished means a feature is absent and people can work around its absence, ideally knowingly. Broken means something present does not work, fails silently, or loses data.
Launching with things unfinished is normal and frequently correct. Launching with things broken damages trust in a way that is expensive to recover, because people who try something broken generally do not come back and do not tell you why.
Four things must never be unfinished, at any scale:
Anything touching money. Anything touching personal data. Anything that could lose information a customer has entered. And your ability to see that something has gone wrong.
Almost everything else is a judgement about timing rather than a matter of principle.
Telling perfectionism from a blocker
One question separates them: what specifically happens to a real user if we ship without this?
A genuine blocker has a concrete answer. They cannot complete the purchase. Their data is exposed. They see somebody else's information. The form loses what they typed.
Perfectionism produces answers about how it looks, how it compares to what was imagined, or how it might be perceived. Those are real concerns and they are not blockers, and the difference matters because they get argued with identical intensity in the final week.
Your team will keep finding things to fix, and that never stops. At some point the list stops containing blockers and starts containing improvements. Sort what remains into those two columns and be strict about the definition, because as a date approaches the two get quietly merged.
And name the decider in advance, ideally not whoever built it. Teams close to the work are systematically poor judges of readiness in both directions: overconfident because everything works on their machine, or overcautious because they can see every flaw. Naming the person before the date arrives stops the decision defaulting to whoever is most anxious in the room.
Make the launch smaller instead of later
The most reliable way to reduce launch risk is not more testing. It is fewer people.
Both major app stores build tooling for exactly this, because releasing to everyone at once is not how experienced teams ship. Our guide on apps nobody is using covers the testing tracks and staged rollout mechanics in detail. The same logic applies to a website or an internal system, where a smaller first audience means a smaller blast radius and a faster fix.
Choose that first group deliberately and not only from enthusiasts. Include people who are busy, sceptical, or less confident with technology, because they represent who arrives later. A private release full of volunteers who want it to work will tell you it works for people who want it to work, which is a considerably narrower finding than it appears.
Then make sure you can go back. Being able to roll back to the previous version in minutes changes the launch decision fundamentally, because it converts an irreversible commitment into a reversible one. Test that you can, rather than assuming. Teams that can roll back launch more readily and more often, and they are right to.
Four things to arrange before the day
Monitoring that tells you the core transaction is working, rather than only that the site responds. A homepage returning a healthy response while checkout silently fails is the most common blind spot there is.
A named person available to fix things, with the access to actually do it.
An agreed way for early users to report problems, so feedback arrives somewhere rather than into a conversation somebody half remembers.
A decision, made in advance, about what would make you roll back.
Those four take a day to arrange between them and change how the launch feels entirely. Our guide on incident response covers the second and fourth properly.
Say that it is early
Telling users plainly that this is an early version, that some things are missing, and that you want to hear what breaks is one of the more useful things available, and it costs nothing.
It sets expectations correctly and converts problems into feedback rather than complaints. People are considerably more forgiving of stated limitations than discovered ones, and the difference in tone between the two responses is striking.
Both directions have a cost
Launching too early costs trust, asymmetrically. People who hit something broken frequently leave without telling you. That is exactly why the four non-negotiable areas matter more than feature completeness: a sparse product that works keeps its users, and a full-featured one that loses their data does not get a second chance.
Launching too late costs everything you have not learned, which is invisible and therefore almost never counted. Every week before real users touch it is another week of building on assumptions nobody has tested. Late launches also tend to arrive carrying more features built on those same assumptions, so more of the work is at risk of being wrong.
Worth also remembering that the date usually matters far less externally than it does internally. Unless you have made a public commitment or tied it to an event, it is an internal artefact. That cuts both ways: a short delay is usually cheaper than it feels, and waiting has no external benefit at all.
Where the date is genuinely fixed by an exhibition or a regulatory deadline, cut scope rather than quality, and decide early which features can be dropped while there is still time to drop them cleanly rather than abandon them half-built.
Measure the right two things
Decide before launch what you will measure, because that is what makes the answer available afterwards.
UK government guidance mandates four performance indicators for public services, including completion rate and take-up [4]. Those two are precisely the ones most businesses never measure. Whether people complete the core task, where they stop if they do not, and whether they come back.
If the early release shows that nobody wants it, that is the single most valuable outcome available and the cheapest possible time to discover it. It is also the finding people resist hardest, because considerable work has already been done. Our guide on apps nobody is using covers how to separate a demand problem from a distribution one, which is the distinction that decides what happens next.
After the day
The two weeks following launch are the most important of the project and the most commonly left unresourced, because everybody assumed the work ended when it went live.
Plan for a period of rapid fixing with people genuinely available. Early users who hit a problem that gets fixed within hours become advocates. The same users hitting the same problem left for a fortnight are gone permanently.
One contractual note: launching a subset of what was specified is a legitimate approach, and it needs to be a decision both sides have made rather than a shortfall one side presents in the final week. Agree it explicitly. Our guide on reading a software proposal covers how acceptance and staged delivery should be structured.
The list that decides it
When the launch conversation has been running for weeks without resolving, the fastest way through is to stop discussing readiness and start sorting items.
Take everything outstanding and put each item in exactly one of four buckets.
Stops a real person completing the core task. These are blockers. There are usually far fewer than the team expects, often two or three on a list of forty.
Touches money, personal data, potential data loss, or your ability to see failures. Also blockers, regardless of how minor they look, because these are the four areas where being wrong is expensive to recover from rather than merely embarrassing.
Would be noticed and complained about, but does not stop anything. Not blockers. Fix them in the fortnight after launch, when you will also know which ones people actually mention.
Would only be noticed by us. The largest bucket by some distance, and the one that has quietly been setting your launch date. Design details nobody outside the team will register, edge cases that occur once a year, and comparisons to the version that existed in somebody's head.
Do this as a group, in one session, with the named decider present. The sorting itself resolves most disagreements, because arguing that a specific item belongs in bucket one is much harder than arguing vaguely that the product is not ready.
Then commit to a date for a limited release based only on buckets one and two. Almost every team that does this discovers the list of genuine blockers is short and mostly already in progress.
Stop the date slipping forever
Attach the date to a stage rather than to completion.
"We release to twenty invited users on the fifteenth" is a commitment you can keep almost regardless of what remains unfinished, because the bar for that stage is low and defined.
"We launch when it is ready" is not a date at all, and it will move as many times as somebody finds something else worth adding.
This week, split your outstanding list into two columns: things that stop a real person completing the core task or that touch money, personal data, data loss or monitoring, and everything else. Then set a date to release to a small invited group regardless of what sits in the second column.
That exercise usually reveals that you were considerably closer than the team believed.
If you want an outside view, a launch readiness review covering what works end to end, what would fail under real volume, whether the four non-negotiable areas are genuinely covered, and what is a blocker rather than an improvement starts from around AED 2,500 with us. Final pricing depends on scope, and these are our own figures rather than a market survey.
References
- GOV.UK Service Manual, how the alpha phase works
- GOV.UK Service Manual, how the beta phase works
- GOV.UK Service Manual, how the live phase works
- GOV.UK Service Standard, define what success looks like and publish performance data
- SKIMBOX, your app is built and nobody is using it
- SKIMBOX, your system breaks when you grow
- SKIMBOX, it broke at 2am: who do you actually call
- SKIMBOX, how to read a software proposal
UK government service guidance governs public sector digital services in that country, including mandatory assessments and published performance data. It is cited here for the staged approach and its stated criteria, which adapt well to commercial launches, rather than as requirements binding on businesses in the UAE.
