Software maintenance cost: what your budget should cover
Estimate maintenance for an existing web app or SaaS: separate takeover, upkeep, support and feature work, then compare what each quote includes.
Paul BădărăuSoftware maintenance cost depends on the system you have and the responsibility you want someone to take. A useful budget separates the work needed to take over the application, the recurring work that keeps it dependable, and the changes you want to ship.
If you are comparing providers, ask each to price the same scope. A monthly figure that excludes deployment, dependency updates, and incident investigation cannot be compared with one that includes them.
Start with the application, not a percentage
The original build price does not tell a new provider whether your backups restore, your dependencies are supported, or your payment integration fails quietly. Before treating any estimate as a commitment, establish what runs in production and which parts need attention.
Write down:
- What the application does and which workflows matter most.
- Whether it is a web app, SaaS product, API, or internal system.
- The runtime, framework, database, and hosting, if known.
- Who can access the repository, deployments, and provider accounts.
- Recent failures, deferred updates, and the next planned changes.
- The hours when the business needs support and who handles urgent incidents.
If the original developer has left, use the codebase takeover checklist to identify missing access and knowledge. You can collect this information without choosing a new provider first.
Separate four parts of the budget
1. Initial takeover and stabilization
A new team needs to understand production, check access, establish a repeatable deployment, and verify recovery. Missing documentation or an unsupported framework can add work before normal maintenance begins.
Ask what the initial scope delivers and what would trigger a revised estimate. Keep it separate from the ongoing monthly commitment so both parties can see the cost of inheriting the system.
2. Recurring upkeep
List the planned work: dependency and security updates, release checks, backup restoration tests, monitoring, and operational documentation. Agree how often each happens and what evidence you receive.
Hosting, database, email, and other provider bills belong in the operating budget too. State whether you pay those directly or through the maintenance provider. Engineering time and infrastructure bills are different costs.
3. Support and incident work
Specify the coverage hours, time zone, contact route, and what counts as urgent. Response time means someone starts assessing the problem; it does not mean the problem is resolved within that time.
For a US or Canadian business using a remote team, discuss overlap explicitly. Do not assume a monthly maintenance arrangement includes overnight or weekend response.
4. Planned improvements
Separate bug fixes from changes to how the product works. A new integration or a large workflow change needs a scope, even when the same team does both maintenance and development.
Agree how work is prioritized, how estimates are approved, and what happens when the month contains more work than the available capacity. That discussion matters more than the label on the package.
A budget worksheet you can send to providers
Fill in these lines before comparing quotes:
- Initial work: access gaps, deployment setup, recovery checks, and urgent repairs.
- Recurring engineering: tasks, frequency, and capacity included.
- Provider bills: hosting, database, email, monitoring, and other services.
- Support: coverage hours, response expectations, and incident scope.
- Product changes: priorities and a separate approval path.
- Uncertainty: areas the provider must inspect before committing.
For each quote, ask the provider to mark what is included, excluded, or not yet known. Ask how unused capacity and work above the agreed scope are handled. Do not assume either rolls over or is automatically billable.
When a low quote leaves work uncovered
A provider may reasonably offer a narrow service. The risk is a gap nobody owns: application support without dependency upgrades, monitoring without a person receiving alerts, or backups without a restoration check.
Ask who is responsible for each gap. You might keep a task internally, hire a specialist, or include it in the maintenance scope. The useful outcome is explicit ownership.
Repair, modernization, or ongoing maintenance?
If the application is supported and easy to deploy, recurring upkeep may be enough. If a framework upgrade, deployment repair, or data migration is needed first, scope that work separately.
Our repair or rewrite guide helps distinguish targeted work from replacement. The maintenance budget should reflect that decision rather than hide a modernization project inside routine upkeep.
Discuss maintenance for your application
AL+ provides software maintenance services for existing web applications and SaaS products, including systems built by another developer or agency.
Email paul@alplustech.com about software maintenance. Describe the application, its stack if known, your country, the current problem, and the support hours you need. Send a description first; keep passwords, API keys, and customer data out of the email.