Website quote — how to read one and which billing model to take

A website quote looks like a price and is a description of scope dressed as a number. Two quotes can be compared only once you know what each assumes — and they usually assume different things, because they were written from the same vague enquiry.

This article is about the document and the contract behind it: which billing model to take, what to tie instalments to, and where the contingency goes. It is not about why one technology costs more than another — that is a separate matter, settled before anyone issues a quote.

How a quote is put together

Before a number appears, the supplier settles several things — and if they did not ask you, they settled them by assuming.

They need to know how many pages there are and which are unusual, because ten pages repeating one pattern is different work from three that each look different. They need to know where the content comes from — whether you supply text and photographs or they prepare them. And what the site has to connect to, because integrating with a system they have not seen is a risk that has to be priced somewhere.

And they need to know when, because a deadline is a line item, not an organisational parameter.

The conclusion runs against intuition: the more detail you give in the enquiry, the lower the quote tends to be — not because anyone concedes, but because the margin for unknowns disappears. "How much does a website cost for my company" guarantees an answer with a buffer, because anything else would be irresponsible.

How to write an enquiry that produces comparable quotes

If more detail means a lower quote, it is worth knowing which details change anything. No technical specification is needed — one page will do.

A list of pages by name. Not "a business site with subpages", but: home, services with three offerings, about, work, blog, contact. That list alone removes most of the divergence.

Three sites you like, and one sentence on why. The cheapest way to convey visual expectations, and the only one better than adjectives.

Who writes the copy and takes the photographs. One sentence. It settles an item that can be a tenth of the budget.

What the site has to connect to. The system's name is enough — CRM, booking, stock control. The supplier will check whether it has an API.

The deadline and where it comes from. If it is fixed by a trade fair or a campaign, say so immediately. A quote with a deadline and one without are two different quotes.

An enquiry in that form gives you offers that can be laid side by side — the only condition under which comparing amounts means anything. Without it every supplier prices their own imagination, and whoever imagined least wins.

Three billing models

The first decision in the document, and the one most often taken without anyone realising it is one.

The surprise in that table: fixed price is often the hidden expensive choice. A supplier quoting a fixed figure takes on the entire risk of unknown requirements and adds a margin for it — rightly, because the alternative is working below cost. You pay for uncertainty you introduced yourself, by giving a general brief.

With a well-described scope, hourly or staged billing often comes out cheaper, because that margin disappears. With a loose scope the reverse is true, and fixed price protects you from an open-ended bill.

The rule: the better you know what you want, the more the flexible model pays. The less you know, the more the rigid one pays — and the more that rigidity costs.

Milestones — not a ratio, a condition

A 30/40/30 split is a convention and means nothing in itself. What means something is what triggers each instalment — an instalment with no acceptance condition is a payment date, not a milestone.

The middle instalment matters most, because it falls when changes are still cheap. After the wireframes are approved, every layout change means undoing work already done. So its condition should not be "half the schedule has passed" but "we have seen and approved how this is going to look".

The final instalment is the only leverage you have left after launch. Tie it not to publication alone but to the handover of access credentials and the closing of the defect list — a site that works but that you cannot change yourself has not been accepted.

Where the contingency actually goes

A contingency of 15–20% gets treated as pessimism. It is not — and it is worth knowing what it goes on, because it is usually the same three things.

Waiting on your side. The team waits for content nobody prepared while the time is reserved. On hourly billing you pay directly; on fixed price you pay in a slipping deadline. The commonest cause of overruns and the only one you fully control.

Scope added mid-project. "Could we also add an English version?" — asked after the wireframes are approved, sounding like a detail, meaning a second version of every page, a second set of content and a rebuilt navigation. Not a bad request; a new scope, and it should be priced as one.

Licences and integrations nobody planned for. A paid plugin without which a feature does not work. A system whose API turns out different from what was assumed. A certificate somebody has to buy. Individually small, together they make up those percentage points.

What all three share: none of them is a pricing error. They are things nobody could have known at the moment of quoting — which is why a contingency is a planned item, not an emergency one.

Keep it as a separate budget line rather than a cushion in your head. A written line forces a decision every time you reach for it — "is the English version worth fifteen per cent of the budget" is a different question from "could we also add". The first sometimes gets a no, and that is healthy; the second almost never does.

If the contingency goes unused, it was not unnecessary. It means the scope was well described — that the work you put into the enquiry came back.

Anatomy of the document

What a quote should contain

A good quote is short and specific, not long and general. Seven items tell you it is a document rather than a figure in an email:

• Scope itemised by name. How many pages, which features, which integrations. Not "business site with a blog", a list.
• Exclusions. What the quote does not cover. The item whose absence costs most, because everything unnamed turns out later to be out of scope.
• Who supplies the content. Text and photographs are either in the price or on your side. There is no third option, and silence means a dispute.
• The billing model and the instalment schedule, with the acceptance condition for each.
• The deadline, with what it runs from. Usually not from signing but from delivery of materials — worth having written down.
• What happens when the scope changes. A variation, an hourly rate, a procedure.
• What you get at the end. Below separately, because it is the most often omitted.

A quote with no exclusions that does not say who supplies the content is not cheaper than one that does. It is less finished, and the difference is paid later.

What you get at the end — and whether it is yours

The least-checked part of the document, and the one that decides what happens when the engagement ends. Four things worth stating explicitly before you negotiate price.

Whose name the domain is registered in. The only one of the four that can be impossible to recover without the other party's consent. The company, not the supplier.

Whose name the hosting account is in, and who gets the renewal notices. The commonest cause of a lost domain is not financial — it is an email to the mailbox of somebody who no longer works there.

