Fig. 16 — After launch
Product support
Launch is where the work changes, not where it stops. Two things keep a product alive: someone answering when it breaks, and someone changing it before it has to break.
When something breaks
Incidents are answered, not queued behind feature work. What matters more than a response time on a page is that the people answering know the system — the same engineers, the same deploy pipeline, the same rollback they set up before the first release.
- A defined path from report to fix, not an inbox someone checks
- Rollback available as a first response, so a bad release is minutes rather than hours
- Logging and health checks that show what happened instead of inviting a guess
- The cause written down afterwards, so the same incident does not arrive twice
Planned updates
Most of what breaks a healthy product is neglect: dependencies age, platforms deprecate, certificates lapse, a library stops receiving security fixes. Planned work keeps those from becoming incidents — upgrades taken deliberately, in daylight, with the test suite and staging to catch what moved.
- Dependency and platform upgrades on a schedule, not on an outage
- Security patches applied when they ship, not when they are exploited
- Changes verified in an environment that mirrors production before they reach it
- Small, frequent releases — the cheapest kind to reverse
Products we did not build
Taking over someone else's codebase starts with reading it, not with a quote. We look at how it deploys, how it is tested and what it depends on, then tell you what shape it is in — including when the honest answer is that a rewrite costs less than the upkeep.