What does it cost to run custom software after launch?

Almost every conversation about custom software focuses on the build: what it costs, how long it takes, what it will do. Then the software launches and a different set of questions arrives, usually at an awkward moment. Who updates this? What happens when the payment provider changes its API? Is that monthly hosting bill normal? This is the part nobody scopes properly, so here it is in plain terms.

What are you actually paying for after launch?

"Maintenance" is a vague word covering five genuinely different things. Separating them is the only way to tell whether a quote is fair.

What it is	How often	What it actually covers
Hosting and infrastructure	Monthly	Servers, database, domain, backups, certificates. For a small internal system this is usually the smallest line on the list, sometimes a few thousand rupees a month.
Dependency and security updates	Quarterly	Patching the libraries and platform your software sits on. Unglamorous, invisible when done, and the single most important item here.
Integration repairs	Unpredictable	Fixing things when a connected service changes its API or authentication. Driven entirely by how many outside systems you depend on.
Small changes	Ongoing	A new field, an extra report, a tweak to an approval rule. Not bugs, just the business changing shape, which it always does.
Support and response	On demand	Someone who answers when a person cannot log in on a Monday morning, and an agreed time within which they respond.

Notice that only one of those five is genuinely optional. You can decline a change budget and live with the software as built. You cannot skip security updates without accepting a growing risk, and you cannot skip integration repairs if you want the integrations to keep working.

How much does software maintenance cost per year?

The long-standing industry rule of thumb puts annual maintenance at roughly 15 to 20 percent of the original development cost. Treat that as a rough heuristic rather than a law. It was formed around large, complex, business-critical systems, and it lands high for the kind of focused tool most growing businesses commission.

What actually moves your number is narrower than the rule suggests. A system with no outside integrations, running on managed hosting, doing one job well, can cost very little to keep alive: hosting plus a periodic update pass. The same system wired into four external services, a payment provider, and a government portal will cost meaningfully more, because every one of those is a moving part maintained by somebody else on their schedule. Integration count, not feature count, is the honest predictor. That is the same reason integrations dominate the build price too, as we set out in what drives the cost of custom software.

Integration count, not feature count, is the honest predictor of what software costs to keep running.

What should be in a support agreement?

If you are paying a monthly or annual retainer, it should say specifically what you get. The four things worth insisting on: a defined response time for different severities, so a system-down issue and a cosmetic one are not treated the same; a clear scope separating fixes, which should be covered, from new work, which should be quoted; a stated update cadence for dependencies and security patches; and backup arrangements, including how often backups run and whether anyone has ever tested restoring one. An untested backup is a hope, not a backup.

Be wary of the two failure modes. A retainer that quietly bundles unlimited changes will either be priced defensively high or quietly starved of attention. A pure hourly arrangement with no agreed response time means you are competing for attention with whoever shouts loudest that week. A small fixed monthly amount covering hosting, patching, and a defined response time, with changes quoted separately, is usually the honest shape.

What happens if your developer disappears?

This is the question people are too polite to ask on a first call, and it is a completely reasonable one to ask any supplier, including a small firm like ours. The honest answer is that it should not matter very much, and whether it does is decided long before anyone leaves.

Three things make a system portable to any competent developer. You hold the source code in a repository your business owns. You hold the credentials and accounts, with hosting, domain, and third-party services registered in your name rather than the supplier's. And there is written documentation covering how the thing is deployed and maintained. If those three are true, replacing your supplier is an inconvenience measured in weeks. If any one of them is false, you do not have a supplier, you have a dependency, and the cost of that shows up at the worst possible time.

This is why we treat handover as part of the job rather than an upsell, which is set out on how we work, and why ownership belongs in writing before a build starts rather than after, as covered in what should be in a software development contract. Ask any firm you are considering to confirm all three in writing. The answer tells you most of what you need to know.

Can you reduce what it costs to run?

Yes, and mostly through decisions made during the build rather than after it. Fewer integrations means fewer things that can break on someone else's timetable. Managed hosting costs slightly more per month and removes an entire category of server maintenance. Documentation written during the build, rather than promised afterwards, is what lets a second developer work on the system without an expensive rediscovery phase. And resisting features nobody asked for keeps the surface area small, because every screen built is a screen that must be maintained for as long as it exists.

The one thing that genuinely does not save money is deferring updates. Skipped patches accumulate quietly until the platform underneath is several versions out of date and the upgrade becomes a project rather than an afternoon. That is precisely the road that turns a working system into a legacy one nobody wants to touch. Integrations deserve the same watchfulness, since they break silently when a connected service changes, which is why we build in monitoring rather than assuming they run forever, a point we make in why your systems do not talk to each other.

Do you always need a maintenance contract?

No, and it is worth saying so plainly. A small internal tool with no external integrations, doing a stable job for a handful of people, may need nothing more than hosting and an occasional update pass. Paying a standing monthly retainer for that is not obviously good value. A system that takes payments, holds customer data, or connects to services outside your control is a different case, and going without cover there is a gamble you will eventually lose. The reasonable middle is a small arrangement covering hosting, patching, and a response time, with everything else quoted as it arises. If a supplier insists you need a large ongoing retainer for a simple tool, ask them to itemise it against the five categories above. More answers of this kind are in our FAQ, and you can see the systems we support in our case studies.