Your software launches, everyone celebrates, and then — quietly — someone has to answer the question nobody wanted to negotiate during the excitement of building: what happens when something breaks at 6pm on a Friday? Without a clear answer, the honest one is usually "whoever picks up the phone, whenever they're free." That's not a support plan. That's hoping.
An SLA (Service Level Agreement) and a support contract turn that hope into something you can actually rely on — and something you can hold a supplier to. Here's what should be in one, and what it typically costs.
What an SLA actually promises
An SLA isn't a vague reassurance that "we'll take care of you." It's a specific, measurable commitment. A usable SLA answers three questions in numbers, not adjectives:
- How fast will someone respond? — Response time, not resolution time. "We'll acknowledge your ticket within 4 business hours" is testable. "We'll get back to you quickly" is not.
- How fast will it actually get fixed? — Resolution time, usually tiered by severity. A payment system going down is not the same urgency as a typo in a footer.
- What uptime is guaranteed? — Typically expressed as a percentage (99.5%, 99.9%) with a defined measurement window and what happens if it's missed.
Severity tiers: the part most SLAs get wrong
A good SLA doesn't treat every issue the same. A typical structure:
- Critical (system down, data loss risk): response within 1 hour, resolution target within 4–8 hours, often available outside business hours.
- High (major feature broken, no workaround): response within 4 business hours, resolution within 1–2 business days.
- Medium (feature degraded, workaround exists): response within 1 business day, resolution within a week.
- Low (cosmetic, minor annoyance): bundled into the next scheduled update.
Without tiers, everything defaults to "whenever we get to it" — including the critical issue that's actually costing you money right now.
What a support contract should cover beyond the SLA
Scope of support
Bug fixes are the baseline. Does the contract also cover security patches, dependency updates, small feature tweaks, or monitoring? A contract that only promises to fix things that are already broken leaves the software slowly decaying underneath — the same technical debt issue you were trying to avoid by building it properly in the first place.
Included hours vs. billed separately
Most support contracts bundle a monthly hour allowance — commonly 5 to 20 hours — for small fixes and updates, with anything beyond that billed at an hourly rate, usually €85–€140. Know which bucket a request falls into before you ask for it.
Escalation path
Who do you actually contact, and what happens if that person is unavailable? For a one-person studio this matters more, not less — ask directly what the backup plan is if your developer is unreachable during a critical incident.
Exclusions
New features are (correctly) usually outside a support contract's scope — that's project work, quoted separately. Make sure the line between "this is a bug" and "this is a new feature" is defined, because that's exactly where disputes happen.
What it costs
Support contracts for a mid-sized business application typically run 10–20% of the original build cost per year. On a €40,000 build, that's roughly €4,000–€8,000 annually, covering a defined SLA and a monthly hour allowance. Ad-hoc support with no contract — calling whoever's available and hoping — often ends up costing more per hour, with none of the guaranteed response times.
How to know if you actually need one
You need a support contract if the software is business-critical — if it going down for a day costs you real money or real reputation. You can skip the formal SLA for low-stakes internal tools where "we'll fix it next sprint" is genuinely fine. Match the guarantee to what's actually at stake; paying for a 1-hour critical response on a tool three people use occasionally is money spent on peace of mind you don't need.
Setting up support for your project?
Whether you're commissioning new software or already running something without a clear support arrangement, I can help you define an SLA that matches the actual risk — not a generic template. Get in touch and we'll figure out what level of cover makes sense for your situation.