Most conversations about custom software focus on the build: scope, timeline, cost per sprint. The maintenance contract that follows gets far less attention, usually a page or two added near the end of negotiations, sometimes agreed verbally and formalised later. That is a mistake. The build is a fixed event. Maintenance is an ongoing relationship, and the terms of that relationship determine how much a bug costs you in year two, how fast a security patch actually reaches production, and what happens if the relationship sours.
None of this needs to be complicated, but it does need to be specific. Vague maintenance terms are not a neutral default; they favour whoever wrote the contract, because ambiguity gets resolved in their favour when a dispute arises.
Why maintenance is a separate decision from development
A development contract and a maintenance contract optimise for different things. During the build, both sides want the product finished and working. After launch, incentives can diverge: the supplier wants predictable, low-effort work; you want problems fixed fast and your system kept current. A contract that does not name this tension explicitly tends to let it resolve by default, usually towards less effort from the supplier’s side, because nothing forces otherwise.
This is also why it is worth negotiating maintenance terms before the build starts, not after. Once your product is live and your team depends on the incumbent supplier for support, your negotiating position is weaker than it was during procurement. Whatever you agree at that point is what you are likely to live with for years.
What ‘support’ actually covers
‘Support included’ is one of the least informative phrases in a software proposal. It can mean anything from a monitored inbox to a fully staffed on-call rotation. Before signing, get each of the following itemised, with an explicit yes or no against it:
- Bug fixes for defects present at handover, versus bugs introduced by later changes
- Security patching for the application and its dependencies, and how quickly a critical vulnerability gets patched once disclosed
- Compatibility updates when a third-party API, library, or platform (payment provider, cloud SDK, mobile OS) changes under you
- Monitoring and alerting, and who actually looks at the alert when it fires outside office hours
- Backups: frequency, retention period, and whether restoring one has ever been tested
- Small enhancements versus new features: most contracts draw a line here, and the line is usually vague on purpose
The last point causes the most friction in practice. Fixing a login bug and adding a new login method both start as tickets that touch the login screen, but only one is maintenance. Push for a written definition of what counts as a defect versus a change request, because that boundary is where scope creep and billing disputes both originate.
Response time and resolution time are not the same commitment
A common pattern in support contracts is to promise a response time and let the reader assume it covers the fix. It does not. A four-hour response time means someone acknowledges the ticket within four hours; it says nothing about when the problem is actually solved. Both numbers matter, and they should be set separately for each severity level, typically something like:
- Critical (system down, data at risk): fast acknowledgement, and a resolution or workaround target measured in hours, not days
- High (major feature broken, no workaround): same-day acknowledgement, resolution target within a small number of business days
- Low (cosmetic, minor inconvenience): acknowledged and scheduled into normal work, no urgency implied
Ask what happens when a target is missed. A service level agreement without a consequence attached – a credit against the next invoice, an escalation path, a right to terminate after repeated breaches – is a statement of intent, not a commitment. It costs the supplier nothing to miss it.
Retainer, pay-as-you-go, or bringing it in-house
There are three broad shapes a maintenance arrangement can take, and the right one depends less on company size than on how much the software matters to daily operations.
A fixed monthly retainer
You pay for a block of guaranteed capacity and response times whether you use it or not. This suits systems that are load-bearing for the business: anything customer-facing, anything revenue-generating, anything where downtime is visible externally. The cost is predictable; the risk is paying for capacity you do not always need.
Pay-as-you-go or ad hoc
You pay only when something needs doing, usually at a higher hourly rate and with no guaranteed response time. This works for internal tools and low-stakes systems where a two-week wait for a fix is genuinely tolerable. It tends to work badly for anything customers touch, because there is no contractual pressure on the supplier to prioritise you over their other clients.
In-house
You hire or reassign someone to own the system directly. This removes the external dependency entirely but only works if that person, or team, genuinely has the capacity and the system is central enough to justify a dedicated role. A half-time in-house owner on a system that needs full-time attention is a worse outcome than a well-structured retainer.
Many companies end up mixing these: a retainer for the core product, ad hoc arrangements for peripheral internal tools, and in-house ownership only for the systems where institutional knowledge genuinely needs to sit inside the company.
Questions worth asking before you sign
- Who specifically handles a critical incident, and are they the people who built the system or a separate support desk?
- What happens if you want to leave: how much notice, and do you get full access to code, credentials, and documentation on exit?
- Does the contract cover dependency and platform updates proactively, or only when something visibly breaks?
- Is there a cap on included hours per month, and what is the rate once you exceed it?
- Has a backup restore ever actually been tested, or only the backup itself?
- Who owns the decision on whether a ticket is a bug fix or a chargeable change request?
If a supplier cannot answer these plainly before you sign, that is itself useful information about how the relationship will run once something actually goes wrong.