Website Development Cost: Price the Artifacts, Not the Pages

A website development cost estimate prices hours, and hours are set by how many things a human has to author — not by how many pages the finished site has. Those two numbers diverge hard. This site has 336 prerendered routes and 27 page files, a ratio of 12 to 1, and the gap between them is where most of a quote's variance actually lives.

The published cost guides answer this question with a bracket, and the brackets are real: they run from a few hundred dollars for a builder-based DIY site to six figures for a large custom build, segmented by site type and complexity. A 200× range is not a plan, though. It is a statement that the question is underspecified, and the thing left unspecified is almost always the ratio above.

So we are not going to add another bracket. We did not measure agency rates, and reciting someone else's is not a cost breakdown. What follows is the itemised authoring cost of one live storefront, read out of its own repository and its own production build, plus the three line items that quotes routinely leave out and clients routinely pay anyway.

The unit that actually meters: authored artifacts

Ask "what does a 300-page website cost" and you have already asked the wrong question, because a page is not a unit of work. An artifact is: a file some person wrote, reviewed, and now has to maintain. Pages are output. Artifacts are input.

Here is this site's ratio, from a production build:

Three files — templates/[slug]/page.tsx, blog/[slug]/page.tsx and blog/[slug]/opengraph-image.tsx — produce 307 of the 336 URLs, 91% of the site. The 111 product pages are one file. The 98 blog posts are one file, plus 98 social cards from a second.

That is the whole cost argument in one table. A quote that prices 336 pages and a quote that prices 27 page files describe the same finished website and differ by an order of magnitude, and which one is honest depends entirely on whether the pages are derived or hand-built.

The test that tells you which you are buying

Ask the person quoting: if we add the 112th product, what does someone have to do?

There is no right answer — a nine-page brochure site should absolutely be nine hand-built pages, and deriving them would be overhead for nothing. But the answer is what the estimate hinges on, and it is knowable in one sentence before you sign anything.

We learned the failure mode of the hand-built end the expensive way. Our category hub pages used to carry hand-maintained arrays of product slugs. Those arrays stopped covering new products, silently, and 24 products ended up on no category page at all — nothing errored, nothing failed a build, and the pages were simply wrong until someone measured. The hubs are derived from the catalog now, and a test fails if any available product ends up off every hub. The rewrite cost a day. Not doing it cost months of index coverage. The full post-mortem is here.

Line item one: the correctness floor

Every quote prices building the thing. Few price knowing it still works, and this is the line that decides whether year two costs what year one did.

# .github/workflows/ci.yml — runs on every push and every PR
- run: npm ci
- run: npm run lint
- run: npm run format:check
- run: npm run test --if-present
- run: npm run build

Behind npm test:

Test Files  31 passed (31)
     Tests  305 passed (305)
  Duration  3.08s

305 tests, 31 files, three seconds. Almost none of them test React rendering. They test the things that silently rot in a content-heavy site: that every product slug referenced by a blog post exists, that every image path resolves to a real file under public/, that every product appears on at least one category hub, that no sitemap date is a build-clock reading rather than a real modification date.

That suite is a real construction cost — call it a few days of the build — and it is the cheapest insurance in the estimate, because the alternative is not "no tests." The alternative is a human clicking 336 URLs, which nobody does, which means the alternative is actually finding out from a customer.

Budget it explicitly. A quote with no line for automated verification has not removed that cost; it has moved it into your maintenance retainer and relabelled it "bug fixes."

Line item two: the rework pass after "done"

The most reliably underestimated part of a website is the work that happens after it looks finished. Not scope creep — correctness. Accessibility, performance, metadata and structured data are graded by machines that do not care that the design was signed off.

This site went through that pass twice, and the second one only happened because the first was scoped to three pages. What the extension to every page and to mobile turned up:

Note what those have in common: every one shipped through human design review and looked correct. A contrast ratio short by one hundredth is not visible. A missing <h1> is not visible — the page has a large bold heading, it is just marked up as something else. This is the category of defect that only a measuring pass finds, and it exists on every site that has not had one.

