The useful question is not only what a website costs. It is what the website must do, how complex the operation behind it is and what underbuilding will cost later.
What actually drives the cost
Page count is a poor pricing shortcut. A concise site with several audiences, custom content workflows, integrations and strict accessibility requirements can be more demanding than a larger brochure site. The work is shaped by decisions, dependencies and risk—not simply by the number of screens.
The main cost drivers are usually discovery, content, experience design, engineering complexity, integrations, migration, quality assurance and post-launch ownership. If one of those areas is left vague, the uncertainty does not disappear; it tends to return as delay or rework.
- What action must each audience take?
- Who will create and maintain the content?
- Which systems must exchange data?
- What would failure cost after launch?
Compare scopes, not headline prices
Two proposals can use the same label while describing very different products. One may cover a template, supplied copy and a basic contact form. Another may include research, positioning, original content, a flexible design system, analytics, integrations and launch support. Comparing totals without normalizing the scope rewards omissions.
Ask every partner to state assumptions, exclusions, decision points and who owns each input. A strong proposal should make the work legible enough for you to understand why it costs what it does and what would change the estimate.
Fund the smallest complete version
A sensible first release is not the cheapest collection of pages. It is the smallest version that can perform its core job end to end: communicate the offer, establish trust, support a decision, capture the right action and produce useful evidence.
Stage optional capabilities when that reduces risk, but do not remove the foundations that make the site operable. Content ownership, responsive behavior, accessibility, performance and measurement are cheaper to design in than to retrofit under pressure.
Define the business job, surface the operational complexity and compare like-for-like scopes before comparing prices.
Working through a similar decision?
Talk it through with Zerobugg