When a custom system goes live, the project ends. The software does not. It now runs alongside browsers that update themselves, cloud services that change their terms, third-party APIs that get retired, and a business that keeps changing what it needs. Keeping the system working through all of that is maintenance, and it is not optional.
We wrote the first version of this article in 2016. The categories have not changed. The examples have, and so has the way we think buyers should pay for it.
Why maintenance is not a sign something went wrong
Owners sometimes hear “maintenance” and assume the build was flawed. It was not, or at least that is not what maintenance means. Most of the lifetime cost of software comes after launch, for the same reason most of the cost of a building comes after the ribbon-cutting. The thing is in use. Use creates wear, and the world around it keeps moving.
A useful way to think about it: your custom application has dependencies you do not control. The operating system, the browser, the cloud provider, the payment processor, the accounting system it syncs with, the AI model it calls. Any of those can change on a Tuesday. Bottom line, bugs will happen, and not all dependencies are always known.
The four kinds of maintenance
Software people sort maintenance into four buckets. Knowing them helps you read a support report and understand what you are paying for.
Corrective
Fixing things that are not working as they should. This is what most people picture: a report that shows the wrong total, a form that fails on one browser, a job that did not run overnight. It also includes security patches for issues found after launch. Corrective work is reactive, and it is the reason response times matter.
Adaptive
Changing the software so it keeps working in an environment that changed around it. Examples from the last couple of years:
- A shipping carrier or payment provider retires the version of its API you integrate with
- Your accounting platform changes how it authenticates, and the nightly sync stops
- A mobile operating system update changes permissions and a feature quietly breaks
- The AI model behind a document-extraction step is deprecated and the replacement behaves differently
- The system needs to handle three times the users it was sized for after an acquisition
None of these are defects in the original build. All of them are work, and some of them are urgent.
Perfective
Improving the software’s internals without changing what it does. Refactoring a slow query so month-end reports run in minutes instead of hours. Cleaning up code that has been patched five times so the sixth change is easy. Upgrading a framework version before it goes out of support. This is the work that keeps future changes cheap, and it is the first thing that gets skipped when maintenance is underfunded.
Preventive
Fixing problems you can see coming. Adding two-factor authentication before a customer’s security questionnaire requires it. Rotating credentials and tightening access before an audit. Adding monitoring so the next outage is caught by a system, not by a customer. Archiving old data before the database gets slow. Preventive work rarely feels urgent and is nearly always the best money in the budget.
Where maintenance ends and new development begins
This line matters because it decides which agreement pays for the work.
Maintenance keeps the system doing what it already does, in a world that keeps changing. New development makes it do something it did not do before. A new module, a new customer-facing portal, a new integration that was never in the plan. Those are projects, and they get their own scope and their own budget.
The gray zone is adaptive work that requires real engineering. Moving to a new version of a platform can involve a lot of coding and testing even if the features stay the same. We handle that by being clear up front: small adaptive work comes out of the support hours, and anything large enough to need its own plan gets scoped and quoted as a project. You will know which is which before the work starts, not on the invoice.
There is also an upside in the gray zone. A platform change sometimes lets you delete code. When a provider adds a capability your application had to build itself, moving to theirs can shrink the thing you have to maintain.
How we price it
We keep maintenance simple and visible:
- Support is a bucket of reserved hours billed monthly, sized to the system. Response times are set by priority and written into the agreement before you sign. Each month you get a report of exactly what the hours went to.
- Managed hosting is cloud costs at pass-through plus a fixed monthly management fee. Monitoring, patching, backups, and recovery are run by the same engineers who build systems, and they are SOC 2 Type II.
- Anything bigger gets scoped as a project, on the same fixed-budget, controlled-scope basis as the original build.
The full description is on the Managed Hosting & Support page, and the pricing page shows how support and hosting sit alongside the typical budgets by type of project. We do not publish a rate card for support because a five-user internal tool and a platform serving 200 locations are not the same job. We size it after looking at the system.
How to budget for it
If you are planning a new build, the maintenance line should be in the plan before the build starts. Our VDP Sprint ends with an investment estimate for the first release and a view of what it takes to keep it healthy afterward. Do not accept a proposal that stops at launch.
What drives the number:
- How many external systems it integrates with, and how stable they are
- How many people depend on it and how bad an outage is
- Whether it faces customers or only staff
- Compliance and security obligations
- How much you plan to keep changing it
If a vendor tells you maintenance is a fixed percentage of the build cost, be skeptical. That formula is easy to quote and rarely matches the actual system.
If you inherited a system nobody maintains
A lot of the systems we support were not built by us. A platform the original vendor stopped answering emails about, an application whose developer left, something that came with an acquisition. The first step there is a System Evaluation, a fixed-fee look at the code, architecture, infrastructure, and security that ends in a written plan with the cost to stabilize it, extend it, or replace it. Then support and hosting can start on a system we actually understand.
The first step
If you are about to build, make sure the plan covers what happens after launch. If you already own a system and the maintenance is ad hoc, or nonexistent, book a 30-minute intro call and we will tell you whether a System Evaluation or a support agreement is the right place to start.