Insights · 5 min read
Most teams budget for the build and forget the years after. A realistic look at software maintenance cost, what drives it, and how to keep it from climbing.
By GGP Editorial
Most project budgets stop at launch. The team plans the build, signs off on the scope, and goes quiet. Then month three hits: a payment provider changes its API, a framework ships a security patch, and a client reports a bug nobody can reproduce. Suddenly there is a monthly bill nobody planned for.
I have watched this happen across more than 300 projects at GlobeSoft. The build cost is a number people negotiate hard. The maintenance cost is a number they pretend does not exist.
A useful starting point is 15 to 20 percent of the original build cost per year. A $60,000 system will run you roughly $9,000 to $12,000 a year to keep it healthy. That covers the boring stuff: dependency updates, security patches, server and database care, small fixes, and the occasional change a customer asks for.
The table below is what we tell clients when they ask for a straight answer.
| System type | Annual cost as % of build | What the money goes to |
|---|---|---|
| Small web app or landing site | 10 to 15% | hosting, patches, minor fixes |
| Business system (CRM, ERP, POS) | 15 to 20% | fixes, integrations, compliance changes |
| Financial or payment software | 20 to 25% | security, audits, regulatory updates |
| Platform with many integrations | 20 to 30% | third-party API changes, scaling |
Financial software sits at the top for a reason. A payment provider changed its webhook format on a project of ours and the fix alone ate a week. That is not bad planning. It is just what the space costs.
One thing that surprises people is how much of the bill is not developers. Hosting, SSL certificates, backups, monitoring tools, and third-party subscriptions add up before a single line of code changes. On a mid-size system these can run $200 to $600 a month on their own, and nobody lists them in the original proposal.
It also helps to separate the work into three buckets. Corrective maintenance is fixing what broke. Adaptive maintenance is keeping the system working as the world around it changes, like an API update or a browser change. Perfective maintenance is the small improvements that keep users happy. The first two are unavoidable. The third is where you decide how fast the product actually improves after launch.
Five things move the price more than anything else.
The first is how many third-party services you touch. Every payment gateway, map provider, or email service you integrate is a small ticking clock. They update on their own schedule, not yours. One client of ours runs eleven integrations, and there is a small change to one of them roughly every month.
The second is the age of your stack. A system on a maintained framework with current versions is cheap to keep. A system running libraries that have hit end-of-life is a rewrite waiting to happen. We quote maintenance on an unsupported Node version higher than the same system on a current stack, because every change carries more risk.
The third is test coverage. Projects with good automated tests let a developer change code without breaking something else. Without them, every fix is a gamble, and the developer has to manually click through ten screens to feel safe.
The fourth is documentation. If the original team left a clean setup guide, a new engineer is productive in a day. If not, you pay someone to reverse-engineer their own codebase before they can change a single line.
The fifth is how you staff it. Hiring freelancers per issue costs more over a year than keeping a small ongoing team that already knows the system. Context is the expensive part of maintenance, and you pay for it again every time you bring in a stranger.
Most runaway maintenance costs come from a system nobody owns. The fixes are boring but they work.
Keep dependencies updated in small, regular steps rather than one painful migration every two years. Write the few tests that matter most, around payments, auth, and the one screen customers complain about. Put monitoring in place so you learn about a problem from a dashboard instead of from a client email. And keep one or two people who know the system on a retainer rather than re-hiring strangers every quarter.
There is a pattern we see a lot. A company lets its software sit for 18 months, then something breaks and they pay a premium for an emergency fix that could have been a $50 change if someone had caught it early.
Maintenance is not glamorous work, which is why in-house developers drift away from it. It is also the work where time zones stop mattering. A dedicated team can apply updates while your customers sleep and hand back a changelog in the morning.
We run maintenance for clients in Brazil, South Africa, Singapore and the US this way. There is a shared group for each project, overlapping hours for anything urgent, and communication in English or Portuguese depending on who is reading. The goal is simple: maintenance should be a predictable monthly cost, not a series of surprises.
Tell us what you are building and where you are today. We typically reply within 24 hours.
