
Software doesn't decay like hardware does, but it rots in its own way: dependencies age, security holes surface, OS platforms move, and the business outgrows what the code was built to do. A maintenance-and-support contract is how you buy your way out of that rot — and the difference between a good provider and a bad one is measurable in downtime, breach risk, and quiet invoices. This guide covers what to demand, what to pay, and how to tell them apart in 2026.
Quick Answer: Judge maintenance providers on six things: proactive monitoring, written SLAs, security discipline, transparent communication, scalability, and a continuous-improvement backlog. Expect corrective maintenance to cost roughly 15–25% of original development per year, and run every candidate through a paid pilot before committing.
First, know what you're buying
Software maintenance is conventionally split into four types, and any honest proposal should say which ones you're purchasing:
| Type | What it covers | Typical trigger |
|---|---|---|
| Corrective | Bug fixes, error corrections | Users find defects |
| Adaptive | Keeping software working as platforms change | OS, browser, API updates |
| Perfective | Improvements, refactoring, UX polish | User feedback, metrics |
| Preventive | Paying down technical debt before it bites | Architecture reviews |
Support (the help-desk side) rides on top: L1 triage, L2 investigation, L3 engineering fixes. A provider selling only "support" without the four maintenance types is selling a phone queue.
The six criteria that separate good providers

1. Proactive monitoring, not ticket reaction. The provider should operate uptime, error-rate, and performance dashboards — and surface problems before your users do. Ask what they monitor by default and how they alert. A provider who discovers your outage from your angry email is not doing maintenance.
2. SLA clarity, in writing. Response and resolution times by severity, measured how, with what remedies when missed. Watch for SLAs that measure "response" (an acknowledgment) rather than "resolution" (the fix). Business-hours-only coverage is fine for internal tools; production systems that trade across time zones need 24/7 — and that changes the price materially.
3. Security discipline. Patch cadence for dependencies, CVE tracking, and evidence on request — compliance reports, penetration-test summaries, secure-development practices. This bar rose in 2026: Europe's Cyber Resilience Act now makes security maintenance a legal obligation for products sold into the EU, and enterprise buyers increasingly audit their suppliers' patch processes. Ask a candidate how they'd handle a critical CVE in a library your app depends on — the specificity of the answer tells you everything.
4. Transparent communication. A named contact, a regular reporting rhythm (what changed, what broke, what's planned), and postmortems that admit causes rather than blur them. The tell: ask about their worst incident last year. Every serious provider has one and can describe what they changed because of it.
5. Scalability. The contract should survive your success: a cost model that scales with users or transactions, and capacity planning included, not billed as surprise re-architecture. Ask how the pricing changes if your user base doubles.
6. Continuous improvement. Maintenance shouldn't only be triage. A shared backlog of fixes and small improvements, reviewed with you each cycle, is what keeps the product's trajectory positive instead of merely alive.
What maintenance actually costs
Rules of thumb the software industry runs on — always verify against your own quotes:
- Corrective + adaptive maintenance typically runs 15–25% of original development cost per year. Below that, someone is skipping work that will surface later.
- Engagement models: time-and-materials (flexible, unpredictable), fixed-price per release (predictable, change-resistant), or a dedicated team (best for products under continuous evolution — usually the right call for active SaaS).
- 2026-specific: AI has genuinely lowered the cost of routine maintenance work — code review, test generation, dependency updates — and good providers pass some of that through as efficiency. Providers who claim AI eliminates maintenance costs are selling you the bug, not the fix: the work shifts toward architecture, security, and judgment, which is exactly what you should be paying humans for.
Providers: how to shortlist
The market splits into three lanes, and the right lane matters more than the logo:
- The original development team or agency, if available — deepest context, weakest independence. Start here if they hit the six criteria.
- Specialized maintenance firms — this is the core business for agencies like Amplework's maintenance-and-support practice and established names such as ScienceSoft or BairesDev (both have dedicated practices — check their current service pages directly, as their URLs move). Vet them on the six criteria, not their case-study page.
- Freelance senior engineers — cost-effective for small products, but check key-person risk: one person's holiday shouldn't be your downtime.
However you shortlist, keep our business cyber-attack protections in view during negotiations — access control, backups, and incident responsibility belong in the contract, not in an assumption.
The evaluation checklist before you sign
1. Paid pilot, 4–6 weeks: a real sprint of fixes against a staging environment. Judge responsiveness, code quality, and reporting — not the sales deck.
2. References at your scale: two customers whose product resembles yours in size and criticality, asked one question: "what happened the last time something broke at 2 a.m.?"
3. Knowledge-transfer plan: documentation, credentials, and code ownership defined so you can leave the provider without a hostage situation.
4. Exit terms: data return, source handover, transition support. Good providers write these proudly; bad ones stall.
FAQ
What's the difference between software maintenance and support?
Support is the reactive front line — tickets, help desk, user questions. Maintenance is the engineering discipline underneath — fixing, adapting, improving, and hardening the code itself. You need both, and the contracts should name both explicitly, because "support included" often means neither.
How much should I budget annually for maintenance?
Start from 15–25% of the original build cost per year for corrective and adaptive work, plus whatever perfective improvements you consciously fund. A product that generates revenue justifies the upper half of that range; an internal tool used by ten people may run leaner with a freelance arrangement.
Can AI tools replace a maintenance contract?
AI accelerates maintenance — dependency updates, test generation, first-pass code review — but it doesn't own outcomes. Someone must watch dashboards, decide trade-offs, take responsibility for security patches, and answer for incidents. Use AI-augmented providers; skip anyone selling AI as a reason you won't need them.
What SLA numbers are reasonable?
For a production B2B system: P1 (down) — response in 15–30 minutes, resolution target in 2–4 hours; P2 — response within an hour, resolution same business day; P3/P4 — scheduled into normal cycles. Demands beyond that are expensive to meet; offers below that for a revenue-critical product are a red flag.
Related reading
Judge every candidate on the six criteria during a paid pilot — the provider who looks best on a sales call and worst on a staging sprint is telling you which one you're actually hiring.

