What a website quote should include, and the questions to ask before you sign

You ask three people to quote for a website. One comes back with a single line and a number. One sends a long document full of terms you don’t recognise. One asks you twelve questions before giving any price at all.

The numbers are wildly different, and it’s tempting to compare them and pick the one in the middle. But the three quotes probably don’t describe the same project. One might include writing the text for every page; another assumes you’ll supply it. One might include a year of hosting; another leaves it out. One might cover a website your team can edit; another delivers something only a developer can change.

A quote is only as useful as what it says it includes. This guide walks through what a good one spells out, the gaps that cause most disagreements later, and the questions to ask before you sign anything.

A price is a promise about scope

Every price is really an answer to the question “what exactly will you do?” If that question isn’t answered in writing, the price doesn’t mean much, because either side can later decide it covered something different.

That’s why a one-line quote is risky even when it looks cheap. It isn’t necessarily dishonest. The person quoting has a picture of the project in their head, and you have a different one in yours. Nobody notices the difference until halfway through, when you ask for something you assumed was included and hear that it’s “extra”.

A good quote closes that gap. It turns the picture in the developer’s head into a list you can read, question and agree to.

What a good quote spells out

1. The pages and features, by name

Not “a professional website” but a list: home, services, about, contact, and so on. For each feature that does something, a short description of what it does: “a contact form that emails enquiries to your team and stores them so nothing gets lost”, or “online booking with deposits taken by card and reminders sent the day before”.

If a feature involves other people’s systems, such as a payment provider, an email service or your accounting software, the quote should name them. Connecting to another system is often where the real work is.

2. What’s not included

This is the most useful part of a quote and the one most often missing. A clear “not included” list might say: writing the text, professional photography, translations, printed materials, ongoing marketing, or anything else you might reasonably have assumed.

A good “not included” list isn’t the developer being difficult. It’s the single best protection against a dispute later, for both of you.

3. Who provides what

Most website projects stall waiting for something from the client: the text, the photos, the logo files, access to the domain. A good quote says who provides each of these and by when, and what happens to the timeline if they arrive late.

If you’d rather not write the text yourself, say so early. Writing clear, useful text for a website is real work, and it’s better priced in from the start than discovered at the end.

4. Design: how many directions, how many rounds

Ask how the design will be shown to you and how many rounds of changes are included. “Unlimited revisions” sounds generous, but it usually means nobody has thought about how decisions will be made. A better answer describes the process: for example, one direction shown as clickable screens, feedback collected in writing, two rounds of changes, then sign-off before building starts.

Signing off the design before building matters. Changing a design on paper is cheap. Changing it after it’s been built can cost as much as building it again.

5. The dates

Not just a launch date, but a date for each stage: design ready for review, build ready for testing, launch. Dates for each stage let you see early if the project is slipping, instead of finding out the week before launch.

6. One price, and what changes it

A fixed price for a fixed scope is the easiest arrangement to plan around. The quote should also say how changes are handled. The best answer is simple: any change is quoted separately, in writing, and nothing starts until you agree to it.

Be careful with quotes that are really estimates (“approximately”, “around”, “from”). An estimate is fine as a first conversation, but before you commit you want a number that won’t move unless you move the scope.

7. Payment terms

How much is paid when, and what triggers each payment. It’s common to pay part upfront and the rest as stages are delivered. What matters is that it’s written down and tied to things you can see, like an approved design or a working site.

8. Hosting, domain and running costs

A website keeps costing money after launch: the domain name, hosting, email, and any paid services it uses (such as a booking tool or a map service). A good quote lists these running costs separately from the build price, says roughly what they cost and who pays them, and says whose name the accounts will be in. (They should be in yours. We explain why in Who owns your code?)

9. Ownership and handover

What you receive at the end: the source code, the design files, the logins, and some documentation. Who owns the rights to the design and code once you’ve paid. Whether you’re free to have someone else work on it later.

If a quote doesn’t mention ownership, ask. The answer tells you a lot.

10. Support after launch

What happens in the first weeks after launch if something doesn’t work as agreed? Is fixing it included, and for how long? And what does ongoing care cost if you want it: security updates, backups, small changes? Ongoing care is often worth paying for, but it should be a separate, optional agreement, not a condition of getting your site.

The gaps behind most disputes

Most disagreements on website projects come back to a small number of gaps.

“I assumed that was included.” The fix is a written scope with a “not included” list. If it isn’t written down, assume it isn’t included, and ask.

Content arrives late. The site is ready, but the text and photos aren’t. The fix is to agree who provides what, and by when, before work starts.

Feedback from too many people. Five people each have opinions, and some contradict each other. The fix is to agree who makes the final call on your side.

