July 2026
What actually drives the cost of a website
Page count is the number everyone asks about and it is rarely the thing that moves the price. Here is what actually does, and where I tell clients to spend less.
The first question is almost always some version of how much a website costs, usually followed by how many pages it will be. Page count is the easiest thing to count, which is why people reach for it. It is also one of the weaker predictors of effort. Five near-identical service pages are close to free once the first one exists. One page with a booking flow, payments and a custom calendar can absorb weeks. Here is what actually moves the number.
Unique templates, not pages
What costs time is the number of genuinely different layouts. A site with twenty pages built from four templates is a four-template job. A site with six pages that all look different is a six-template job and will take longer despite being a third of the size. When a client tells me the page count, my next question is always how many of those are structurally the same.
Functionality that touches money or time
Anything involving payments, scheduling or accounts moves a project into a different category. It is not the interface that costs, it is the edge cases: what happens on a failed payment, a double booking, a cancellation, a refund, a no-show. I have built at least seven booking systems and the flow itself was never the hard part. The hard part was every path that is not the happy one, and those have to be designed and tested whether or not anyone budgeted for them.
Who is creating the content
This is the most consistently underestimated line. If you supply finished copy and usable images, the project moves quickly. If copy has to be written, photography arranged, or a brand created before anything can be designed, that is real work that happens before the first layout. Projects rarely stall on design or code. They stall waiting for content, and that delay costs both of us.
Integrations
Every system the site has to talk to is a small project of its own: a CRM, an email platform, an inventory system, an analytics stack, a payment provider. Two integrations are routine. Six is a different job. It is worth listing them honestly at the start rather than discovering them at the end, because each one carries its own quirks and its own failure modes.
How much change you want mid-build
Some change is normal and healthy. But structural change after the build has started is expensive in a way that surface change is not. Swapping a headline or a colour is a conversation. Changing how a booking flow works once it is built can mean rebuilding rather than adjusting. I treat the flow the way a builder treats foundations: agreed on paper before construction, and any change after that priced as the structural work it really is.
Where I tell people to spend less
Plenty of clients arrive asking for something bigger than they need. A booking system when a contact form and a phone number would convert better. A custom build when a well-executed template site would serve them for three years. A blog nobody has time to write. I would rather scope it down and have you come back next year than sell you the larger version and watch it go unused. Around 60 to 70 percent of my clients come back for more work, and I think honest scoping is a large part of why.
The useful question
Instead of asking what a website costs, tell me what you are trying to achieve and what has to be true for it to be worth doing. I will tell you what that actually requires, what it does not, and where the money is better spent. That conversation is more useful than any number I could put on a page, and it is free.
Working on something like this?
I take projects from brief to delivery. If this note resonated, the case studies show the same thinking applied.