What to Ask Before You Sign a Website Contract

A website contract usually turns up at the end of the conversation, once you’ve agreed a price and you’re keen to get started. That’s the wrong moment to read it properly. The website contract questions that matter get asked before you sign anything, not after a problem shows up six weeks into the project. I’ve seen contracts that protect the developer completely and say almost nothing about what the client actually gets, not through dishonesty, just because nobody asked. This isn’t about turning a website purchase into a legal negotiation. It’s about knowing which handful of questions matter, and asking them before any money changes hands.

Who owns the website once it’s built?

A contract that dodges the ownership question, or answers it vaguely, is worth pushing on before you sign.

This sounds obvious until you’re the business that finds out it isn’t. Some contracts hand you full ownership of the code, the content, and the design the moment the final invoice clears. Others keep the developer as the only person who can access or move the site, even after you’ve paid in full.

Ask directly: once this is finished and paid for, who owns it, and can I take it to another developer if I need to? A contract that dodges this question, or answers it vaguely, is worth pushing on before you sign.

What’s actually included in the contract?

Vague scope is where most website disputes start. “A modern website with a few pages” means something different to every developer who reads it. A proper contract lists the pages, the functionality, and the number of revision rounds included at the agreed price.

Anything outside that list should be flagged as a variation, with its own cost and timeline, rather than folded quietly into the original quote. If a contract doesn’t spell out what’s included, ask for a written scope before you agree to anything.

What happens if the timeline slips?

Timelines slip. Content arrives late, feedback takes longer than planned, a launch date moves around a client’s own schedule. None of that is unusual. What matters is whether the contract says anything about it.

A good contract sets out what happens when a delay is the client’s doing versus the developer’s doing, and whether either side owes the other anything as a result. If a contract promises a fixed delivery date with no mention of what causes delays or who’s responsible for them, that’s worth asking about directly.

What does “ongoing support” mean in the contract?

A website is not a one-off delivery. Knowing what happens after launch matters as much as what happens before it.

“Ongoing support included” is one of the most common phrases in a website contract, and one of the least defined. Included for how long? Covering what, exactly? What happens once that period ends?

Ask what “support” actually covers: security updates, content changes, emergency fixes if something breaks, or just email access to ask questions. Ask what it costs once any included period runs out. A website is not a one-off delivery. Knowing what happens after launch matters as much as what happens before it.

How and when do you pay?

Payment structure tells you a lot about how a project is likely to go. A developer asking for the full amount upfront, with nothing tied to milestones or delivery, carries more risk for you than one who splits payment across stages: deposit, midpoint, and completion.

Ask what triggers each payment and what recourse exists if a stage isn’t delivered as agreed. This isn’t about assuming bad faith. It’s about having a clear answer before you need one.

What if the relationship doesn’t work out?

Most website projects go fine. Some don’t, and a contract should say what happens when they don’t. Can either side end the agreement, and under what terms? What do you keep if the project stops halfway: the design files, the partial build, the content already written?

I’ve written before about what happens when a developer disappears, and almost every case traces back to a contract that never addressed this question in the first place. Asking it upfront costs you nothing. Not asking for it can cost weeks of recovery later.

Before you sign anything

None of these website contract questions require legal training to ask. They require reading the contract properly and being willing to raise what it doesn’t say, not just what it does. A developer who answers all six clearly and without hesitation is showing you how the rest of the relationship is likely to go.

For a broader look at how website pricing and decision-making works before you get anywhere near a contract, the Small Business Website Investment Guide covers what drives cost at every level and how to work out what your business actually needs.

If you’re weighing up a website project and want a second pair of eyes on a contract before you sign it, get in touch and I’ll give you an honest read of whether it protects you properly. enquiries@kupu.co.uk or connect on LinkedIn.