Support after launch: what a maintenance contract should cover
Launch is the start of a software system's life. The nine things a maintenance contract must cover, and the ones most often missing.
The short answer
Launching custom software is the beginning of its life, not the end of the project. From that day, everything around it changes while it stands still: the platform, the dependencies, the browsers, the vendors it integrates with, the data volume, the business itself. Without maintenance it decays within a year, and the decay is silent until an integration breaks or a vulnerability is exploited. A maintenance contract for software covers nine things, broader than one for a website because there is data, integrations, background jobs and users to keep working. The items most often missing from contracts are the restore tests, the retests after platform updates and a defined change budget.
The nine items
| Item | What it covers | Cadence |
|---|---|---|
| 1. Monitoring and response | Uptime, errors, performance and business signals watched; alerts to a person; a severity table with response times | Continuous; incidents as they occur |
| 2. Updates | Dependencies, framework, platform, with security fixes within days | Monthly, security immediately |
| 3. Security | Advisory monitoring, secret rotation, access reviews, periodic scans | Monthly; scan yearly or on change |
| 4. Backups and restore tests | Backups verified; a restore to a fresh environment performed and timed | Quarterly restore test |
| 5. Performance | Real-user timings watched; slow screens traced and fixed; budgets kept | Monthly review |
| 6. Small changes | A change budget for fields, reports, tweaks, with request and approval | Monthly, reported |
| 7. Documentation | Setup, runbook, integrations and decisions kept current with every change | With each change |
| 8. Vendor changes | API deprecations, model updates, terms changes read and acted on; retests after updates | As announced |
| 9. Reporting | A monthly report with numbers for all of the above | Monthly |
What is usually missing
- Restore tests. Backups exist; nobody has restored one. The contract should name the cadence and require the report to show the date and duration.
- Retests after external changes. A platform or vendor update is a change to your system. The contract should include running the suite and critical flows after them.
- A change budget. Without it, small changes pile up or become disputes. Name the hours or amount and the process.
- Vendor watching. Someone reads the deprecation notices. Name who.
- Access reviews. Who can log in to what, reviewed quarterly, departed people removed.
Sizing it
A small internal tool on a mainstream stack needs a light version of the nine: monitoring, monthly updates, quarterly restore test, a small change budget, a short report. A customer-facing application with payments, integrations and thousands of users needs the full version with on-call response, staging, and a larger change budget. The items are the same; the numbers under them differ, and the contract should show which.
What this means for you
Treat launch as the start and contract for the nine items from day one: monitoring and response, updates, security, backups with restore tests, performance, a change budget, documentation, vendor changes with retests, and a monthly report that proves it. Size it to the system. The software that is still working, secure and useful in year three is the software somebody was paid to look after every month.
Frequently asked questions
The software works. Why does it need monthly maintenance?
Because everything around it changes: the platform updates, dependencies publish security fixes, the browsers change, the vendors it integrates with change their APIs, the data grows and the business shifts. Software untouched for a year is not the same software; it is the same code in a changed world, and it fails in ways nobody is watching for.
What is a fair change budget?
Enough hours or a fixed amount per month for the small improvements every live system needs: a field added, a report adjusted, an integration tweaked. It is drawn on with a request and approval process, reported monthly, and anything larger is quoted separately. Without it, small changes either pile up or become disputes about what maintenance includes.
How do we know maintenance is actually happening?
The monthly report: updates applied with versions, security findings and their status, backup restore test date and result, uptime and incidents with response times, performance trend, changes delivered against the budget, vendor notices handled. A report with those items is evidence; an invoice alone is not.