There's a widespread fantasy in the software industry: the launch as a finish line. The team merges the code, the pipeline goes green, the product hits production, and someone opens something bubbly. Mission accomplished.
What nobody says out loud is that this moment — the deploy to production — is exactly when the real risk begins. Everything before it was, at best, a well-constructed hypothesis. From launch onwards, that hypothesis meets the real world: real users, real load, failures no staging environment can predict, and technical debt decisions that now carry immediate consequences.
The problem isn't that teams don't know this in theory. It's that the incentive system — deadlines, demos, quarterly roadmaps — is built to reward the launch and forget everything that follows. And that forgetting has a cost. It always does.
Most critical production failures aren't code bugs: they're the consequences of design decisions nobody revisited once the system was under real load.
Maintenance isn't a project phase; it's the longest, most expensive, and least planned phase of any digital product.
A product not designed to be maintained is a product designed to accumulate debt at exponential speed.
Launch Day: A Contract You Just Signed
When a product goes live, the team hasn't finished a job. They've signed a long-term contract with every user who just placed their trust in it. That trust isn't granted at sign-up; it's built — or destroyed — with every subsequent interaction.
The problem is that most teams plan for the launch as if it's the end of the project, when it's really the end of the rehearsal period. What follows — patching vulnerabilities, updating dependencies, responding to incidents, handling compatibility with third-party API changes, supporting real users with behaviors QA never anticipated — is the real work. And it's on nobody's roadmap.
A concrete example: in 2021, the Log4j library revealed a critical vulnerability (Log4Shell) that affected thousands of production systems. Most teams that had to patch in days had one thing in common: they didn't know exactly which versions of Log4j they were running or where in their stack. Not because they were negligent, but because nobody had built visibility into dependencies once the code was deployed. The launch had closed that conversation.
A product in production is a living system. Ignoring it after deploy doesn't make it more stable — it makes it more fragile, silently.
This connects directly to something we've argued about architecture and purpose: decisions made early, without fully understanding the problem, are the ones that hurt most when the system is under real pressure. Launch is the moment those decisions stop being theoretical.
Maintenance: The Work That Doesn't Fit in a Sprint
There's a persistent accounting illusion in how organisations budget software: resources go to development (the exciting phase, with wireframes and press kits) while maintenance is systematically undervalued. The industry standard ratio has been known for decades: between 60% and 80% of the total cost of a software system is spent after launch, on maintenance and evolution. Not building it. Sustaining it.
And yet, in most mid-sized companies we work with, maintenance has no dedicated budget. It lives parasitically inside development sprints, competing with new features — and always losing. The result is predictable: technical debt accumulates silently until something breaks at the worst possible moment.
The three types of maintenance nobody plans for
Not all maintenance is the same. Confusing them leads to bad prioritisation:
Corrective maintenance is what everyone recognises: fixing what's broken. It's the most visible and the most urgent. But if it's the only kind in your organisation, you're operating in permanent reactive mode — fighting fires instead of building systems that don't catch fire.
Adaptive maintenance is what few plan for: updating dependencies, adapting to changes in third-party APIs, ensuring compatibility with new platform versions. A mobile app that doesn't update its security dependencies every quarter ends up running libraries with known CVEs. An app that doesn't test against the latest iOS or Android versions ends up with one-star reviews at the worst possible moment.
Perfective maintenance generates the most long-term value and gets cancelled most often: improving internal architecture, reducing technical debt, refactoring modules that have grown beyond manageability. It adds no visible features. It has no date on the roadmap. But it's what separates a system that can evolve over five years from one that needs a full rewrite in two.
We've seen this dynamic repeat itself: teams that accelerate technical debt accumulation, convinced they'll "refactor when there's time." That time never comes if it isn't explicitly reserved.
Observability: Actually Seeing the System You Shipped
There's a question we ask systematically when auditing a product in production: do you know exactly what your system is doing right now? Not in staging. Not locally. In production, with the real users who are using it this moment.
The honest answer, in most cases, is no.
Observability — the ability to understand the internal state of a system from its external outputs — is not a premium feature you add when budget allows. It's the basic infrastructure that lets you manage a living system. Without it, maintenance becomes archaeology: you find problems by digging, after someone has complained.
The three classic pillars are logs, metrics, and traces. But real observability goes further: it means that when an incident hits production, the team can answer concrete questions within minutes. What changed? When did it start? What percentage of users are affected? Which code path is involved?
Datadog, Grafana, OpenTelemetry, Sentry — there are tools for every budget and stack. The problem is never tooling. It's organisational willingness to invest in visibility before the first serious incident happens.
Observability isn't for when something breaks. It's for knowing it hasn't broken yet.
The mistake of confusing uptime with health
A system can have 99.9% uptime and be in critical condition. If responses are taking twice as long as normal, if the silent error rate has crept up 15% over two weeks, if 40% of users are abandoning a key flow midway — none of these signals appear on the uptime dashboard. All of them are visible with properly configured observability.
Confusing "the system isn't down" with "the system is healthy" is one of the most common failures we see. It's what turns manageable problems into crises when they finally become visible. This is also at the root of what happens when you scale before you understand: symptoms amplify and the source gets lost.
Strategy: Designing for the Day After Launch
The solution isn't philosophical. It's structural. Teams that manage post-launch well don't have fewer problems than others — they have systems to detect them earlier, processes to resolve them faster, and budget to prevent them continuously.
Some concrete decisions that make the difference:
Incident runbooks before the first incident. A document describing the exact steps to respond to the most likely failures. It doesn't need to be exhaustive; it needs to exist and the team needs to know it.
Feature flags as infrastructure, not a trick. The ability to activate and deactivate functionality in production without a deploy reduces the risk of every release and lets you respond to problems in seconds instead of hours.
An explicit maintenance budget. If maintenance competes with features in the same sprint, it always loses. It needs its own time, its own budget, its own visibility on the roadmap.
Dependency reviews on a calendar. Monthly or quarterly depending on your stack's pace. Not reactive — not when there's already a critical CVE — but proactive, like an inventory check.
Blameless postmortems. When something fails in production, the goal isn't to find someone to blame. It's to understand what condition in the system allowed that failure to occur, and how to eliminate that condition.
None of these practices are new. Most have been in engineering handbooks for decades. The problem isn't ignorance — it's knowing they exist and lacking the organisational mandate to implement them, because the roadmap always has something more urgent.
That "something more urgent" is almost always the feature that should have been postponed to do things properly.
If you're at that point — a product in production built to launch, not to last — a technical audit is the first step. Not to judge what was done, but to map exactly what debt exists, what risk it represents, and what order of priority it demands. That map is what enables real decisions, instead of surviving sprint to sprint. That's the work we do at Room 714.
