Your Page Count Is Lying to You

Off By

Digital Measurement Paradox

Your Page Count Is Lying to You

Moving past the phantom units of digital construction to find the true value of architectural engineering.

On the corner of my desk sits a architectural scale ruler, a triangular piece of boxwood with markings so precise they feel like an indictment of our current era. This object represents a world where a foot was a foot, and a blueprint was a definitive promise of physical reality.

Precision of Physical Reality

If you were building a house, the number of doors was a fixed variable. If you were buying lumber, the board foot was a unit that, while flawed, at least corresponded to a volume of matter you could hold in your hands. In the digital world, we have no such scale, yet we continue to pretend that we do. We use the word “page” as if it were a physical brick, a standard unit of measure that translates across every agency, every client, and every procurement department.

The Ghost Unit of Scoping Calls

Since a digital interface has no fixed edges-varying by viewport, scroll depth, and state-the term describes a ghost rather than a reality. For a unit to be useful in a commercial negotiation, it must have a shared definition. Because no two people in a scoping call can agree on where a page starts and where a component ends, the entire pricing structure of the modern web industry is built upon a foundation of mutual misunderstanding.

Consider the scoping call. Ben, a marketing director who has spent the last forty-eight hours staring at a spreadsheet until the cells began to swim, asks a seemingly simple question: “Does the pricing table count as a page or a component?” The agency lead, eager to move the proposal into the “signed” column, offers a verbal shrug. They will call it a page for the estimate and figure out the specifics during the build.

Ben’s Budget

14 Pages

Agency Planner

14 Templates

Both men write down a number. Ben writes “14 pages” in his budget. The agency lead writes “14 templates” in his resource planner. Three months later, the change-order conversation begins. It usually starts with the sentence, “Well, that was never really a page.”

By then, the project has morphed. What was once a static table has become a dynamic, filterable component connected to a CMS collection. The “page” has dissolved into a system of 60 components and 340 published URLs, and the original estimate has become a relic of a conversation that never actually happened.

Static “Page”

60+ Living Components

The persistence of page-count pricing is a legacy convention that mirrors the “board foot” crisis of the 19th-century timber industry. Historically, a board foot was defined as a volume of wood twelve inches square and one inch thick. However, this unit failed to account for the quality of the grain, the presence of knots, or the moisture content of the wood.

The Board Foot Crisis of the 1880s

In the , a buyer could purchase a thousand board feet and receive warped, unusable sapwood, while another buyer received prime heartwood for the same price. The unit described the volume but ignored the work required to make that volume valuable. Eventually, the industry had to move toward more complex grading systems because the “board foot” was too blunt an instrument to facilitate fair trade.

SAPWOOD

$1.00

HEARTWOOD

$1.00

The original “Board Foot” fallacy: Charging for volume while ignoring structural integrity and grain quality.

Digital agencies are currently in their “board foot” era. We are selling volume while the client is buying functionality. We quote “14 pages” because it is a number that a finance department can process, yet the work required to build a single high-performance Webflow template with custom GSAP motion and a complex schema markup structure is vastly different from the work required to build ten static informational pages.

A website is a system, for a system is a collection of interdependent components that achieve a specific goal. Since components are reusable, their value is not additive but exponential. For this reason, counting pages is a linear solution to a non-linear problem.

When you build a CMS with four collections-say, team members, case studies, services, and blog posts-you aren’t building four pages. You are building an engine that can generate an infinite number of pages. This mismatch is rarely resolved in the early stages of a project; instead, it is paid for later by whoever has the least leverage.

If the agency is small and desperate, they “eat” the cost of the extra work to keep the client happy. If the client is locked into a rigid budget, they receive a hollowed-out version of their vision. I have reread the same sentence in a Master Service Agreement five times today: “Agency shall deliver 14 unique page designs.”

Each time I read it, I wonder if a “unique design” includes the mobile breakpoint, the tablet view, the hover states, the error states for the forms, and the success messages. Probably not. Those are the “invisible” pages that usually get built in the frantic final weeks of a project, far outside the scope of the original quote.

Why Websites are Verbs, Not Nouns

