Most budgets for a new software product end at launch. The build is scoped, quoted and paid for, the product goes live and everyone relaxes. Then, a few months later, a security update is needed, a browser changes, a payment provider alters its rules, users ask for improvements, and nobody has set aside time or money for any of it.
Software is not like a building that stands once it is finished. It is closer to a vehicle: it needs regular servicing, occasional repairs and periodic upgrades, and skipping them does not save money, it only postpones a larger bill. This guide explains what maintenance actually covers, what it tends to cost, how to budget for it, and how to keep it under control. It is written for founders and business owners, not just developers, and complements our custom software cost guide, which focuses on the build.
Why software needs maintenance at all
Code does not wear out, but everything around it changes.
- Security threats evolve. New vulnerabilities are found in frameworks, libraries and servers all the time, and patches need applying.
- Platforms move on. Browsers, phone operating systems, databases and programming languages release new versions, and old ones lose support.
- Third-party services change. Payment, email, maps and shipping providers update their interfaces and retire old ones.
- Users behave differently. Real use reveals problems and opportunities that planning never predicted.
- Your business changes. New products, pricing, regulations and processes need to be reflected in the software.
- Data grows. A system that was fast with a hundred records can slow down with a million.
Ignoring these does not freeze the product. It lets it decay.
The four types of maintenance
Maintenance is not one thing. It helps to separate it into four kinds, because they have different urgency and cost.
1. Corrective maintenance: fixing problems
Bugs appear in any software once it meets real users and real data. Corrective work fixes them. Some are minor annoyances; some, such as a broken checkout, are emergencies. A good agreement defines how quickly different severities are handled.
2. Preventive maintenance: staying healthy
This is the dull but valuable work that prevents future failures: updating dependencies, applying security patches, monitoring performance, checking backups, renewing certificates and cleaning up technical debt before it grows. Preventive maintenance is cheap compared with the emergency it avoids.
3. Adaptive maintenance: keeping up with change
When the environment changes, the software must adapt. Examples include supporting a new operating system version, moving to a new payment API, updating to a new framework release or complying with a new regulation.
4. Perfective maintenance: improving
Small improvements and new features based on user feedback: better workflows, clearer screens, faster reports. This overlaps with ongoing development, and it is where much of a product's long-term value is created.
How much should you budget?
There is no single figure, but there is a useful planning guideline. Many teams set aside roughly 15 to 20 percent of the original build cost per year for maintenance and small improvements. A product that cost $40,000 to build might therefore need $6,000 to $8,000 a year to keep healthy.
Treat that as a starting point, not a rule. The right amount depends on several factors.
| Factor | Pushes the budget up | Pushes the budget down |
|---|---|---|
| Complexity | Many integrations and modules | Focused product, few dependencies |
| Users and traffic | Many users, high availability needs | Small internal tool |
| Pace of change | Active roadmap and frequent releases | Stable requirements |
| Security needs | Sensitive data, regulation | Low-risk data |
| Platform | Mobile apps on several platforms | A single web application |
| Code quality | Older, undocumented, untested code | Clean, tested, documented code |
Well-built software costs less to maintain. This is one of the strongest arguments for paying for quality at the start: tests, documentation and clear structure reduce every maintenance bill that follows.
What is usually included in a maintenance plan
A sensible support agreement covers some or all of the following.
- Hosting and infrastructure. Servers, databases, storage and monitoring, either included or billed separately.
- Security updates. Applying patches to the framework, libraries and server.
- Backups and recovery. Regular backups and proof that they can be restored.
- Monitoring and alerts. Knowing when the system is slow or down, ideally before users tell you.
- Bug fixing. Corrective work within agreed response times.
- Small changes. A set number of hours for minor improvements.
- Compatibility updates. New browser, operating system or service versions.
- Reporting. A short summary of what was done and what is coming up.
Ask any vendor exactly what is covered and what is billed separately. Vague "support" promises are a common source of disputes.
Running costs that are not developer time
Maintenance includes recurring bills that have nothing to do with code. Plan for:
- Hosting. Cloud servers, databases, storage and bandwidth, often billed monthly or by usage.
- Third-party services. Email and SMS delivery, payment fees, mapping, search, analytics and error tracking.
- Domain names and certificates.
- Developer accounts. Apple and Google charge for app store access.
- Licences. Some tools, plugins or components carry annual fees.
- Monitoring and security tools.
These often grow with usage, which is good news, since growth usually means revenue, but they should not be a surprise.
What happens when you skip maintenance
It is tempting to treat maintenance as optional. The consequences tend to arrive all at once.
- Security incidents. Unpatched software is the easiest target. A breach costs far more than the patches would have.
- Sudden breakage. A provider retires an old interface or a browser update breaks a feature, and the fix is urgent and expensive.
- Technical debt. Small shortcuts accumulate until even simple changes take long and risk breaking something.
- Forced rewrites. Software left long enough becomes too outdated to upgrade, and the only option is rebuilding.
- Lost knowledge. When nobody touches the code for a year, nobody remembers how it works.
- Declining user trust. Slow, buggy or outdated products lose customers quietly.
Regular small investments almost always cost less than occasional large rescues.
Ways to keep maintenance costs down
You cannot avoid maintenance, but you can make it cheaper.
- Insist on quality at the start. Automated tests, clear structure and documentation pay back every year.
- Use mainstream technology. Popular frameworks such as Laravel have long support, large communities and clear upgrade paths, and developers are easy to find.
- Keep dependencies few and current. Every library you add is something you must update. Small, regular upgrades are far cheaper than a giant leap after years of neglect.
- Automate what you can. Automated deployments, tests and monitoring reduce human effort and error.
- Own your code and documentation. You should be able to change vendors without starting again; see how to choose a software development company.
- Watch the performance early. Small database and query problems are cheap to fix before they become big. We describe typical issues in signs your Laravel application needs a technical review.
- Retire what you do not use. Unused features still need maintenance. Remove them.
- Plan releases. Batching updates is cheaper than constant small interruptions.
Choosing a maintenance arrangement
There are three common ways to organise ongoing support.
Retainer. A fixed monthly fee for an agreed amount of time and a defined response level. Good for predictable budgets and ongoing small improvements.
Pay as you go. You pay for work when it is needed. It is flexible but leaves you exposed if something urgent happens and the team is busy.
Dedicated team or developer. For products with a busy roadmap, a continuing team handles both maintenance and development. See hire a dedicated software team and our comparison in dedicated team vs freelancers vs in-house.
For small products, a modest retainer is often the sweet spot: it guarantees someone who knows the code is available, without paying for idle time.
Mobile apps: extra considerations
Mobile apps have a few additional maintenance drivers.
- Yearly operating system releases. Apple and Google update their systems every year, and apps need checking and sometimes changes.
- Store rules. Policies and required assets change, and apps that fall behind can be removed.
- Many devices. New phones and screen sizes appear constantly.
- User updates. Not everyone updates promptly, so old versions must keep working.
These are part of the reason app maintenance sits at the higher end of the budget range. Our article on mobile app development cost covers the wider cost picture.
How to estimate your own maintenance budget
A simple approach:
- List the recurring bills: hosting, services, licences, accounts. Add them up per month.
- Estimate preventive work: updates, patches and checks. A few hours a month is typical for a small application.
- Allow for fixes: base this on the product's size and complexity.
- Allow for improvements: decide how much change you expect each quarter.
- Add a contingency: around 10 to 20 percent for the unexpected.
- Compare with the 15 to 20 percent guideline as a sanity check.
Review the figure every year. Good products usually need more attention as they grow.
Questions to ask a vendor
- What exactly does the support agreement include?
- What response times do you commit to for urgent problems?
- Who handles hosting, and is it included?
- How do you handle security patches and framework upgrades?
- What happens if the person who built it leaves?
- How is documentation kept up to date?
- Can I see a sample report of work done?
- What would you recommend we budget each year, and why?
Final thoughts
Software that is cared for keeps working, stays secure and grows more valuable. Software that is neglected slowly becomes a liability. The difference is usually a modest, regular budget set aside from the beginning, not a heroic rescue later.
If you have a product that needs looking after, or you are planning one and want the running costs mapped out from day one, get in touch. We will tell you what a sensible maintenance plan looks like for your product, and what you can safely leave out.