# Go-live is where ownership starts The real test is what happens after users, edge cases and Monday morning arrive. By Sunclue. Published: 2026-09-12. Updated: 2026-09-12. ## TL;DR Launch is the start of operating a service. Before people rely on it, agree who will notice failures, respond and restore the work that matters. - Name owners and backups, with support coverage the team can sustain. - Monitor real user journeys and rehearse recovery, including partially changed data. - Reserve time for stabilisation and keep accounts, access and operating knowledge with the company. The release is live. The demonstration has gone well. People can sign in, the dashboard loads and the launch message is ready. Then a customer uploads an unexpected file, an overnight job stops halfway through or the person who knows the deployment process takes a holiday. Software becomes part of the business when people depend on it to do their work. At that point, ownership has to cover the days when the system behaves differently from the demonstration. Someone needs to notice the problem, help the people affected and decide what happens next. Those responsibilities are easier to establish before launch, while the team still has the time and attention to test them. ## Give every critical journey an owner Start with the work people must be able to complete. For a manufacturing business, that might include recording a production run, releasing stock or sending an order to the warehouse. Each journey may cross several applications and teams. Name a business owner who can explain the consequence of failure and an engineering owner who can coordinate a response. Add a backup for each. Ownership should survive an absence, a supplier change and the end of the original delivery project. Be specific about coverage. If people depend on an overnight process, an agreement that covers office hours needs an explicit plan for failures outside those hours. Promise the response the team can sustain and make the limits visible to the people using the service. A contact list is only part of the arrangement. The responsible people need access to relevant information, the authority to make appropriate changes and a clear route for decisions they cannot make alone. ## Agree what a working service looks like A server being available does not prove that a customer can complete an order. Define health using the journeys that matter to the business, alongside the technical signals used to investigate problems. For an overnight stock update, useful questions include whether the run completed, whether expected records arrived and whether rejected records can be found. A process may exit successfully while importing an empty file. The team needs to know whether that result is normal for the business. Discuss timeliness too. An update that is correct by lunchtime may still be a failure if warehouse staff need it before the morning shift. Agree the point at which someone should investigate and the point at which the business needs to switch to a fallback process. Google's [guidance on production readiness reviews](https://sre.google/sre-book/evolving-sre-engagement-model/) treats reliability requirements and operational preparation as part of accepting responsibility for a service. A smaller team can use the same basic idea: agree what must be ready and demonstrate it before assuming the system is safely supported. ## Rehearse the awkward morning Choose a plausible failure and walk through it with the people who would respond. Suppose a scheduled import stops after processing part of a file. Who notices? Can support see which records succeeded? Would rerunning the job duplicate anything? Who tells the warehouse whether it can continue? Run technical exercises in an appropriate environment with an agreed scope. The point is to discover missing access, unclear instructions and unsafe assumptions without creating a new incident in production. Keep recovery instructions close to the work. A useful runbook explains the symptom, the checks to perform, the permitted intervention and how to confirm recovery. It should also say when to stop and escalate. A long document that requires its author to interpret it has not transferred much capability. Try the instructions with someone who did not write them. If they cannot identify the affected records or find the right dashboard, improve the material while the details are fresh. ## Plan for the data left behind Rolling back application code may restore the previous behaviour, but it does not automatically undo records already changed by the new version. A failed release can leave duplicate events, partially processed orders or messages that were already sent. Before a risky change, consider both the software and the data. Establish how affected records will be identified and whether the team would reverse, repair or complete the work. Some changes are easier to fix forward than to reverse; the release decision should account for that. The same care applies to restoring a backup. Agree how much recent work the business could lose and what it would take to reconcile records created elsewhere during the interruption. A successful restore is not the end of the recovery if people must still determine which orders are valid. These questions belong in planning because they can change the design. A record of processing progress, for example, may be worth building before launch if it makes an interrupted job recoverable. ## Make room for stabilisation Early operation reveals work that a launch plan cannot fully predict. Users interpret labels differently. Real data contains exceptions. An integration behaves differently at a busy time of day. Reserve capacity for responding to those findings instead of allocating the entire team to the next major feature immediately. Separate defects from new requirements through discussion with the business owner. If the system cannot complete an agreed workflow, the team needs to repair it. If users now want a different workflow, that deserves a deliberate scope decision. Calling every request a bug creates confusion; calling every defect a new feature damages trust. Keep support observations connected to the product backlog. Several tickets about the same confusing field may justify changing the interface. Repeated manual repairs may reveal a missing validation rule or an unreliable dependency. Operations can provide direct evidence for what to improve next. For each recurring issue, record the affected journey and the cost to the people doing the work. That makes a quieter reliability improvement easier to compare with a visible new feature. ## Keep the company able to operate its own software Your repositories, cloud accounts and essential subscriptions should have clear company ownership. Access should be sufficient for the people doing the work and reviewed when responsibilities change. Avoid arrangements where a departed employee or a supplier's personal account is the only route to a critical system. Document the practical dependencies: the domain renewal, the email provider, the scheduled job and the integration credentials. Include who receives billing notices and service alerts. These details are easy to dismiss during development and difficult to ignore when a renewal failure interrupts service. If another team will take over, give them time to operate the system with the original team available. Ask them to perform a routine release and investigate a representative failure. Their questions show what the handover still needs. ## Review ownership as the service changes Set a regular review around a few concrete questions. Which failures affected users? Which interventions keep repeating? Are the agreed support arrangements still appropriate for the way the business now uses the software? What upcoming change could make recovery harder? The review should produce decisions, with owners and dates. Remove alerts that create noise, repair the recurring problem or update the runbook that failed during an incident. If usage has grown, revisit capacity and coverage before the next busy period exposes the gap. Before your next launch, ask someone outside the delivery team to explain what happens when a critical journey fails. Give them the actual contacts and instructions, then let them walk through the response. Anything they cannot resolve is work to finish while the launch team is still together. If that exercise uncovers a system already struggling to support the business, read [How to rescue a stalled build without rewriting everything](https://sunclue.com/insights/how-to-rescue-a-stalled-build-without-rewriting-everything/). ## Keep reading - [Which finance workflow should become an AI agent first?](https://sunclue.com/insights/which-finance-workflow-should-become-an-ai-agent-first/) - [How much is production loss costing your factory?](https://sunclue.com/insights/how-much-is-production-loss-costing-your-factory/) - [Why the first slice should be uncomfortably small](https://sunclue.com/insights/why-the-first-slice-should-be-uncomfortably-small/) - [How to rescue a stalled build without rewriting everything](https://sunclue.com/insights/how-to-rescue-a-stalled-build-without-rewriting-everything/) - [Where AI earns its place, and where it should stay quiet](https://sunclue.com/insights/where-ai-earns-its-place-and-where-it-should-stay-quiet/) --- [Canonical HTML page](https://sunclue.com/insights/go-live-is-where-ownership-starts/) ยท [Sunclue reading guide](https://sunclue.com/llms.txt)