"How much is a website?" has no single answer — but the items that set the price are known and not secret. This page explains how a quote is produced and which common mistakes inflate cost for nothing.
Five items determine the price of a website or software build: (1) scope — not page count but the number of distinct screen types; (2) integrations — connections to payment, shipping, accounting or SMS systems, the least predictable item; (3) content readiness — whether copy and imagery exist; (4) design level — adapting a theme versus original design; (5) maintenance and responsibility — who looks after it after delivery. A figure given before these are settled is a guess; once settled, a fixed quote can be given.
You will not find a figure on this page, and there is a reason. Two jobs described in the same sentence can differ tenfold.
Two clients asking for "a site that takes restaurant orders" might mean very different things: one is happy with standard payment methods and has a menu ready; the other needs meal-card integration, a kitchen screen, courier handoff and shift permissions. Both phrase it identically.
That is why "websites from £X" advertising carries no information. What does carry information is knowing which items set the price — because then you can see which one dominates in your case, and genuinely compare the quotes you receive.
A common misconception is that price scales with page count. But 40 product pages sharing a template are designed once; 5 genuinely different screens are designed five times.
The right question is not "how many pages" but "how many distinct screen types". Home, list, detail, form and dashboard are each separate work.
Every connection to an external system is its own item: payment gateway, shipping carrier, accounting software, SMS provider, booking system, CRM. Each means separate documentation, separate testing and separate failure modes.
This is the item that affects cost most and is underestimated most. It gets its own section below.
Is the copy written? Have the product photographs been taken? Are the corporate details in order? If the answer to those is no, a substantial part of the project's duration is spent waiting on content.
There is a wide range between adapting an existing theme to a brand and building original design from scratch. Both are legitimate; what decides is how much the brand needs to stand apart. A personal brand or a boutique product usually gets its money back from original design; a standard corporate brochure site may be well served by a theme.
What happens after delivery is part of the price. Will the site be left alone, will it be updated and backed up regularly, and who responds when something breaks? A project without a maintenance arrangement looks cheap and becomes expensive at the first serious problem.
The cost of an integration is set not by the length of the code but by the quality of the other side.
With a well-documented provider that offers a test environment, an integration takes days. With a provider whose documentation is incomplete, who has no test environment and whose support is slow, the same work stretches over weeks — and that is time spent waiting, not developing.
Integrations also carry approval time that is independent of software. A bank virtual POS application, for instance, requires specific legal pages to exist on your site, and approval takes time. The system waits even when the technical work is finished.
Practical advice: if you will take payments, start the legal pages and the bank application at the beginning of the project, not the end.
Most projects are delayed not by development but by content. It is independent of the quote and directly determines the timeline.
The familiar picture: the site is technically ready, but the about copy is unwritten, the team photographs untaken and the product descriptions incomplete. Projects can sit at that point for months.
The way to prevent it is to turn the content requirement into a list at the start, naming who prepares what and by when. Content production can also be brought into scope — priced as its own item, but the project does not wait.
If scope changes later — as it often does — the change is priced separately and not carried out without approval. That rule protects both sides.
For systems that take payments or hold personal data, the third model is strongly recommended — in those systems an unpatched component is a direct risk.
The honest answer to the price question: a figure given before scope is settled is a guess; once settled, a fixed quote can and should be given.
The most valuable preparation on your side is answering three questions in advance: how many distinct screen types are there, which external systems will it connect to, and is the content ready? A request that arrives with those three answers gets a faster and more accurate quote — from whoever you ask.
A single figure would mislead, because two jobs described in the same sentence can differ tenfold. Five items set the price: the number of distinct screen types, external integrations, whether content is ready, design level, and post-delivery maintenance. Once those are settled, a fixed quote can be given.
Because a list price does not help you compare — it makes comparison harder. "Websites from £X" tells you nothing about what a job like yours means. I prefer to state the items that set the price openly, so you can see which one dominates in your case and genuinely compare the quotes you receive.
Fixed price, once scope is settled. Hourly work makes sense for ongoing development where scope cannot be defined up front; for a defined project a fixed quote is safer for both sides, because you know the cost in advance.
Additional requests are normal and expected. Anything outside scope is priced separately and is not carried out without your approval. The rule protects both sides: the work does not grow silently, and you do not see an invoice you did not expect.
Come with three answers: how many distinct screen types, which external systems it connects to, and whether content is ready. With those three, a quote comes back much faster and much more accurately — and that holds whoever you ask.