· 2 min read · Delivery
Launch is when the product meets reality
A green test suite tells you the code does what you expected. The first week of production traffic tells you what it is actually for.
When a project goes live, the popular belief is that the hardest part is over. My first thought at launch has never been "we finally shipped". It is "is this actually working?"
The launch is not the finish line. It is the moment the product meets reality, and reality has properties your staging environment does not: real data shapes, real concurrency, and real people using the thing in ways nobody wrote a test for.
What I do in the first 48 hours
I do not stop at the deploy. I watch production data, read the logs, and follow how the system handles its first real users — not aggregate dashboards, but individual requests through the paths that matter. A green test suite says the code does what I expected. It says nothing about what users will actually do with it.
The things that surface in the first two days are rarely the things I worried about. Queries that were fast against seed data meet a table with a realistic distribution. A background job that never queued in testing develops a backlog. A form that two developers filled in correctly meets a hundred people who fill it in every other way. None of this is a failure of testing; it is the part testing cannot reach.
Evaluation measures what you thought to ask
This is sharper with AI systems, where I build evaluation harnesses as a matter of course — golden datasets, regression tests, tracing on every call. Those are genuinely valuable and I would not ship an agent system without them. But a golden dataset contains the questions I thought to write down. Real users ask the ones I did not, in phrasings I would not have invented, about edge cases I did not know existed.
So the evaluation suite tells you the system has not regressed. The first week of production traffic tells you what it is actually for.
Build for the day after
Which is why monitoring, structured logs and error tracking go in before launch rather than after the first incident. Not as a checklist item — because the first forty-eight hours are the highest-information period a system ever has, and you only get to read them if the instrumentation was already there.
Launching is not the end of the work. It is the first time the work gets marked by someone other than me.