Changes after sign-off. Changing the design after it’s been approved and built is expensive, and it’s often where a fixed price starts to feel less fixed. The fix is a clear sign-off step, and quoting any later change separately.

Nobody owns the accounts. The developer registered the domain in their own name, or set up hosting on their account, and now they’re hard to reach. The fix is to have every account in your name from the start.

“It works on my computer.” The site looks fine on a large office screen and falls apart on the phones your customers actually use. The fix is to agree, in writing, what devices and browsers the site will be tested on, including an inexpensive phone on a slow connection.

Questions to ask before you sign

You don’t need to be technical to ask good questions. These work for any website or app project:

1. What exactly is included, and what isn’t?
2. What do you need from us, and by when?
3. How will we see the design, and how many rounds of changes are included?
4. What are the dates for each stage?
5. Is this a fixed price? What would change it?
6. How are changes handled once work has started?
7. What will it cost to run each month or year, and whose name will the accounts be in?
8. What do we receive at the end, and who owns it?
9. Can our team update the content ourselves? How?
10. What devices and browsers will you test on?
11. Is the site built to be accessible to people with disabilities? To what standard?
12. What happens if something isn’t working after launch?
13. If we want to work with someone else later, how easy is that?

Watch how people answer as well as what they say. Clear, specific answers are a good sign. Vague ones (“don’t worry, we’ll sort that out”) usually mean the question hasn’t been thought through yet.

If it’s a web app or mobile app

Quotes for apps and systems have a few extra things worth spelling out, because there’s more going on behind the screens:

• Who can do what. The different kinds of users (customers, staff, managers) and what each one can see and change. Roles are easy to forget and fiddly to add later.
• The admin side. Every app has screens your team uses to manage it: approving orders, editing products, answering customers. Make sure the quote includes them, not just what customers see.
• Connections to other systems. Payments, accounting, WhatsApp, SMS, email, maps. Each one should be named, with who pays for it.
• Moving existing data. If you’re replacing spreadsheets or an old system, who cleans and imports the data, and who checks it?
• Offline and slow connections. If people will use it where the signal is weak, say so, and ask how it’ll behave. (See Offline-first apps.)
• App store publishing. For mobile apps: whose developer accounts are used, who prepares the store listings, and who handles store review.
• Security and backups. How people sign in, how data is protected, and how often it’s backed up. Ask how a backup would be restored, not just whether one exists.

If you’re not yet sure whether you need a website, a web app or a mobile app, settle that before asking for quotes. Website, web app or mobile app? can help.

Comparing quotes fairly

Once you have two or three quotes that each spell out their scope, you can actually compare them. It’s much easier if everyone quoted against the same written brief; How to write a project brief has a template.

Put them side by side and go through the list above. Mark what each one includes. You’ll often find that the cheapest quote leaves out things the others include, such as writing the text, the ability to edit the site yourself, or accessibility, and that once you add those back, the prices are closer than they looked.

It’s also worth asking each person to walk you through their quote. The conversation will tell you whether they’ve understood your business, whether they ask good questions, and whether you’d be comfortable working with them for a few months. That matters as much as the number.

Red flags

Some things are worth pausing on:

• No written scope at all. Just a price and a promise.
• Pressure to decide quickly. A good offer doesn’t expire in 24 hours.
• The whole price upfront for a project that takes months.
• Vague ownership. Talk of “licensing” the site to you, or the domain being registered in the developer’s name.
• No questions about your business. If someone can quote without asking what you do and who your customers are, they’re quoting for a website, not for yours.
• Guaranteed results that nobody can promise, such as a specific position on Google or a number of new customers.

None of these automatically means the person is untrustworthy. But each one is worth a direct question before you commit.

A simple checklist

Before you sign, check the quote covers:

• Pages and features, listed by name
• What’s not included
• Who provides the text, photos and logins, and by when
• How design is shown, and how many rounds of changes
• Dates for each stage
• One fixed price, and how changes are priced
• Payment terms tied to delivery
• Running costs, and whose name the accounts are in
• What you receive at the end, and who owns it
• What support is included after launch, and for how long

If any of these are missing, ask for them in writing. A developer who’s confident in their work will be happy to add them.

How we quote

For what it’s worth, this is how we do it at Variance: a short call about your business first, then a written scope listing what’s included and what isn’t, dates for each stage, and one fixed price. Changes are quoted before anyone starts on them. The accounts are in your name, and at the end you get the code, the design files, the documentation and every login.

If you’re planning a website and want a second opinion on a quote you’ve received, send it to us. We’ll tell you honestly what’s missing, even if we’re not the right people to build it.