“Most human suffering comes from trying to name things that are in a constant state of flux. We want the world to be made of nouns, but the world is actually made of verbs.”

– Sky C., Mindfulness Instructor

Sky C., a friend who spent a previous life in corporate procurement, captured the crux of our industry’s struggle. A website isn’t a “thing” you buy; it’s a “performance” you host. When we try to count pages, we are trying to turn a river into a collection of buckets. We feel a temporary sense of control, but the river doesn’t care about our buckets.

The reality of modern web development, particularly within high-end ecosystems, requires a shift from design-led thinking to engineering-led thinking. In an engineering-led build, the unit of measure is the “component” and the “logic.”

If you are working with a partner like Coherent Agency, the conversation shifts away from the arbitrary page count and toward the technical architecture. They understand that a website for a global enterprise isn’t just a series of layouts; it is a conversion-focused machine that must integrate with SEO strategies, AEO (Answer Engine Optimization), and custom app engineering.

⚙️

Technical Architecture

Building robust systems that handle complexity behind the scenes.

🤖

AEO Integration

Optimizing for the next generation of answer engine crawlers.

Component Library

Reusable UI systems designed for effortless scale and consistency.

When you prioritize engineering, you realize that the “page” is just a specific configuration of a component library. If the component library is built correctly, adding the 15th page or the 340th URL should be a matter of content entry, not a structural crisis. However, building that library requires an upfront investment in architecture that a “page-based” quote cannot capture.

Purchasing Systems, Not Templates

Finance departments love the page-count model because it allows for easy comparison. If Agency A quotes $2,000 per page and Agency B quotes $3,500 per page, the choice seems obvious to someone who hasn’t seen the code. But this is the same logic that led the 19th-century timber buyers to purchase thousands of feet of warped wood.

$2,000

The Brittle Page

Hard-coded templates that break when you add new content.

VS

$3,500

The Scalable System

Enterprise-ready architecture designed to handle massive growth.

The $2,000 page is likely a brittle, hard-coded template that will break the moment a marketing manager tries to add a new category to the CMS. The $3,500 page is likely a scalable system designed to handle the weight of an enterprise-scale launch without requiring a developer ticket for every minor update.

We must define our terms explicitly before we use them. A “page” in a modern build should be defined as a unique template. A “component” should be defined as a reusable UI element with a defined set of states. A “CMS collection” should be defined as a database structure. If we do not use these terms, we are essentially negotiating in a dead language.

Beyond the Credit Card Peace Treaty

It is easier to sell a “20-page website” than it is to sell a “modular design system with integrated schema architecture and third-party API hooks.” The latter sounds expensive and complicated. The former sounds like something you can put on a credit card. But the complexity doesn’t vanish just because we refuse to name it.

It simply waits in the shadows until the middle of development, where it emerges as a series of awkward emails about “out of scope” features and “unexpected technical hurdles.” The number on the proposal is a peace treaty signed in a language neither side intends to speak once the war of construction begins.

To move forward, we have to stop asking how many pages a site has and start asking how many problems it solves. A single-page application that perfectly handles a complex financial calculation is worth more to a business than a 50-page brochure site that no one visits.

Value Drivers of Modern Engineering

Performance & Speed

Interactive Motion

3D Web Experience

The value is in the engineering depth-the motion work in GSAP, the 3D web experiences, and the pixel-perfect builds that load in under a second. When I look back at my architectural scale ruler, I realize that it worked because the medium was static. Paper doesn’t change size based on who is looking at it.

Digital interfaces are not static; they are living, breathing entities that exist in a thousand different states simultaneously. We cannot measure them with tools designed for paper. We cannot price them with units designed for the .

If you are a marketing director or a founder, your next website project will likely live or die based on whether you can move past the page-count lie. You need to look for a team that talks about systems, performance, and ownership of the outcome. You need to look for people who act as engineers rather than just decorators.

Only then can you stop pretending that you know exactly what a “page” is and start building something that actually works. The next time a proposal lands on your desk with a neat, round number of pages, take a moment to reread it. Look for the definitions that aren’t there. Ask the uncomfortable questions.