Whose account the theme and plugin licences sit on, and what happens when the contract ends. The site keeps working but stops receiving updates — including security updates.

Who has administrator access. Not editor — administrator. If only the supplier does, every future change of supplier starts with a negotiation about access.

Separately, agree what happens to the design files — wireframes and graphic sources. They are sometimes treated as the supplier's working tools rather than part of the delivery, and that is to be settled rather than assumed either way.

The warranty — for what and for how long

The word "warranty" appears in most quotes and almost never means the same to two suppliers. Three things worth settling.

What is a defect and what is a new feature. A form that does not send is a defect. A form that sends but needs an extra field is a change of scope. The boundary is obvious only once written down.

For how long. The period is often counted from acceptance and is often shorter than the time it takes defects to surface — some only appear at the first real traffic or the first update.

Whether it covers the effects of updates. The most important question and the most often skipped: if an automatic plugin update breaks the layout six months after handover, is that a warranty defect or paid work? Both answers are honest — only the absence of one is not.

What is not in the quote and will certainly happen

A quote describes the build. It ends on publication day — the bill does not.

Hosting and the domain — whose choice has cost consequences of its own — licence renewals, updates and work on whatever breaks start accruing the day after launch and appear in no project quote, because formally they are not part of one. That is not concealment; it is a different document.

The consequence when comparing offers: two quotes can be identical and the three-year bill can still differ by a factor of two, depending on what the site stands on and how many licences it needs. The four layers of that bill, with renewal prices, we set out separately. Worth asking about at the quoting stage even though it is not part of it — an answer of "it depends" is information in itself.

What can be negotiated and what cannot

Negotiating a quote is associated with one thing — pushing the rate down. That is where the room is smallest and the cost of a concession highest. Below is what can actually be moved.

The hourly rate — least of all. The supplier calculated it from the cost of the team and rarely moves more than a few per cent. A concession here comes back as a less experienced person on the project or a slower response — not because anyone is cheating, but because cheaper is done differently, not faster. Worth knowing before you push: rates in the two largest continental markets are falling, not rising — French JavaScript day rates down 10.6% to 16.6% year on year, and the German freelance average declining for the first time since its survey began.

Scope — most of all. The right place for the budget conversation. Cutting a third integration, two page templates or the photo shoot from stage one moves the figure genuinely and reversibly — each can be added later to a finished foundation.

The payment schedule — almost always. More instalments, the last one behind acceptance, instalments tied to milestones instead of dates. For the supplier that is cash flow, not margin, so the conversation is easier than it looks.

Warranty and a post-launch fixes package — worth it. One month or three for bug fixes, a pool of hours for small changes in the first quarter. Cheaper agreed before signing than bought afterwards in emergency mode.

A response time written as a number — worth it, if the site earns. "Support included" with no time attached is not a commitment. A specific response time for a critical outage, in the contract, is — sometimes the only difference between an hour and a week of downtime.

Transfer of rights and access to the code — not negotiable. The one item you have to have in full or not at all. Without a clause transferring the economic copyright, and without access to the code and the database, you cannot commission changes from anyone else and cannot move the site. With a supplier who disputes that, you are not negotiating price — you are negotiating whether you buy at all.

The order: rights and access first, then warranty and response time, then scope. Leave the rate alone — if the budget does not close after those three, the problem is scope, not the hourly price.

How to read and compare

Warning signs in the document itself

Regardless of the amount, several things should prompt a question. All concern the document, not the price.

One line for the whole thing. "Website build — €8,000" with no breakdown means every conversation about a change starts by establishing the scope from nothing, because it never was.

No exclusions. A document saying only what is included shifts the whole burden of interpretation to the moment of a dispute.

A deadline with no reference point. "Six weeks" from what? If from signing, and materials arrive in week three, the delay is formally yours.

No deposit. It sounds favourable and can signal that the supplier does not plan to start with the stage requiring their work before your approval — or that the project is filler.

Payment in full up front. The opposite extreme and more dangerous — after the transfer you have no leverage at all.

Silence about access. A quote that does not say whose name the domain goes in and who holds the administrator account defers that conversation to its hardest moment.

None of these means a bad supplier on its own. Each means a question worth asking before signing, not after.

When a quote is suspiciously low

A low figure is not itself a warning — often it is simply a narrower scope, and for some companies the right choice. The warning is a low figure against a broad description.

If the document promises a design from scratch, integrations, content and care, and the figure sits at the floor of the landing-page band on published price lists, one of those things is not what it appears to be. Usually "design" means choosing colours in a ready-made theme, and "content" means pasting across whatever is on the old site.

Three questions settle it faster than any analysis: how many people work on the project, how many of those stages have you seen this supplier deliver, and what happens when the scope turns out to be larger. The third matters most, because with an underpriced quote that moment always arrives.

And one thing worth saying plainly, because it cuts both ways: a quote well above the market also needs an explanation — just an easier one to get, because a supplier charging more usually knows why and will name it.

How to compare two quotes

Four questions, asked before you look at the amounts.

1. Do they price the same scope? If one lists integrations and the other is silent, they are not two offers for the same thing. Without a written list of pages, features and integrations you are comparing assumptions.
2. Which billing model? Fixed price with a risk margin and an hourly rate without one give different numbers for the same work.
3. What is the condition for each instalment? Not the ratio, the condition. No conditions means a payment schedule with no checkpoints.
4. What happens when the scope changes? A variation, an hourly rate, or "we'll sort it out"? The third is the most expensive, because it is settled mid-project, when you have no leverage.

A separate decision worth taking in parallel is whether you pay for the build once or spread it into a subscription — we costed both over five years. If the difference still looks unjustified after those four questions, it probably sits outside the document — in who is quoting, what they build on and where they work. That is a separate subject.