One word, three different jobs
Ask ten buyers what “support and maintenance” means and you will get three answers wearing the same name. The reason it matters is that the three jobs have completely different economics, and a contract that prices them as one thing will misprice at least two of them.
Keeping the lights on. Dependency updates, security patches, runtime versions that reach end of life, expiring certificates, backup verification, credential rotation, cloud services that get deprecated. This is scheduled work. It is predictable, it can be estimated in advance, and skipping it produces no visible effect for eighteen months and then produces a rewrite.
Answering when something goes wrong. An incident, a question, an odd result somebody wants explained, a record that needs restoring. This is unpredictable in timing and mostly small in size. What you are buying is not hours — it is the guarantee that somebody who knows the system will look at it within a defined window.
Small changes. A new field, a report column, a rule that changed because the business changed. This is ordinary development work in small pieces, and it is the one that causes the fights, because it is genuinely difficult to tell a two-hour change from a two-week one until you are inside it.
Nearly every support dispute we have watched, on either side, traces back to the third category being paid for out of a budget sized for the first two. The vendor feels used; the client feels stonewalled; both are behaving reasonably given the contract they signed.
You are probably here because
- A vendor sent a support quote and you have no way to judge whether it is fair
- You are paying a retainer and cannot tell what it bought last quarter
- Every small request turns into a negotiation about whether it is in scope
- Something broke and it turned out nobody was actually responsible for it
The pricing-model table is the fastest read. The ranges section gives you a basis for judging a quote. The section on not buying support is the honest one.
What each pricing model does to behavior
Every pricing model is an incentive system. Read the model first and the rate second, because the model decides what both sides will do when the month gets busy.
| Model | What it does well | What it does badly |
|---|---|---|
| Monthly retainer, fixed hours | Predictable for both sides; the vendor keeps someone available; unused capacity often absorbs the scheduled maintenance | Hours expire and feel wasted in a quiet month; encourages the client to invent work in week four |
| Time and materials, no minimum | You pay only for what you use; honest in a quiet period | No guaranteed availability. When you need urgent help, you are queued behind the vendor's project clients, which is where the money is |
| Percentage of build cost, annually | Simple, easy to budget, roughly proportionate to system size | Bears no relation to how much attention the system actually needs; a stable system overpays badly |
| Per ticket | Transparent, and a clean fit for high-volume small requests | Discourages people from reporting things, which is the opposite of what you want |
| Small retainer plus hourly overflow | Buys availability and response time cheaply; usage-based work is billed as used | Requires trust and clear records on both sides, or the overflow becomes an argument |
The last row is the arrangement we recommend most often, and not because it is the most lucrative. A modest retainer buys the thing that is genuinely scarce — a named engineer who has the system in their head and will answer within an agreed window — and everything beyond that is billed as it happens. Both sides can see what they got.
Honest ranges
Every system is different and anyone who quotes without looking is guessing. These are the bands we plan around, for a system built in the last few years and running on a normal cloud setup.
A small internal system. One or two integrations, tens of users, business hours only. Realistically four to ten hours a month, most of it scheduled maintenance rather than incidents. At typical mid-market engineering rates that is a low-four-figure monthly commitment, and in a quiet quarter it will feel like too much. It is not; it is the price of the phone being answered in the month it matters.
A business-critical system with several integrations. Hundreds of users or customer-facing traffic, three to eight outside systems. Twenty to sixty hours a month is a normal range once you include monitoring, dependency work, incident response and small changes. Integrations are the driver — every outside system is an independent source of unscheduled work, because it changes on its own schedule and tells you afterward.
Anything with a model in it. Add monitoring of output quality on top of everything above. Inputs drift, providers ship updates, and a model system can degrade without a single error appearing in any log. Budget for someone reviewing a sample of outputs on a schedule, forever. This is the cost most buyers of AI systems have not been told about.
As a cross-check on any quote: annual support and maintenance for an actively used system commonly lands between 15% and 25% of what the build cost, before new features. Well under that usually means the scheduled maintenance is not being done by anyone. Well over it usually means feature development has been relabeled.
What a service level agreement actually guarantees
An SLA is a response commitment with a penalty attached, and both halves are worth reading carefully.
First, distinguish response from resolution. Almost every credible SLA commits to response — a qualified human acknowledges and begins work within the window. Very few commit to resolution, and the ones that do usually carry an exclusion list long enough to swallow the commitment. This is not vendor evasion. Nobody can honestly promise to fix an unknown problem in four hours, and a vendor who promises it is either not going to honor it or has priced in the failure.
Second, understand what the penalty is. In most contracts the remedy for a missed target is a service credit — some fraction of that month's fee. If a missed window costs you a day of company-wide productivity, a credit of a few hundred dollars is not compensation, it is a gesture. That does not make the SLA useless; it makes it a management tool rather than an insurance policy. Its real value is that it forces both sides to agree, in calm conditions, what counts as urgent.
Third, price the coverage window honestly. Business-hours coverage is a normal working arrangement. Genuine round-the-clock coverage requires a rotation, and a rotation that does not burn people out needs somewhere between four and six engineers who all know the system. A three-person firm promising 24/7 for a small monthly fee is promising something the arithmetic does not support, and the failure will happen on a holiday weekend.
Where a support month actually goes — our read
Our judgment across supported systems, not a survey. Most people buy support expecting the bottom row and pay mostly for the top three.
The maintenance you cannot safely defer
There is a short list of work that has no visible benefit, produces no demo, and cannot be skipped without the bill arriving later with interest.
Dependency and framework updates. Modern applications carry hundreds of third-party packages. Updating them continuously is a small monthly cost. Updating them after three years is a project, because the versions have moved so far apart that nothing upgrades in isolation. The cost curve here is not linear and it is the single most common source of an unpleasant surprise in year three.
Runtime and platform end-of-life. Language runtimes, database versions and managed services all have published end dates. Nobody notices them until support stops. Someone should be tracking the dates for your stack and telling you a year out, and that person should be named.
Certificates, keys and secrets. Certificates expire on a date known years in advance and still take systems down, because the calendar entry was owned by someone who left. Rotation should be automated where possible and diarized where not.
Backup restores, actually performed. A backup you have never restored is a hypothesis. Test it at least annually, on real data, and record how long it took — because the elapsed time is the number you will need during an incident, and nobody wants to discover it then.
Model behavior, where there is a model. Sample outputs on a schedule and compare against a held-out set with known answers. Quality drifts silently and no error log will report it.
When you should not buy a support contract
Three cases, and they come up often enough to state plainly.
The first is when you already have engineers. If you have two or more capable developers and the system is in your repository with a written runbook, the honest answer is that you do not need us on retainer. Buy a short block of hours for the questions only the original authors can answer, keep the relationship warm, and run it yourselves. We would rather say this and be called in a year for real work than bill a retainer nobody draws on.
The second is when the system genuinely does not change and nothing depends on it urgently. An internal reporting tool that runs weekly, that ten people use, where a two-day outage is an inconvenience, does not need a response commitment. It needs dependency updates twice a year and someone's phone number.
The third is when the system is about to be replaced. Paying to maintain something that will be switched off in eight months is a decision to make deliberately, not by default. Maintain the parts that carry risk, let the rest sit, and put the money into the replacement.
The inverse deserves saying too. If the system carries revenue, touches customers, or is the only record of something your business needs, then a defined support arrangement is not optional. It is the cheapest insurance available and it costs a fraction of one bad week.
The mistakes we see most
- Support scoped as “bug fixes” with no definition of a bug, so every request is a debate
- Feature work paid from the support budget, which quietly consumes the maintenance capacity
- Hours that expire monthly in a system whose needs are lumpy by nature
- A response commitment with no defined escalation path when the first responder is unavailable
- Round-the-clock coverage bought from a team too small to staff a rotation
- No named engineer, so each ticket is handled by someone learning the system from scratch
- Access held only by the vendor, which turns a support decision into a hostage situation
- Scheduled maintenance never scheduled, so it happens only when something breaks
- No monthly record of what was done, so renewal is decided on feeling
What a fair support agreement contains
- The three jobs named and priced separately — upkeep, incidents, small changes
- Severity levels in plain language, with a response commitment for each
- Coverage hours and time zone stated explicitly, with the out-of-hours price if any
- A named primary engineer and a named backup
- A scheduled-maintenance calendar with the tasks and their cadence
- A monthly report: what came in, what was done, hours used, what is deferred
- A defined change process, so small changes do not have to be argued as defects
- Your team retains access to code, accounts and deployment throughout
- Termination for convenience with a notice period, and a defined handover
- Rates published for work beyond the retainer, agreed in advance
Bottom line
Support is three jobs sold as one, and separating them is most of the work of getting a fair agreement. Price the scheduled upkeep as scheduled work, because it is. Price availability honestly, understanding that you are buying the right to interrupt somebody who knows your system rather than a block of hours. Keep small changes on a separate line with its own budget so nobody has to argue about whether a request is a defect. Expect annual support to land between 15% and 25% of the build for a system in active use. And if you have your own engineers and a system that is genuinely stable, say no to the retainer — a good vendor will tell you the same thing and will still be there when you need them.
Frequently asked questions
A retainer buys availability; hourly buys work. If you need a response commitment, the retainer is what pays for someone to be reachable in the months nothing happens. If you only need occasional help and can wait a few days, hourly is honest and cheaper. The hybrid — a small retainer covering availability and scheduled upkeep, with overflow billed as used — fits most mid-sized companies and keeps both sides comfortable.
Some should. A common arrangement is that unused hours roll for one quarter and then expire, which acknowledges that support demand is lumpy without letting a year of unused capacity accumulate into an obligation the vendor cannot staff. Insisting on indefinite rollover usually just raises the rate, because the vendor prices in the liability.
It should be straightforward, and whether it is was decided before the build finished. If the code is in your repository, the pipeline runs in your accounts, the runbook is current and your own team has deployed at least once, a new vendor needs a few weeks to get oriented. If any of those are untrue, fix them now while the relationship is good, rather than during a transition when goodwill is scarce.
Probably, but a manageable one. Working fine and being current are different properties. The likely position is dozens of outdated packages, at least one runtime approaching end of life, and possibly an expired dependency on a service that has been deprecated. Get an assessment before you get a scare: a few days of work will tell you what is urgent, what can wait a year, and what will be a project.
Three signs. You get a monthly record showing what was done without asking for it. Scheduled maintenance happens on a schedule rather than after an incident. And small requests get done without a conversation about scope. If any of those is missing, raise it early — every one of them is fixable, and all three tend to fail quietly rather than loudly.