The case for operating what you build
There is a version of software work that ends at launch. You ship, you hand over the repository, you write a deployment guide nobody reads, and you move on. It is a clean business model and it produces a specific kind of engineer — one who has never had to live with their own architecture.
Day 400 is where the truth is
Most defects that matter do not show up in the first month. They show up when the database has enough rows to make a missing index hurt, when a background job that always finished in eight seconds starts taking nine minutes, when a customer's session outlives the assumptions the auth code was written under.
What operating changes about the engineering
Staying on the hook changes decisions upstream in ways that are hard to fake:
- You stop writing clever code. Clever is a liability at 2am. You write the boring version because you will be the one reading it under pressure.
- You instrument before you need to. Not because a best-practice document says so, but because you have once tried to debug a payment discrepancy with no logs.
- You treat data migrations as products. They get tested, staged and reversible, because you have been on the wrong side of one.
- You learn what your users actually do, which is almost never what the requirements said they would.
The honest counter-argument
Operating is expensive. It means capacity you cannot bill to a new project, an on-call rotation, and a slow accumulation of systems you cannot walk away from. Any agency that tells you otherwise has not done it.
The trade is that it makes one claim credible that nothing else does: that the thing still works. Not that it was delivered on time, or that it passed acceptance testing, but that it is running right now, today, with real money moving through it.
That is a different sentence from "we built this," and buyers can tell the difference.