Budget roughly 15–25% of the original build cost every year to keep custom software healthy, as a typical range that varies with scope. So a US$40,000 platform usually needs about US$6,000–10,000 a year for fixes, updates and support. Hosting, paid third-party services and new features sit on top of that figure, so plan them separately.
Many owners treat launch day as the finish line. In practice it is the point where the software starts doing real work, meeting real data and real users, and where the running costs begin.
What does software maintenance actually pay for?
Maintenance is the work that keeps existing software safe, working and compatible; it is not the same as building new features. Engineers usually split it into four kinds:
- Corrective: fixing bugs that slipped through testing or appear with real-world data.
- Adaptive: keeping up with the outside world. Browsers update, phone operating systems change, payment gateways and APIs retire old versions, and your code must follow.
- Preventive: updating frameworks and libraries, applying security patches, checking backups and tidying code before small problems become big ones.
- Perfective: small improvements to speed, usability or reports that users ask for once they live with the system.
The first three are non-negotiable. Skip them and the software slowly breaks, even if nobody touches it. The fourth is where you have the most control over spend.
How much should I budget each year?
Take the build cost and apply 15–25%. Use the lower end for simple, stable tools with few integrations; use the upper end for customer-facing products, mobile apps and anything connected to many outside services.
Here is how that works out against the typical global build ranges we see. These are estimates, not quotes; your scope decides the real number.
| Type of software | Typical build cost (USD) | Annual maintenance at 15–25% (USD) |
|---|---|---|
| Simple internal tool or automation | $6k–20k | about $900–5,000 |
| Custom CRM | $20k–90k | about $3,000–22,500 |
| AI chatbot on your own documents | $10k–40k | about $1,500–10,000 |
| MVP web app or SaaS | $15k–50k | about $2,250–12,500 |
| Cross-platform mobile app (simple–mid) | $25k–90k | about $3,750–22,500 |
| Mid-size web platform or SaaS | $50k–150k | about $7,500–37,500 |
For India-based projects the same percentage applies to rupee budgets: a ₹10 lakh build typically needs ₹1.5–2.5 lakh a year. Mobile apps carry extra platform churn from Apple and Google, which our guide to mobile app maintenance costs covers in more depth.
Which costs are not included in that percentage?
The 15–25% covers people's time on existing software. Running costs and new work need their own lines. When you build your annual budget, list these separately:
- Hosting and infrastructure: servers, managed databases, storage, backups and data transfer. Our comparison of AWS, Google Cloud, Azure and VPS hosting explains what drives that bill.
- Third-party services: transactional email, SMS and WhatsApp messaging, maps, payment-gateway fees, error monitoring and analytics tools.
- AI usage: if the software calls a language model, you pay per use, and that grows with your users.
- Licences and store fees: app store developer accounts, paid plugins, fonts or component libraries.
- Domains and certificates, if not already bundled.
- Security reviews: an occasional independent penetration test for software that handles payments or sensitive data.
- New features: the roadmap. Price these as small projects, not as maintenance.
A useful habit is a simple spreadsheet with three columns: fixed monthly costs, usage-based costs, and planned feature work. Review it every quarter.
Should I choose a retainer, pay-as-you-go or an in-house developer?
The right model depends on how critical the software is and how often it changes.
- Monthly retainer: a fixed number of hours or a fixed scope each month, with agreed response times. Best for business-critical systems such as a CRM, booking platform or customer portal. You get predictable cost and someone who knows the code.
- Pay-as-you-go: you pay an hourly or per-task rate when something comes up. Fine for simple, stable internal tools, but response can be slow when you most need it, because nobody has reserved time for you.
- In-house developer: worthwhile once there is enough continuous work to fill a full-time role, and you can keep that person challenged. One developer is also a single point of failure, so documentation still matters.
Many growing businesses mix them: a light agency retainer for security patches, backups and urgent fixes, with feature work quoted separately.
What should a support agreement include?
If it is not written down, assume it is not included. A good support agreement or service-level agreement (SLA) answers:
- Response times by severity. For example, "system down" within hours, "minor bug" within a few working days.
- Support hours and time zone, which matters if your team is in Australia and your developer in India or the USA.
- What counts as maintenance vs new work, with examples.
- Update cadence: how often frameworks, libraries and the server are patched.
- Backups: frequency, retention and how often a restore is actually tested.
- Monitoring: who watches uptime and errors, and who gets the alert at 2am.
- Unused hours: whether they roll over or expire.
- Exit terms: handover of code, credentials and documentation if you change supplier.
How can I keep maintenance costs down?
You keep maintenance cheap mostly through decisions made during the build. Once the software is live, consistency matters more than heroics.
- Pay for automated tests. They let developers update libraries with confidence instead of fear, which keeps patching quick.
- Choose mainstream technology. Popular frameworks have long support windows and plenty of developers who can take over.
- Update little and often. Skipping two years of updates turns a routine afternoon into a risky mini-project.
- Keep documentation current: setup steps, architecture notes and a list of every third-party account.
- Resist "just one more" custom tweak. Each special case is code that must be maintained forever.
- Pay down shortcuts deliberately. Rushed code accumulates interest; our explainer on what technical debt costs a business shows how it shows up in maintenance invoices.
- Right-size hosting. Over-provisioned servers are money spent on idle machines.
Is year one more expensive than later years?
Usually, yes. The first few months after launch surface edge cases, real-world data quirks and quick usability fixes that testing could not predict, so set aside a little extra in year one. Many good agencies include a warranty period for defects in their own work. After that settling period, costs tend to stabilise unless you keep adding integrations.
From year three onward, watch for a different pattern: rising cost to make small changes. When simple requests keep taking longer, it is a signal to review the architecture, not just to keep paying. Our custom software development guide covers when a refactor or rebuild makes more sense than patching.
Frequently asked questions
Can I skip maintenance if the software works fine?
You can for a while, but risk builds silently. Unpatched libraries attract security problems, and outside services such as payment gateways eventually retire the versions your software depends on. The bill for a rushed emergency fix is almost always higher than steady upkeep.
Is a warranty period the same as maintenance?
No. A warranty covers defects in the work as delivered, usually for a fixed period after launch. Maintenance covers ongoing updates, compatibility changes and support that nobody could have delivered at launch.
Why is the percentage higher for mobile apps?
Apple and Google update their operating systems and store requirements every year, and apps must keep up to stay listed and working well. That adds recurring adaptive work that a web-only internal tool rarely needs.
How do I compare maintenance quotes from different agencies?
Line them up on the same questions: hours included, response times, update cadence, backup testing, monitoring and exit terms. A cheaper quote that excludes security updates or monitoring is not actually cheaper.
Should maintenance be included in the original contract?
Ideally it is quoted alongside the build, so you can see the total cost of ownership before you commit. Signing the support agreement before launch also avoids a gap where nobody is responsible.
Plan the running costs before you build
Agreeing the maintenance plan alongside the build budget avoids unpleasant surprises in year two. Want a fixed-price build quote with the first year of support costed up front? Start a conversation with our team, or browse our development services to see what we look after once software is live.