Founders usually know when a build feels done.
The major screens exist. The critical workflow works in a demo. The core features are present. The team can point to a product instead of a plan.
That is a real milestone.
It is not the same thing as being ready to launch.
Launch changes the standard because the product is about to move from an internal build environment into live use. Real users, real data, real support needs, real operating ownership, and real consequences enter the picture.
That is why I treat Launch Readiness as a decision, not a feeling.
"It works" is not a readiness criterion
A product can work and still have unresolved conditions that matter at launch.
The questions become broader:
- Can the critical user workflow operate safely enough for real users?
- Are the stop-ship risks known?
- Is there a clear owner for operational problems after launch?
- Are the most consequential business rules implemented correctly?
- Is monitoring sufficient to recognize important failures?
- Which issues must be corrected before launch?
- Which issues can be intentionally deferred?
- What risk is being accepted with those deferrals?
Those questions should not appear for the first time when the launch date is already driving the decision.
Readiness works better when the criteria exist before the milestone arrives.
Define readiness before momentum defines it for you
Without explicit criteria, teams often substitute momentum for evidence.
The build passes. The demo works. Everyone has been working hard. The date is close. The backlog is never going to be empty.
So the team starts asking whether anything is "bad enough" to delay launch.
That puts the decision backwards.
The better question is: what must be true for us to authorize this launch?
That does not require perfection.
It requires enough clarity to distinguish a blocking condition from an acceptable residual risk.
For an MVP, readiness criteria may include:
- the critical user journey works end to end,
- required business rules are implemented,
- authentication and tenant boundaries are understood,
- operational ownership is assigned,
- important failures can be detected,
- launch support is planned,
- known issues have an explicit disposition,
- deferred work has a named risk and owner.
The exact list will vary by product. The discipline does not.
A Readiness Review should change the decision
A useful Readiness Review is not simply a pre-launch checklist.
It should produce a decision.
That may be:
- launch,
- launch after specified corrections,
- narrow the launch,
- defer the launch,
- return to Build,
- gather more evidence before deciding.
The size of the review should match the consequence of the milestone. Some products need a focused review. Others justify a deeper audit.
The featured case in this issue required audit-level depth because the founders were approaching a real launch and needed a defensible view of technical readiness.
The audit did not make the product perfect.
It separated stop-ship items from coordinated pre-launch fixes, near-term work, and backlog. It made explicit what had to change before launch and what could wait.
That is the value of readiness work.
Known risk is different from unknown risk
A team can launch with known limitations.
Every product does.
The dangerous position is not "we have issues." It is "we do not know which issues matter to the launch decision."
Readiness gives you a way to make that distinction deliberately.
You can decide which risk is acceptable, which condition is blocking, and what evidence supports the decision.
That is much stronger than relying on a green build, a quiet error log, or the feeling that the team is probably ready.
The goal is not perfect software. The goal is a launch decision you can stand behind.