Every enterprise technology conversation focuses on the build. Requirements. Features. Launch date. Budget. Nobody talks about day 366. Who updates the dependencies? Who fixes the bug when the external API changes its auth model? Who adds the report the CFO needs six months after go-live? Those answers determine whether a system lasts two years or ten. Almost never asked during procurement.
The Day After Launch
Launch day is a celebration. The system works. Users are trained. The project is done.
Except it isn't. From day one, the system starts ageing. Libraries release security patches. Browsers update. Regulations change. Users discover edge cases. The external systems it integrates with update their APIs. The business evolves and needs new capabilities.
60-80%
of total software lifecycle cost is spent on maintenance and evolution, not initial development
Source: IEEE Software Engineering Body of Knowledge (SWEBOK), 2014
Sixty to eighty percent. That number should dominate procurement conversations. It rarely gets a mention.
Three Maintenance Scenarios
The Vendor Disappears
It happens more than people admit. The agency that built the system moves on to other clients. The key developers leave. The SaaS vendor pivots or shuts down. Suddenly the organisation is left with a system nobody understands and nobody can modify.
We've been called in to take over systems where the original vendor is unreachable. The codebase has no documentation. The infrastructure credentials are missing. The deployment process exists only in someone's memory. Resurrection costs more than the original build.
The Internal Team Can't Cope
Some organisations plan to maintain systems internally. That's a valid strategy if the internal team has the skills and capacity. Often they don't. They were hired to keep the lights on, not to evolve a bespoke application. The system stagnates. Feature requests pile up. Workarounds multiply.
Nobody Planned For It
The worst scenario. No maintenance plan at all. The project budget covered the build and nothing else. The system works on launch day and slowly degrades as the world around it changes.
Questions to Ask Before You Build
Who will maintain this? Name the team or organisation. Not "we'll figure it out later." Now.
What are the ongoing costs? Hosting. Monitoring. Security patches. Dependency updates. Bug fixes. Feature requests. Get a realistic annual figure and budget for it.
Is the codebase maintainable? Can a developer who didn't build it understand and modify it? This isn't a nice-to-have. It's the difference between a living system and a legacy burden.
What's the handover plan? If the build team is different from the maintenance team, how does knowledge transfer happen? Documentation? Pair programming? A supported transition period?
What's the exit strategy? If the maintenance arrangement doesn't work, can you move to a different team or vendor without starting over?
What We Do
At RIVER, we build maintenance into every project conversation from the start. Not as an afterthought. As a core part of the discovery process.
We write code that's maintainable by design. Consistent patterns. Clear documentation. Tests that describe behaviour. Infrastructure that can be handed over.
And we're honest about what ongoing support looks like. It's not free. It's not optional. And it shouldn't be the last conversation. It should be one of the first.
The system you build is only as valuable as the system you maintain. Ask the maintenance question before you sign the contract, not after the launch party.