Why I Always Push for Ongoing Maintenance, Even When Clients Say No
Long-term client relationships taught me that skipping maintenance saves money today but creates expensive headaches tomorrow.
I’ve been building backend systems and custom software for clients for over a decade. One pattern shows up again and again in long-term partnerships: a project goes quiet for a year or more, then the client comes back with new feature requests. Everyone is excited to move forward, until we try to start work.
There are two very different ways this can go.
The Good Scenario: Someone Kept the Project Alive
The good scenario is when the original plan included a small prepaid monthly maintenance retainer. Even if no new features were being built, we kept an eye on the project. That meant:
- Applying security patches as soon as they are released
- Updating dependencies to stay compatible with new versions of languages, frameworks, and servers
- Running the application regularly in our development environments
- Deploying small fixes or configuration changes to production when needed
When the client came back, we could pull the code, start it locally in minutes, and begin planning new features that same week. The project remained healthy and ready.
The Worst Scenario: The Project Was Left Running Without Care
More typical is the client who declines ongoing maintenance. “We’re not changing anything. Why keep paying every month?” It sounds reasonable. Pausing the fee feels like smart saving. But time doesn’t stand still for software, just not the way most people think. The code itself isn’t like milk. It doesn’t spoil on its own. The files you wrote years ago are still the same bits on disk if left untouched. What moves forward without pause is the entire ecosystem around the code.
Languages release new versions and deprecate old syntax. Libraries receive critical security fixes and eventually drop support for older runtimes. Operating systems, cloud platforms, and databases evolve, sometimes breaking backward compatibility in subtle ways. Installation tools change commands or disappear altogether.
None of this waits for your project. When you return after a long break, the application suddenly finds itself in a world that has quietly shifted beneath it. That’s when the unplanned work starts: not the new features the client wants, but first getting the old code to run again in today’s world.
Stories from the Trenches
I’ve lived this many times. Teams spend days (sometimes weeks) just trying to reach the point where we can begin the requested work. We chase down ancient error messages, pin obsolete package versions, patch broken integrations, or rewrite setup scripts from scratch.
Right now, I’m several days into upgrading an old Node.js and MongoDB application that sat untouched for years. Both technologies reached end-of-life in their old versions, so I’ve had to touch nearly every corner of the codebase. Once the upgrade finishes, a full regression test cycle will be required before we can safely add anything new.
None of this is cheap. Those revival hours get billed at full rate, often exceeding what the monthly retainer would have cost.
Even though we developers don’t particularly enjoy routine maintenance work, it’s not the exciting part of building new things. But we do it anyway, because we know, from challenging experience, that it pays off later. Skipping it means paying more (in time and frustration) when the project wakes up again.
I don’t believe every project needs constant heavy attention. But a light retainer, even a handful of hours per month, is enough to keep things current, secure, and runnable. Think of it as changing the oil in your car: ignore it long enough, and you’ll pay far more when the engine seizes.
A Word of Caution for Clients
If you decide to pay for ongoing care, treat it like any other service: ask for a short monthly summary. What vulnerabilities were checked? Which dependencies were updated? Was the application started and tested? A simple bullet-point email or a quick shared document is enough. Good partners won’t mind, in fact, they’ll welcome the clarity. It keeps everyone honest and ensures you’re truly getting the protection you’re paying for.
My Unpopular Opinion in the Industry
In our industry, treating maintenance as optional is shortsighted. Software isn’t a physical object you can box up and forget. It exists inside a living, changing ecosystem. If you want it ready when you return, someone has to keep it breathing.
Maintaining something is almost always cheaper than reviving it.
