ARTICLE
How should you negotiate maintenance after launch?
A maintenance contract is not really about fixing faults. It is about the boundary of responsibility, response times and how work outside the scope is charged. This article covers three common models and five questions to settle before signing.
The short answer
A maintenance contract only needs three things settled: what counts as maintenance, how fast you respond, and how anything outside that is charged. Writing those three down clearly matters more than how thick the contract is. A vague promise of maintenance for life becomes the source of the dispute the moment the two sides read it differently.
Separate defect fixes from new development
These two are confused more often than anything else. Something the system was always supposed to do but does not do correctly is a defect fix, and the developer owns it. A requirement added after launch because the business changed is new development, and it should be quoted on time and cost separately.
Between them sits a grey area: changes forced by regulation or by a third-party service upgrade. Classify these explicitly in the contract, for example whether a payment provider's API upgrade falls under the annual maintenance.
Three common maintenance models
1. Annual maintenance fee
A fixed annual fee based on the size of the system, covering defect fixes, environment upkeep and small adjustments. Suits systems whose processes have settled and that need only minor changes each year.
2. Prepaid hours
You buy a block of hours and draw them down as changes are needed. Suits the first period after launch, or a business still changing shape: more flexible, and you pay for nothing you do not use.
3. Per project
No standing contract, and each request is quoted on its own. Suits a relatively simple system that changes rarely, but you have to accept waiting for a slot.
Five questions to settle before signing
- How is response time defined: a reply, or a fix? The difference is large.
- How are issues graded? A system that cannot be used and a display glitch should not share a priority.
- Does maintenance include hosting, domains and certificates, or are those billed separately?
- Who owns the source code and the data, and how is handover done if someone else takes over later?
- Is the maintenance team the team that built it? Changing team usually costs more than expected.
How we work
The same team handles consulting, design, development and maintenance after launch. We do not hand the system to a different group once it is delivered. The reason is straightforward: the people who best understand why a system was built this way are the ones who made the decisions.
