The quote tells you what the website costs. The contract tells you what exactly you get for that money — and what happens if something goes wrong. Most disputes between a client and a web agency are not about the price but about things nobody wrote down: who writes the copy, how many revisions there are, whose name the domain is in.
Here are the 12 points a website development contract should cover. You don’t need a lawyer to check them — you only need to know what to look for.
This is a practical checklist from a developer’s point of view, not legal advice. For a large project or unusual terms, show the contract to a lawyer. In Bulgaria contracts are usually in Bulgarian — if you don’t read it, ask for a bilingual version.
Why the contract matters more than the quote
A quote is a promise. A contract is what you can point to when the promise isn’t kept. If the scope, the deadline and the ownership are not written down, each side remembers them in its own way — usually in its own favour.
For a small business the contract doesn’t need to be long. Two or three pages are enough, as long as they clearly answer the questions below.
The 12 points the contract should have
1. Parties and subject
Who signs with whom — company, registration number, representative — and what is being built, in one sentence. It sounds formal, but without clear parties there is no one to hold to account.
2. Scope: an exact list of pages and features
This is the heart of the contract. Not “a business website” but a list: which pages, what contact form, whether there is a blog, online booking, a gallery, a second language. Anything not on the list later becomes “extra work”.
Good sign: the scope is a detailed annex to the contract. Red flag: “website development as instructed by the client” with no annex.
3. Deadlines — and what depends on you
The deadline should be in days or a date, split into stages: design, build, launch. It is fair for the contract to say the reverse too — when you deliver copy, photos and access, because without them nobody can meet the deadline.
4. Price, payments and what is NOT included
A total price, with or without VAT, and a payment schedule — for example a deposit at the start and the balance on handover. Just as important is the sentence “the price does not include…”: the domain after the first year, hosting, paid add-ons, an advertising budget. Hidden costs usually live in exactly this silence.
5. Revisions: how many and until when
The number of revision rounds (or “until approval”) and what counts as a revision. “Change the button colour” is a revision; “add an online store” is new scope. If the difference isn’t described, a dispute is only a matter of time.
6. Acceptance of the work
How and when the website counts as delivered — usually with a handover protocol. It helps to have a review period too: a few working days in which you point out problems before the final payment.
7. Ownership: design, code, copy and photos
The point owners miss most often. If the contract doesn’t say explicitly that the rights are transferred, copyright stays with the author by default, and you rely on a right to use the website for the purpose it was commissioned for. Check the photos too: are they bought with a licence that covers you, or taken “from the internet”?
One sentence settles it: “After the final payment, all rights to the design, the source code and the content created under this contract pass to the client.” If it isn’t there, ask for it.
8. Domain and hosting — in whose name
The domain should be registered in your name or your company’s. Hosting too, or at least with a clear clause on how it is transferred if you change developers. Otherwise, on the day you decide to leave, you may find that your business’s address isn’t yours.
9. Access and passwords on handover
A list of what you receive on handover day: the admin panel, hosting, domain, Google Analytics and Search Console. You own the accounts and the developer is a guest in them — not the other way round.
10. Warranty for bugs after launch
A period in which the developer fixes bugs in their own work for free: a button that doesn’t work, a form that doesn’t send. It should be kept separate from new wishes, which are separate work.
11. Maintenance — separate and with a price
If there is maintenance after launch, the contract (or a separate one) should state what it costs, what it covers and how it ends. “Optional” maintenance with no price in the contract becomes a surprise on the invoice. More in our article on maintenance and its cost.
12. Personal data and termination
The contact form collects your customers’ names, phone numbers and email addresses. The contract should say that the developer processes them only for the purposes of the website and does not use them for anything else. And finally — how either side can end the contract and what is owed for the work done up to that point.
The red flags in one place
- No written contract — “we’ll sort it out”.
- The scope is a single sentence with no annex.
- The domain is registered in the developer’s name.
- Nothing is said about the rights to the design and code.
- Full payment up front, before you have seen anything.
- Maintenance is “mandatory” but its price isn’t in the contract.
- No way to end the contract other than “by mutual agreement”.
How we work
Since we are writing a list like this, it is only fair to show how things stand with us. The terms are public on the pricing page:
- Demo first. The demo is free and needs no deposit — you pay only after you approve the direction.
- Payment in two stages: 50% at the start of the project and 50% on handover of the finished website.
- Revisions until full approval, with no limit on the number.
- The website and the code are 100% yours. When we register the domain, it is in your name.
- Timeline: usually 7–14 working days after the demo is approved.
- Maintenance: the first year is on us, after that it is optional — €250/year.
- Money back: if after the start of the project we haven’t delivered what was agreed, we return the first payment.
Summary: a detailed scope, a clear deadline, a price with or without VAT and what isn’t included, the number of revisions, an acceptance protocol, rights to the design and code, the domain in your name, access on handover, a bug warranty, maintenance with a price, personal data and termination. If the contract answers these 12 questions, you will rarely need to take it out of the drawer.