Name what the prototype proved
A prototype might establish that an interaction makes sense, an integration is possible, or a model can handle a narrow task. Write down that evidence and its limits. Avoid treating a successful demonstration as proof that every operating condition has been covered.
Define readiness together
Agree on the expected users, data volumes, environments, and failure conditions. Set acceptance criteria that the team can actually observe. Include accessibility, privacy, access control, and recovery requirements where they apply to the product.
Make behaviour visible
Decide how the team will notice when the service is slow, unavailable, or producing incorrect results. Google’s SRE guidance discusses latency, traffic, errors, and saturation as four useful signals for monitoring. Apply signals that describe the actual user experience rather than collecting numbers without a decision attached.
Plan the first imperfect day
Prepare a deployment process, a rollback or recovery approach, and clear responsibility for incidents. Test the important paths in an environment that represents the intended use. Make the handover include operating instructions and known limitations, not only a repository link.
Keep learning after release
Use observations from real operation to prioritise the next changes. A release is a transition into a different kind of learning. This note is a practical discussion guide, not a guarantee of availability or a report of production results.