There is a version of this studio that ships a repository, invoices, and moves on. It is a perfectly honest business. It is also a business that never finds out which of its decisions were wrong, because the bill for them arrives at somebody else's address.
The feedback loop only closes in production#
A code review tells you whether something is defensible. Three months of running it tells you whether it was right. The gap between those two is where most of what we know now came from.
- Retries that hide bugs
A retry around a flaky call looks responsible in review. At 3am it is the reason a broken payload silently triples in volume instead of failing loudly once.
- Logs nobody can act on
“Failed to process request” passes review. On call it is worthless. We now review log lines by asking what the reader is supposed to do next.
- Migrations with a human in them
A two-step migration is fine when someone is watching. If it cannot finish unattended, it is not a migration — it is a maintenance window with better branding.
What owning the pager actually means#
- One number, one person. A rota with two people on it and a documented escalation. No shared inbox pretending to be on-call.
- A runbook per alert. An alert that has no runbook gets one or gets deleted. There is no third option, because an alert nobody knows how to answer trains people to ignore alerts.
- A monthly review. Everything that paged, and what it changed. If an alert fired three times and changed nothing, it was noise wearing a uniform.
The honest cost#
It is not free and we do not pretend otherwise. Carrying operations means a slower project cadence, a rota that has to survive holidays, and turning down work that would leave nobody to answer the phone. Small studios usually skip it for exactly those reasons.
What we get back is a shorter argument. When a client asks why a piece of work costs what it costs, the answer is not a theory about maintainability — it is a list of the things that paged us on the last system that skipped it.