Project plans taper at go-live. Budget, attention, and the people who understand the system all reduce at precisely the moment the system meets real users, real data volumes, and real edge cases for the first time.
The first ninety days deserve to be planned as deliberately as the build.
Weeks one to two: nothing is normal yet
Expect a spike of issues that are not defects: confusion, missing permissions, and workflows people were trained on differently. Triage needs to distinguish these quickly, because treating training gaps as bugs generates rework nobody needed.
Keep the build team reachable. Nobody else can tell in five minutes whether something is broken or merely unfamiliar.
Weeks three to six: the real edge cases arrive
This is when the genuinely odd records surface — the account created in 2011 under rules that no longer exist, the customer with two addresses and one of them blank. Volume also finds the queries that were fine on test data.
Most true post-launch defects land in this window, and the fixes are usually small if the people who wrote the code are still available.
Weeks seven to twelve: behaviour becomes visible
Now there is enough usage data to see what people actually do rather than what was designed. Features that go unused, steps where people abandon, workarounds invented in spreadsheets — this is the most valuable product information the project will ever produce.
It is also routinely discarded because the team has moved on and nobody is looking.
Plan the handover as an activity
Whoever operates the system long-term needs runbooks, alert ownership, and access before day one, not after the first incident. Where support transfers to a different team, overlap them deliberately for several weeks rather than switching on a date.
A launch is the point at which a system starts being informative. Reserving capacity to act on what it tells you is the difference between a product that improves and one that is merely live.