The honest way to put this in an estimate is as a distinct phase with its own hours, after the build and before launch, with a named exit criterion. Ours is Lighthouse accessibility and SEO at 100 on desktop and mobile for every main page. Score 100 is not a claim of WCAG conformance — we wrote about exactly that gap — but it is a threshold a machine can check, which makes it something you can hold a vendor to.

Line item three: what keeps costing after launch

Three meters keep running. Only one of them is infrastructure.

Dependencies. Thirteen runtime dependencies and thirteen dev dependencies, declared. The lockfile resolves them to 633 packages — 204 runtime, 429 dev-only. Each is a future upgrade, an occasional advisory, and a share of the risk that a major version lands and something breaks. This is why "we used a lighter stack" is a real cost argument and not just taste, and why a dependency count belongs in a proposal.

Content. The largest single body of hand-written material here is not the application. It is 15,877 lines of article prose across 98 posts, against 31,510 lines of everything else. On a marketing site, content authoring eventually outweighs the build that carries it — and unlike the build, it never stops. A cost model that ends at launch has priced the smaller half.

Infrastructure. Genuinely the smallest line, and the one people obsess over. It is set by four architectural decisions rather than by traffic; we itemised them separately in the storefront cost breakdown.

Four ways to get a website, priced by artifact

Two things that table deliberately does not have: a price column, and a winner. The buy-versus-build break-even genuinely depends on whether the interface is the product, which we worked through in template vs. building from scratch.

What it does show is that the cost never disappears — it relocates. A builder converts build hours into a subscription. A template converts build hours into comprehension hours. From-scratch keeps them as build hours and adds the maintenance. The cheapest option is the one that puts the cost where you can actually absorb it.

Mistakes and how they show up

Frequently asked questions

How much does a website cost to develop? The honest answer is that the range published anywhere is too wide to plan with, because it aggregates sites whose scope differs by orders of magnitude. What narrows it is three questions you can ask before any number is quoted: how many page templates does a human write, is the verification suite in the build or in the retainer, and who authors the content. A quote that answers those is comparable. One that gives a per-page rate is not.

What actually drives website development cost up? Hand-built pages that should have been derived, and rework after launch. This site's 336 URLs come from 27 page files; the same site with 336 hand-built pages would be a completely different project at the same visible scope. The second driver is the accessibility, performance and metadata pass — real work that arrives as a surprise when it is not in the plan, because the site looks finished before it starts.

Is a cheap template a false economy? Only if you buy it on appearance. What a template cannot fix after purchase is its architecture, its accessibility baseline, and its licence terms — everything else is your code now. Judge it on the parts you cannot change: run Lighthouse on mobile, open the inner pages rather than the home page, count the routes that actually exist. Ten checks, in order.

What is a realistic ongoing cost after launch? Three meters, in descending order of what they usually cost: content authoring, dependency and framework upgrades, then infrastructure. Most budgets rank them backwards. On this site the prose outweighs the application code by half again, and infrastructure is the smallest line precisely because the architectural decisions that meter it were made deliberately at build time.

Should I pay for a redesign or a rebuild? Ask whether the current site's pages are derived or hand-built. If they are derived from data, a redesign touches the templates and is genuinely cheap. If each page is bespoke, a redesign is a rebuild and pricing it as a design job will overrun. The ratio in the first table of this post is the diagnostic — get your current site's version of it before you scope anything. What a redesign actually costs prices that same split — new copy and imagery against new architecture — for a site that already exists.

Templates that start you past the build cost

ASoc Synth, ASoc Tempo and ASoc Till ship the layer this post prices as the expensive one — responsive layout, dark mode, the accessibility baseline, and the states nobody scopes — so your hours go to the parts that are actually yours.

Browse the sets: Next.js landing page templates and Tailwind landing page templates. If you are weighing the buy-versus-build decision itself, start with template vs. building from scratch; if the recurring infrastructure bill is what you are trying to bound, the four decisions that set it is the companion to this one.