Launch is treated as the end of the project. It is the beginning of the risk.
Before launch nothing is real: no customer data, no money moving, no dependency. After launch all of it is, and in most businesses that is precisely the moment the people who understood the system move on to something else.
The gap nobody owns
The agency's contract ended at delivery. The freelancer finished the scope. The internal developer is on the next feature. The system runs, so nobody is looking at it.
Meanwhile it decays, and the decay is silent by nature. Dependencies acquire published vulnerabilities. Certificates approach expiry. Disk fills. A third-party API deprecates a version. Data volumes cross a threshold where a query that was instant becomes slow. Someone's admin access outlives their employment.
None of these is a failure on the day it appears. Each is a failure scheduled for later, and the scheduling is what makes them dangerous — the incident happens weeks after the cause, so nobody connects the two.
The three questions that define the gap
If it broke at 3am on a Sunday, who finds out? Not who fixes it — who finds out. In a surprising number of businesses the answer is a customer on Monday.
When did anyone last look at this who was not fixing something? Reactive attention is not the same as review. If nobody has read the logs, checked the access list, or looked at the dependency report in six months, the system has been unobserved rather than stable.
Who decides what ships? After launch, changes keep happening — a fix here, a feature there, often by whoever is available. Without someone holding the standard, the quality of what ships drifts toward the quality of whoever shipped last.
What watching actually involves
Less than people fear, and it is mostly rhythm rather than heroics.
Monitoring that pages a human. Not a dashboard — an alert with a name attached. Uptime, error rate, job completion, queue depth.
A dependency and patch cycle. Monthly. Read the report, apply what matters, note what was deferred and why.
An access review. Quarterly. Who has access to what, and should they still.
A restore test. Twice a year, restore a backup somewhere safe and confirm the data is there. Backups that have never been restored are a hypothesis.
Review before shipping. Someone senior reads changes before they go live, holding the same standard the original build was held to.
That is a few hours a month for most systems. The cost of not doing it is not a few hours a month — it is one incident, at a time of the incident's choosing.
Why it is priced like insurance
Because that is the shape of it. You pay a predictable amount so that an unpredictable, larger amount is less likely, and in the good months it looks like money for nothing. That feeling is the product working.
The alternative is the emergency engagement, which costs more, happens at the worst moment, and starts with someone unfamiliar reading unfamiliar code under time pressure while customers wait.
The question to ask this week
Take your most important system and ask who is watching it. If the answer is a name, ask what they looked at last month. If the answer is "it's fine, it's been running for a year", that is not reassurance — a year is exactly long enough for every item on the list above to have gone unattended.
Knowing where you stand is a week's work. A Reality Check covers what is live, what is drifting, and what would need watching — and if the honest answer is that your current arrangement is adequate, it says so.
This is the part we do — the crossing from a demo to a system that survives production.