Note from the workbench
Page count does not define a website
“How much does a five-page website cost?” is a reasonable question. Anyone making an investment wants a concrete reference, and page count looks like the simplest measure. I use it in my pricing too, to outline the packages. The problem begins only when that number is treated as if it described the whole project.
The point
Page count matters, but it is not enough. It measures part of the editorial volume; it does not reveal how many templates, content types, journeys, languages, data and features need to coexist in the website. This is why Essential, Pro and E-commerce share the same technical standard, but not the same scope.
The question is not wrong. It is incomplete
When someone asks me how much a website costs, they almost always add a number: three pages, five pages, perhaps seven. It is a natural reference. Pages are visible, can be listed and seem to turn complex work into something measurable.
That number has meaning. Every page needs a purpose, a title, content, metadata, internal links, correct rendering across different screens and checks before publication.
It does not say whether those pages will use the same template or different layouts. It does not reveal how many journeys they must support, whether there will be more than one language, which data they must present or what they must do.
Two websites with the same page count can therefore require very different scopes, responsibilities and timelines.
The count is a useful starting point. It becomes a problem only when it replaces the analysis.
What a page actually measures
A web page is not a sheet waiting to be filled. It is a resource within an architecture: it needs to be found, understood, connected to the other pages and maintained over time.
Page count primarily describes volume. Defining the project requires at least three more dimensions.
Volume
How many public resources need to be organised, connected and checked.
Structure
How many genuinely different layouts are needed to present that content.
Goals
How many needs, destinations and actions the website must support.
Behaviour
Which data, rules, external services and failure cases become part of the project.
The same count can therefore describe a compact website built from a few coordinated templates, or a system with much more complex sections, logic and responsibilities. The number stays the same; the actual work does not.
Essential does not mean reduced quality
In my services pricing, Essential describes a compact website: one page or a small set of coordinated pages, a few templates and one primary journey. A fixed price is possible because the scope is clear.
It does not mean receiving a technically reduced website. Design and brand application, semantic responsive code, a protected contact form, security, performance, baseline accessibility, technical SEO, relevant structured data and GEO readiness all belong to the shared standard.
What is removed is not care. It is complexity that the project does not require.
A website with only a few pages can therefore fall outside the Essential scope when it requires many templates, complex content, several conversion journeys, additional languages or bespoke features.
The fifth page does not turn a website into Pro by itself
The threshold shown in the pricing is not a tax on the fifth page. It provides an immediate reference; it does not replace an assessment of the project.
A three-page website with a calculator, data from an external service and separate journeys can be more complex than seven compact information pages built from the same templates.
This is also why the Pro package starts from a figure instead of assigning one price to every possible case. As templates, content, languages, features or journeys increase, so does the work required to design, connect, test and maintain them.
The final quotation resolves that uncertainty before work begins: it turns specific needs into activities, inclusions, options and verifiable boundaries.
One feature can outweigh many pages
A standard protected contact form is not a booking system. A booking system must manage availability, rules, confirmations, errors, notifications and often an external service.
A catalogue is not merely a succession of product pages. When it becomes e-commerce, products, variants, basket, checkout, orders, payments and operational responsibilities continue beyond publication.
An additional language or editorial section also extends beyond the number of initial pages: it requires architecture, metadata, navigation, update workflows and content that remains consistent over time.
Bespoke features, integrations, licences and external providers must therefore be assessed separately. The space they occupy on screen does not measure the work required to make them reliable.
The technical standard does not change with the package
A small website is no less in need of security, speed, readability, keyboard access or content that search engines can understand. The scope changes, not the level of robustness I consider necessary for publication.
The packages therefore share a technical foundation: semantic responsive code, protected forms, security measures, attention to performance, baseline accessibility, technical SEO, relevant structured data and preparation for search and AI systems to read the content.
They also share declared limits. Baseline accessibility is not certification or a complete WCAG compliance engagement. SEO and GEO do not promise rankings or citations. Commercial outcomes and final metrics cannot be guaranteed before the website has been built, published and measured.
To me, professionalism includes both: what I commit to delivering and what it would not be serious to promise.
The shared standard defines how solid the foundation must be. The package defines how broad and complex the project must be.
A serious quotation also defines its boundaries
Defining the project means stating what is included, who supplies copy, images and translations, which features are excluded, which costs belong to external services and which dependencies can affect the work.
A generic phrase such as “complete website” clarifies none of this. A written scope makes it possible to compare the proposal with actual needs and reduces surprises during development.
What happens after publication must also remain separate from the initial project. Ongoing maintenance, one-off work and future development follow different arrangements and can be handled through CARE, SPOT or a separate quotation.
A declared boundary does not limit the relationship. It protects both parties and makes it possible to decide consciously when the website needs to grow.
The client is not buying a number
Page count is useful for orientation, but it is not a universal unit of value. The client is buying a coherent set of decisions, content, journeys, features and technical responsibilities.
Essential means a more compact scope, not lower quality. Pro accommodates more complex architectures and goals. An e-commerce website does not simply add pages: it introduces a commercial process that must keep working once the website is live.
Part of my work is making those differences visible before acceptance, so the price does not depend on an opaque formula and the project does not begin with incompatible expectations.
Pages can be counted. A project has to be defined.