What Should Be in Your Website Contract and SLA?

A strong website contract describes exactly what you get, at what price, when, and what happens if something changes or goes wrong. The SLA (service level agreement) covers the arrangements after launch: support, response times, availability and maintenance. Together, these two documents prevent the classic pitfalls: a project that overruns, an invoice that comes in higher than expected, or a supplier you can no longer reach once the site is delivered. In this article you get a concrete checklist of the clauses that belong in there: scope, change orders, deadlines, support, uptime, warranty and exit.

This is deliberately not legal advice, but a practical guide so you know what to watch for before you sign. Want the bigger picture of a website project? Then read our guide to building a B2B website.

What is the difference between a website contract and an SLA?

The contract is about building your site, the SLA is about running it afterwards. The contract governs the project: what is being made, by whom, for what amount and within what timeframe. It describes the one-off delivery and everything that leads up to it.

The SLA usually starts where the contract ends, namely at launch. It sets out how quickly your supplier responds to problems, what falls under maintenance, how available your site should be and what that costs per month or per year. Many agencies put both agreements into one document with separate chapters, and that is fine as long as each part is clear. The danger lies in what is written nowhere: undefined grey areas almost always lead to disputes and extra costs.

Which clauses belong in the website contract?

The core of a good contract is that scope, price, planning and ownership leave no room for interpretation. Work through these points before you sign.

• Scope and deliverables. A list of what is being built precisely: number of pages or templates, languages, integrations (CRM, newsletter, forms), the CMS and who supplies the content. The more concrete it is, the less argument afterwards.
• Price and payment schedule. Fixed price, hourly rate or a mix, and when you pay (for example in phases). Watch what is not included: stock photos, licences, premium plugins or hosting.
• Planning and deadlines. Milestones with dates, and what happens in case of delay. Important: also record that the planning depends on your input. Slow feedback or late content is the most common cause of overrun.
• Change orders. The most important clause for preventing runaway invoices. Agree how additional work is determined, that it is estimated in advance and approved in writing, and at what rate. That way an extra wish never lands on your invoice as a surprise.
• Revisions. How many feedback rounds are included in the price and what an extra round costs. Endless polishing without a limit is expensive for everyone.
• Ownership and intellectual property. Who owns the design, the code and the content after payment? Agree that all rights transfer to you the moment the invoice is paid. This ties directly into your exit position further on.
• Liability. A reasonable limitation of liability is normal, but read what is excluded.

An agency that works honestly will want to nail down these points itself. Ambiguity is, after all, just as annoying for the builder as it is for you. See how we approach projects in web design.

What belongs in the SLA after launch?

The SLA determines how your site is supported and maintained after delivery, and that is what you live with for the years ahead. A few thousand euros in build costs pale next to years of support, so read this part just as thoroughly as the build quote.

• Support and reachability. How do you report a problem (email, ticket, phone) and during which hours? Does that also apply outside office hours?
• Response and resolution times. The heart of an SLA. Good arrangements distinguish by urgency: a site that is down deserves a faster response than a typo. Watch the difference between response time (when someone starts) and resolution time (when it is fixed). Never promise anyone a fixed resolution time for problems that lie partly outside their control.
• Maintenance. What falls under the monthly fee: updates to the CMS and plugins, security patches, backups, small content changes? And what falls outside it and is billed separately?
• Backups and recovery. How often are backups made, where are they kept and how quickly can your site be restored after an incident?
• Security and updates. Who keeps the platform safe and up to date? With a headless or CMS choice the division of responsibility differs, so make it explicit.
• Performance. If need be, agree that the site keeps loading fast. Slow pages cost you leads. Our explanation of Core Web Vitals helps you understand what you can demand here.

How do you read the uptime and warranty arrangements?

Uptime is the promised availability of your site, usually expressed as a percentage per month or year. The higher the percentage, the less downtime is allowed. The difference between, say, 99% and 99.9% seems small but stands for a considerable difference in permitted outage moments. More important than the exact figure are the details underneath: is planned maintenance time excluded from the measurement, how is downtime measured, and what do you get if the standard is not met (often a credit or discount, rarely genuine compensation)? Bear in mind too that uptime largely depends on the hosting party, so check who is responsible for that.

The warranty governs something else: that faults in the delivered work are fixed free of charge within an agreed period. Watch the distinction between a bug (the supplier built something wrong, and fixes it for free) and a change (you want something different, and that is a change order). A reasonable warranty period after delivery is customary. Make sure it clearly states what does and does not fall under warranty, so that a genuine fault is not presented as paid extra work.

Why is the exit clause so important?

The exit clause determines whether you are free to leave or whether you are stuck with your supplier, and that is perhaps the most important point of all. Check these matters:

• Ownership of everything. Code, design, content and database must be yours. Ask whether you receive a full export or copy on departure.
• Domain and accounts. Your domain name, hosting and all accounts must be in your name, not only in that of the agency. This is a classic pitfall: companies that do not manage their own domain are in a weak position.
• Notice period. How far in advance must you cancel the SLA, and are there costs attached to stopping early?
• Handover. Does your supplier help with a clean handover to a new party, and on what terms?
• Vendor lock-in. Does the agency build on a mainstream platform or in a closed system that only they can work with? Open and transferable is always safer.

An honest partner makes leaving easy, precisely because good service should be the reason you stay. Want to move to another platform or agency later? Then our guide on website migration without losing rankings helps you do it without damage.

Don’t forget the data processing agreement

If your supplier processes personal data on your behalf, for example via forms, a CRM integration or analytics, then the GDPR requires a written data processing agreement between you and that party. This is not an optional extra but a legal obligation under article 28 of the GDPR. It states, among other things, what may be done with the data, how it is secured and that it is returned or erased when the collaboration ends. Ask for it explicitly; a professional agency has this ready as standard.

The short summary

A good website contract makes scope, change orders, deadlines and ownership watertight, so you get no surprises during the build. The SLA governs life after launch: support, response times, uptime, maintenance and backups, in other words the largest part of your site’s lifespan. Pay extra attention to the warranty (free fault repair, no disguised extra work) and especially to the exit clause, because ownership of your code, content and domain determines whether you stay free. And don’t forget the data processing agreement if personal data is in play. Read aloud anything that is unclear and keep asking questions: an honest partner is happy to explain it to you.

Not sure whether a quote or SLA is sound, or want to have a new project properly documented? Get in touch with us and we’ll look at it together.