Build to run
The most dangerous day in the life of a new technology is the day it goes live. Not because something breaks, although something usually does, but because that is the day everyone stops paying attention. The project celebrates, the steering committee moves on, the best people get pulled into the next initiative. What remains is a service that will run for years, and a question nobody asked loudly enough: run by whom, exactly, and how?
The inverted arithmetic
A typical service spends a few months being built and many years being operated. Two percent of its life is build; the rest is run. Attention, budget, and senior involvement flow in exactly the opposite proportion. We plan the two percent in detail and improvise the ninety-eight. Go-live gets treated as a finish line when it is, quite literally, the starting line.
The inversion has predictable results. Services with no named owner. Knowledge that lives in one head. A runbook that consists of chat history. Monitoring that gets added after the first incident instead of before it. Temporary configurations that quietly age into permanence. None of this is malice. Each is a project behaving rationally inside a system that rewards delivery dates and ignores operability.
The boundary that fixes it
Between build and run belongs a checkpoint, and its nature matters more than its checklist. It is an acceptance by the receiving side, not a handover by the delivering side. The service owner who will live with the thing decides whether it is operable. Projects grade their own homework generously; the operations owner has no such incentive, which is precisely why the signature belongs there.
What does acceptance actually check? Four groups cover it. People: a named owner who has said yes, a trained team, knowledge held by at least two heads. Operability: a runbook including standard changes and known failure modes, monitoring with agreed thresholds, a backup that has been restored at least once rather than merely configured. Integration: the security review done and access running through standard roles, a published support path with defined service levels. Sustainability: capacity and cost modeled, a lifecycle plan for patching and end of life, and an exception list that is either empty or has an owner and a date on every entry.
"Not done" is information
The hard moment comes when a criterion fails two weeks before a committed date. The temptation is always the same: hand it over anyway, fix it later. Later has the weakest gravitational pull of any word in IT. Saying "not done" feels like failure in that meeting, but it is the system working as designed. It is far cheaper to hold a service back for two weeks than to operate it half-owned for two years.
Is this bureaucracy? Only if the criteria are theater. Kept to what the receiving team genuinely needs on a bad Tuesday at three in the morning, the checkpoint removes friction rather than adding it. And it changes behavior upstream: teams that know the acceptance is real start designing for operability on day one, because they would rather pass the gate than argue with it.
Roadmaps answer the question "what next". Operating models answer "who, how, every single day". New technology needs the second answer before the first one deserves any attention. And the point of the checkpoint is not devotion to uptime; it is design. When ownership, knowledge, and handover are structural, reliability stops being an effort and becomes a property of the system.