There is a satisfying moment in building software when the main flow finally works.

The user submits something. The system processes it. The result appears. The experience starts to feel real.

That moment matters. A working demo is a milestone, but it is not the finish line. I would separate two questions.

Can we make this work? And can people rely on it under the conditions they will actually use it in?

A demo helps answer the first. Preparing for launch means investigating the second.

Test beyond the intended path

Before launch, I would work through the scenarios a presentation can easily avoid:

  • Someone submits incomplete information.
  • A third-party service is unavailable.
  • A user clicks twice.
  • A file is larger than expected.
  • A session expires during a task.
  • A user returns after leaving halfway through.
  • Two people try to update the same record.

The point is not to imagine every possible failure. It is to identify the failures most relevant to the workflow and decide how the product should respond.

Does it keep the user's work? Explain what happened? Offer a safe retry? Tell the team something needs attention? Real users will find more of these than the team does, which is why I test every preview with them.

Check boundaries, not just screens

Hiding a button does not answer whether an action is properly restricted.

For a product with multiple organizations or user roles, I would want testing at the implementation level of who can read, create, update, export and delete information.

Input validation also needs more than checks in the browser. W3C's forms tutorial notes that client-side validation alone does not ensure security, so data needs to be validated on the server as well.

The interface and the enforcement underneath it need to agree.

Evaluate AI with representative tasks

If the product includes generative AI, a handful of impressive outputs would not be enough for my launch decision.

I would put together examples that reflect the intended work, including ambiguous requests, missing information and unacceptable outputs. Then I would define what counts as a useful result and what needs a person to step in.

NIST's Generative AI Profile emphasizes evaluation, pre-deployment testing and monitoring across the AI lifecycle, not just assessing an impressive demonstration.

The evaluation should match the product's role. An internal brainstorming assistant and a system drafting customer-facing advice need different acceptance criteria.

Decide how the product will be operated

I would also want answers to practical questions. Who receives error alerts? Who helps a user who cannot get in? How are configuration changes made? What can be rolled back? What happens if a service becomes too expensive or unavailable?

These are ownership decisions as much as technical ones. A launch checklist should make those responsibilities explicit, starting with who decides it ships.

Match the release to the risk

Not every product needs the same launch process. A limited internal pilot can have different constraints from a public application handling sensitive information.

My approach is to define the audience, the consequences, the dependencies and the acceptable limitations before deciding what "ready" means.

A working demo shows the promise. A responsible release makes clear where that promise holds, where the boundaries are and what the team will do when reality does not follow the script.

If you have a working demo and a launch date, email me and we can work out what ready means for your product.