A finished software project is not finished. It is deployed. From that day on it is a system the business runs on, and systems the business runs on need to be kept running. The companies that plan for this spend a modest, predictable amount every year. The ones that do not spend nothing for a while, and then a great deal all at once.
This is what maintenance actually is, how we price it, and how to know when it has stopped being maintenance.
Why software rots
Nothing in the code changes on its own. Everything around it does.
The operating system and the database get security updates, and eventually stop being supported. The libraries the system was built with release new versions, and old versions stop receiving fixes. Browsers change what they allow. The accounting platform you integrate with changes its API. The cloud provider retires a service. A regulation changes what you have to log. Your business changes what it sells, and the system’s assumptions quietly stop being true.
A system that nobody touches for three years is not stable. It is three years behind on every one of those fronts at once, and the first time you need to change it, you pay for all three years before you can make the change. That is why “it works fine, we haven’t touched it” is a warning sign to us, not a reassurance.
What maintenance actually includes
People hear “maintenance” and think “fixing bugs.” That is part of it. The full list is longer, and most of it is invisible when it is done well.
Keeping it secure. Applying security patches to the platform, the framework, and the dependencies. Rotating credentials. Reviewing access. For anyone with customers, insurers, or a sponsor, this is the non-negotiable part. We hold SOC 2 Type 2, and the systems we manage are kept to that standard.
Keeping it current. Updating the components the system is built on before they fall out of support, in small steps, so no single update is a project.
Keeping it running. Monitoring, backups, restoring from backups when needed, watching performance as data grows, responding when something breaks at two in the morning.
Keeping it fitting. Small changes as the business changes: a new field, a report tweak, a rule that changed when you added a product line, an integration that needs adjusting because the vendor changed something. Individually trivial. Collectively, the difference between a system people use and one they work around.
Keeping it known. Documentation, and a team that still understands how it works. This is the item companies skip and regret. If the only person who understands the system is gone, all the other items get expensive.
How we price it
Two parts, both predictable.
Reserved hours, billed monthly. You reserve a block of engineering time each month. It covers the updates, the small changes, the questions, and the fixes. Response time is by priority: an outage is handled now, a report tweak is scheduled. The block is sized to the system and how much the business changes, and it can be adjusted. What you are buying is a team that knows your system and is available, rather than a stranger on an hourly rate who has to learn it first.
Hosting at cloud pass-through plus a fixed monthly management fee. The cloud bill is what the provider charges, passed through without markup. The management fee is fixed and covers the monitoring, backups, patching, and infrastructure work that keeps the environment healthy. You see both numbers separately, and neither one surprises you.
This is what Managed Hosting & Support is. We offer it for systems we built and, after a System Evaluation, for systems we did not.
How much to set aside
We will not give you a percentage, because the honest answer depends on the system. But the shape of the budget is consistent:
A system that is core to operations, integrated with several other platforms, and changes with the business needs a meaningful monthly reserve. A simple internal tool that mostly sits there needs a small one. Neither needs zero.
Two things push the number up: integrations, because every connected system is a source of change you do not control; and business change, because a company that adds a product line every quarter needs its software to keep up. Two things push it down: a clean, well-documented codebase, and a system built recently on a supported stack.
If you want to sanity-check a number, typical budgets by type of project are on our pricing page, and the maintenance conversation is part of every proposal we write. For a new build, it starts in the VDP Sprint, where the roadmap includes what the system will need after the first release ships.
What happens when you skip it
A hypothetical, drawn from a pattern we see often. A manufacturer has a scheduling system built eight years ago by a contractor who has since moved on. It works. Nobody has touched it. Then the ERP vendor announces the old integration method is being retired in six months.
Now the company needs a change. But the framework the system runs on is four major versions behind, and the change needs a newer version. The database is on an unsupported release. Nobody has the deployment steps written down. The “small integration update” becomes a four-month effort to bring the system to a place where the update can be made, at a cost that would have covered years of maintenance. And it has a deadline.
That is what deferred maintenance looks like. It is not a bigger bill later. It is a bigger bill later, with a clock on it.
When maintenance becomes modernization
Maintenance keeps a good system healthy. It cannot make a bad one good. At some point the honest answer changes from “keep it up” to “replace it,” and it helps to know the signs.
- The cost of small changes keeps rising, because each one has to work around something old.
- Nobody can make a change without breaking something else.
- The platform it runs on is out of support, and the upgrade path is a rewrite anyway.
- The business has changed enough that the system’s core assumptions are wrong, not just its details.
- Finding people who can work in the technology is getting hard.
When a few of these are true, the right move is a System Evaluation: a fixed-fee look at the architecture, code, infrastructure, and security, ending with findings, a prioritized plan, and a fixed proposal for the next step. Sometimes that step is a targeted modernization of the worst parts. Sometimes it is a new system with a migration plan. Either way, you get to decide with the facts in hand instead of after the next emergency. There is more on the symptoms in When your custom software stops working for you.
The first step
If you have a system in production with no maintenance plan, the first step is not a budget. It is an inventory. What runs where, on what version, who can get into it, when it was last updated. An afternoon of questions to whoever knows.
If the answers worry you, book a Discovery Call. If they really worry you, we can start with a System Evaluation and give you a plan in a few weeks.