Maintenance is the product, not the afterthought

The standard shape of a software engagement puts all the attention before launch and almost none after it. There's a brief, a build, a demo, a handover call, and then — for most agencies — silence, unless something breaks badly enough to justify an invoice. The client is left holding a working system on day one and a slowly decaying one from day two onward, because nobody was ever contracted to notice the decay.

That model isn't dishonest, exactly. It's just built around the wrong moment. Launch is not when a piece of operator software proves its worth. The proof comes later, across every week it keeps working correctly while the business around it keeps changing.

Why "finished" is the wrong frame

Software that runs a business isn't a static artefact — it's closer to a piece of infrastructure that has to keep pace with everything happening around it. Payment providers change their APIs. Browsers deprecate features. The business itself adds a new pricing tier, a new market, a new regulation it has to comply with. None of that is a defect in the original build. It's just what happens to anything left running in the world for longer than a few months.

A handover-and-vanish engagement treats the day of launch as the finish line. But the operator experiences the build very differently: day one is simply the first day the thing has to keep working, unattended, against a world that hasn't agreed to stay still.

What actually breaks in the gap

• Dependency drift. Libraries and integrations age. Left unattended, a security patch that should have taken an hour becomes a rebuild.
• Content rot. Pricing pages, seasonal copy, terms — all correct at launch, all wrong within a year if nobody owns updating them.
• Silent failure. A form that stops submitting, an integration that quietly stops syncing — these often fail without an error message, because nobody built the monitoring to catch them.
• Knowledge loss. The one person who understood a particular integration moves on, and the documentation that should have survived them was never written.

Every one of these is invisible on launch day and completely predictable across the following year. Building without planning for them isn't neutral — it's quietly deferring cost onto the operator, disguised as a lower headline price.

What we mean by treating maintenance as the product

In practice, this means the handover isn't the end of the engagement's thinking, even when it's the end of the paid retainer. It means documentation written for the next person, not the one who built it. It means monitoring wired in before launch, not bolted on after the first outage. It means a clear, written answer to "what happens when this breaks and nobody from the build team is on the phone" — delivered at handover, not discovered during an incident.

A build that only works while the original developer is reachable isn't finished. It's a dependency wearing the shape of a deliverable.

None of this requires a compulsory retainer. Our position is the opposite: a retainer should be worth paying for because of what it actively does — content updates, feature extension, proactive monitoring — not because the alternative is a system engineered to quietly need you.

The retainer question, answered honestly

Most agencies default to a compulsory maintenance retainer bundled into the build, and most operators default to resenting it, because it's rarely clear what the retainer is actually buying beyond insurance against the developer's own build decisions. That structure creates a strange incentive: the less robust the original build, the more the retainer looks essential, and neither side benefits from being honest about that relationship.

The alternative we work to is separating the two questions entirely. The build should be robust enough to run unattended for a meaningful stretch without a retainer — that's simply what "finished" should mean. A retainer, where one exists, should be sold on what it actively adds: new features, content refreshed for the season, proactive monitoring reviewed monthly, optimisation work informed by real usage data. If a client can't articulate what they're getting for the monthly fee beyond "in case it breaks," that's a sign the retainer is compensating for something that should have been solved at build time instead.

Most of our clients take a retainer for the first few months after launch, while real-world usage surfaces the small adjustments every build needs once actual customers are using it, and then move to ad-hoc once things settle. That pattern only works honestly if walking away at month three doesn't leave the operator holding something fragile — which loops back to the same point: the build itself has to be the thing doing the heavy lifting, not the ongoing retainer.

What operators should ask for at handover

• Written documentation aimed at a future developer who wasn't in the original brief conversations.
• Monitoring or alerting for the failure modes that don't announce themselves.
• A named point of contact for the first ninety days, even without a retainer signed.
• An honest answer to what typically needs attention in year one, based on the technology chosen — not a vague reassurance that everything is future-proof.

The honest version of premium engineering isn't a system that never needs touching again. Nothing running in production ever reaches that state. It's a system built by people who planned for the touching, told you what it would look like, and made the ongoing relationship optional rather than structurally unavoidable.