What Is an SLA in Software Development (and Why It's Not Enough for a Project)?

An SLA (service level agreement) is a contract that defines how a provider's service gets measured: response time, resolution time, uptime, and what happens if those numbers aren't met. It was built for technical support and infrastructure — a helpdesk, a hosting plan — not for a software project with a delivery date. So when a company hires an outside squad to build something new, a traditional SLA measures what doesn't matter (how fast someone answers a ticket) and stays silent on what does (whether what's being built is what was actually asked for).

What does an SLA measure in a software development contract?

A typical SLA defines four kinds of metric: uptime, response time, resolution time, and support availability. The document usually also spells out what happens if the provider misses those marks — service credits, renegotiation, contract exit — and who's responsible for which layer of the system.

• Uptime — the percentage of time the service stays available, almost always measured monthly (say, 99.9%).
• Response time — how long it takes the provider to acknowledge a reported issue.
• Resolution time — how long it takes to actually fix it, separate from just acknowledging it.
• Support availability — whether coverage is 24/7, business hours only, or tiered by how severe the issue is.

Why doesn't an SLA built for support hold up for building a project?

The problem isn't that the SLA is poorly designed — it's that it measures the process, not the outcome. A support team can close 95% of tickets within the agreed window and still leave the client feeling like nothing actually got fixed. Carried over to a development project, that same problem gets worse: measuring an engineering team's output by response time or availability says nothing about whether the code they're writing solves the real problem, or whether the project will be done when they said it would be.

Gartner frames this as three maturity levels for IT contracts: input-based (paying for hours or headcount), output-based (paying for concrete deliverables, like a feature or a closed ticket), and outcome-based (paying for the business result, like uptime or measured impact). Most companies are still at the first level or moving toward the second; very few reach the third. A traditional support SLA lives at level one. A well-run software project needs to live, at minimum, at level two.

What happens when the SLA stays vague?

The most common source of friction in an SLA-based contract isn't that the provider misses the mark on purpose — it's that the metric was never fully defined. “Response time” can mean different things to each side if the exact moment the clock starts isn't specified, and “resolved” can mean “a temporary patch was applied” to the provider and “this won't happen again” to the client. The more ambiguous the definition, the more room each side has to read it in their own favor when something goes wrong — and that disagreement, not the miss itself, is usually what takes the longest to resolve.

What replaces an SLA in a project paid by milestone?

In a software project — unlike an ongoing support service — what needs verifying isn't how fast the team responds, but whether it delivered what it committed to, when it said it would. That's why Zenit doesn't ask companies to draft a generic SLA for each squad: it replaces that logic with acceptance criteria signed before each milestone starts, so the standard for “done” is defined upfront instead of getting negotiated the moment something doesn't add up.

SafePay releases payment for each milestone against that evidence — not against a date on a calendar or a verbal promise — so the squad doesn't get paid for work that can't be verified, and the company doesn't pay for work that isn't done.

And that delivery track record doesn't reset between projects: ZenitRank accumulates it milestone by milestone, with an on-time rate that updates on its own, so the next company evaluating that squad sees a real history — not a fresh promise every time.

An SLA is still the right tool when what's being hired is an ongoing service — support, infrastructure, maintenance. For a project with a delivery date and a defined scope, the question that matters isn't how fast the provider responds — it's whether what they're going to deliver is exactly what the company needs. Kaizen answers that question before the project even starts, not a document full of support metrics.