The system is finished. The project is about half done.
A build ends when the last feature passes review. A system starts when real people put real inputs into it, and those two events are separated by a period that most statements of work treat as an afterthought. The build had a plan, a budget, a schedule and a named owner. The ninety days after it usually have none of those, which is why they are the part of the project most likely to go sideways.
This is not a criticism of anybody's engineering. A well-built system launches with real defects still in it, because there is a class of problem that only appears under real load, real data and real user behavior, and no amount of testing finds it in advance. The difference between a smooth launch and a bad one is almost never code quality. It is whether somebody planned for the period when those problems arrive.
The first seventy-two hours
Almost everything that breaks in the first three days breaks for one of five reasons, and none of them is a logic error in the feature you spent the most time on.
Data that was never in the test set. The customer record with an apostrophe in the name. The order with a quantity of zero. The file exported in 2014 with a different column order. Every organization has a body of historical data that predates every current convention, and it arrives on day one.
Volume in the wrong shape. Not total volume — distribution. One account has forty thousand line items and everyone else has forty. A query that runs in eighty milliseconds for the median customer runs for two minutes for that one, and it is always that one who calls.
Something upstream behaving differently in production. A rate limit that the sandbox did not enforce. A payment provider returning a status the test environment never produced. An identity system with a group membership rule nobody documented.
Permissions. The system works perfectly for the people who built and tested it, all of whom are administrators. The first regular user logs in and half the screen is missing, or worse, is not missing when it should be.
Time. Time zones, daylight saving, month boundaries, fiscal calendars that do not start in January. Reliably one of the first ten bugs.
None of these are surprising individually. What surprises buyers is the arrival rate. Expect the first three days to produce more issues than the following three weeks, and expect most of them to be small. That curve is normal and it is the reason for the practice described next.
Hypercare, and what it should cost
Hypercare is the industry word for a defined, staffed, time-boxed period immediately after launch where the people who built the system are still on it, response times are short, and fixes ship daily rather than on a sprint boundary. It has a start date, an end date, an agreed response commitment and a budget. It is not the same as a support contract, and it is not goodwill.
Our planning assumption is that hypercare runs two to four weeks for a small system and four to eight weeks for a large one, and consumes somewhere between 10% and 20% of the original build effort. If your vendor has not priced anything into this window, either they intend to absorb it — which usually means it competes with their next client — or the conversation about who pays for launch-week fixes is going to happen during launch week.
| Period | What is actually happening | Reasonable expectation |
|---|---|---|
| Days 1–3 | Data shape surprises, permissions, upstream differences | Same-day fixes, someone reachable, a daily standing check-in |
| Week 1–2 | Defect arrival peaks then falls sharply; first real usage patterns visible | Fixes shipping most days; a written list everyone can see |
| Week 3–6 | Adoption becomes the issue, not defects. Workarounds appear. | Usage measured per person; the workarounds investigated, not scolded |
| Week 6–12 | The first change requests that are genuinely new scope | A change process that distinguishes a defect from a new request |
| Day 90 | Steady state, or a clear signal that something is wrong | A written review against the outcome the project was funded for |
The adoption cliff nobody budgets for
Here is the failure that costs the most and appears in no defect tracker. The system works. It is fast, it is correct, and four weeks later a fifth of the intended users are using it while everyone else is back on the spreadsheet.
This happens for reasons that are consistent enough to plan around. The old way still works, so there is no forcing function. The new system is better at the whole task but worse at one small step somebody does thirty times a day. Training happened two weeks before launch and has been forgotten. The person who championed the project changed roles. Or the system asks for a field that the people entering data genuinely do not know at the time they are asked for it, so they type something to get past the screen — and now your data has a column full of fiction.
The instrumentation that catches this is simple and it has to be built before launch, not after: usage by named user by week, task completion rate, time spent per task, and abandonment at each step. If four weeks in you cannot answer “how many people used this yesterday,” you cannot manage the rollout, and you will find out how it went from a hallway conversation in month four.
The fix is almost never a feature. It is usually removing a required field, changing a default, fixing one slow screen, or sitting with three users for an hour and watching what they actually do. That hour is the highest-return activity in the whole post-launch period and it is the one most likely to be skipped.
You are probably here because
- A launch date is close and nobody has said what happens the day after
- Your last project shipped and then quietly stopped being used
- The vendor's proposal ends at “deployment” and you suspect that is not the end
- You are being asked to approve a run budget and have no basis for the number
The hypercare section has the cost ranges. The adoption section is the one that decides whether the money was well spent. The ownership section is what to settle this week, before ship day.
The costs that continue
A build has a price. A running system has a monthly one, and it is made of four parts that are easy to underestimate separately and easy to forget entirely together.
Infrastructure. Compute, storage, database, network egress, backups. For a mid-sized internal business system this is often a few hundred to a few thousand dollars a month. It is usually the smallest of the four and it is the one everybody remembers.
Third-party services. Identity, email delivery, payments, mapping, monitoring, error tracking, and any model provider. These are priced per seat or per call and they scale with your success. Add them up before launch, because individually they all look trivial.
Keeping it current. Dependency updates, security patches, the language runtime that reaches end of life, the cloud service that gets deprecated with twelve months of notice. Doing this continuously costs a modest, predictable amount. Not doing it costs nothing for two years and then costs a rewrite.
People. Somebody answers questions, investigates the odd result, restores a record somebody deleted, and is reachable when something breaks at an inconvenient hour. This is the largest of the four and the one most often missing from the plan.
As a planning number, budget annual run-and-maintain at roughly 15% to 25% of the original build cost, before any new features. Lower if the system is small, stable and internal. Higher if it faces customers, integrates with several outside systems, or carries a model that needs monitoring. If a vendor tells you the number is zero, they mean somebody else is going to pay it.
Where post-launch effort actually goes — our read
Our judgment of where the first ninety days go, not a study. The point of the last row is that the code is rarely the problem.
Who owns it on day forty
This is the question to settle before ship day, in writing, and it is four questions wearing one coat.
Who is called when it breaks? A name, a channel, and a response time. “The vendor” is not an answer if the vendor's obligation ended at deployment. If there is an out-of-hours expectation, it needs to be stated and paid for; nobody is reliably available at 2am out of enthusiasm.
What counts as broken? Agree severity levels in plain language. Something like: everyone is blocked, some people are blocked, one workflow is degraded, cosmetic. Attach a response commitment to each. This one paragraph prevents most launch-period conflict, because the argument is almost always about whether a thing is urgent rather than about whether it is real.
Who can change it? Your team should be able to deploy a fix on the day the vendor relationship ends, whenever that is. That means the code lives in your repository, the pipeline runs in your accounts, and at least one person on your side has done a deployment with their own hands, before launch, as a test. An untested ability to deploy is not an ability to deploy.
Who is accountable for the outcome? Not the uptime — the outcome the project was funded for. Somebody on the business side should own the number the system was supposed to move, and should be reviewing it at ninety days.
What to have in place before ship day
- A named person on each side, with a response commitment in writing
- Severity levels defined in plain language, agreed by both sides
- Alerting that pages a human on the failures that matter, and nothing else
- Usage instrumentation per named user, live from day one
- A runbook covering restart, restore, roll back, and the three most likely failures
- A tested backup restore, performed once, with the elapsed time recorded
- A rollback path someone has actually executed, not just documented
- Credentials and account access held by you, not only by the vendor
- A hypercare window with a start date, an end date and a budget
- A ninety-day review on the calendar, against the outcome, not the feature list
The mistakes we see most
- Launch on a Friday, or the day before a holiday, or into a month-end close
- Everyone at once when a pilot group of ten would have found the same problems cheaply
- No usage measurement, so adoption failure is invisible for a quarter
- The old system switched off immediately, removing the fallback on the worst possible week
- Support undefined, so the first urgent issue becomes a contract negotiation
- Alerting on everything, which trains the team to ignore alerts within eleven days
- No named business owner, so nobody decides the small questions and they queue
- Change requests treated as defects, or defects treated as change requests
- The build team reassigned on launch day, taking every piece of context with them
The ninety-day review
Put it on the calendar before launch, because after launch nobody schedules it. It should be short and it should answer five questions honestly.
Is the number the project was funded to move actually moving? How many distinct people used the system last week, against how many were meant to? What are the three things users complain about, in their words? What does it cost to run per month, against what was budgeted? And what would break first if volume tripled?
The value of this review is not the answers. It is that asking them at ninety days is cheap, and asking them at eighteen months means the write-off conversation is already happening. We have seen more projects rescued by an honest ninety-day review than by any technical intervention.
Bottom line
The period after launch is predictable enough to plan for. Data surprises and permissions dominate the first three days. Defects peak in week one and fall off fast. Adoption, not correctness, is what decides whether the money was well spent, and it is invisible unless you instrumented for it before you shipped. Budget 10% to 20% of the build for a defined hypercare window and 15% to 25% of the build annually to run and maintain. Settle four ownership questions in writing before ship day. Do those things and the ninety days after launch are uneventful, which is the entire goal.
Frequently asked questions
Long enough to cover the defect curve and the first adoption signal, which in practice means two to four weeks of intensive coverage for a small system and four to eight for a large one, followed by a lighter arrangement through day ninety. What matters more than the length is that it is defined, staffed and priced. An open-ended promise to be responsive is worth roughly what it costs.
Rarely. A pilot group of ten to thirty users, chosen to include the least enthusiastic rather than only the volunteers, will surface most of what a full launch would surface, at a fraction of the blast radius. The main exception is a system where partial adoption breaks the data, such as a shared queue that only works if everyone is in it. In that case, launch fully but keep the old path available.
Later than feels necessary. Keep it readable for at least a full business cycle, which for most companies means a month-end and a quarter-end, so that anyone reconciling can compare. Turning it off early removes your fallback exactly when the new system is least proven, and it converts an inconvenience into an incident.
More than zero, and the count matters less than the mix. A first month dominated by data-shape issues, permissions and small usability fixes is a normal launch. A first month dominated by wrong calculations, lost records or intermittent failures nobody can reproduce indicates something structural, and the right response is to stop adding features and find it.
Only if something bad happens at night. For an internal system used in business hours, an agreed next-business-morning response is honest and much cheaper. For anything customer-facing or revenue-carrying, decide the tolerable outage window first, then buy the coverage that meets it. The expensive mistake is assuming out-of-hours coverage exists because nobody said it did not.