Page count describes the quantity of public content, but it does not fully represent content preparation, custom design, CMS, form data, user permissions, languages, integrations, testing and handover. Two websites described as five pages may be very different: one places approved text into an established layout, while another requires content discovery, a multilingual CMS and an enquiry administration workflow. A fair comparison aligns what is included, who provides each input and how completion will be accepted.
Do not compare only total price and page count. Compare the delivered scope against the same requirements.
Page count can still be useful, but it is only one measurement. If the proposal does not define content depth, shared components, administration, external services and launch responsibilities, similar totals may represent entirely different projects.
Why can two five-page websites require very different work?
Imagine that both businesses request Home, About, Services, Work and Contact:
- Project A provides approved copy and suitable images, uses an established layout, sends a simple form by email and operates in one language.
- Project B needs stakeholder interviews, a distinctive visual system, old-content migration, three-language management, retained enquiry records, role permissions, analytics and notification integration.
The public page count is the same. Project B includes content strategy, data modelling, administration, language operations, integrations and broader acceptance. Describing both only as a “responsive five-page website” conceals the difference and makes later changes difficult to manage.
Eight factors that shape website scope
1. Content readiness
A website needs more than several paragraphs. Brand positioning, service names, audiences, actions, case permissions, image quality, translation and legal notices all need owners. When content is not ready, the project may include interviews, architecture, writing, editing, selection and migration.
Confirm before pricing:
- Who supplies text and images?
- Is the supplier formatting, editing or writing from interviews?
- Are cases and images cleared for public use?
- Is all old content being migrated or reviewed first?
- Who approves facts and each language?
2. Template use, adaptation or custom design
Using a proven template, adapting it to a brand and designing around the content are different scopes. Custom interface work usually includes hierarchy, component states, mobile behaviour, errors, empty states, loading and interaction, not only one desktop homepage image.
“Custom design” should specify:
- Which pages and shared components are included?
- Are desktop and mobile reviewed separately?
- How are revision rounds defined?
- Are forms, menus, dialogs and error states included?
- Who supplies the logo, fonts, colours and photography?
3. CMS and operational administration
A service page may be a fixed file or a CMS entry with title, sections, media, SEO, dates and language versions. The public output may look similar, but the latter requires data structure, permissions, validation, drafts, preview, publishing and administration.
Content management must also be distinguished from operational administration. A CMS manages articles and pages; an operational system may manage enquiries, orders, bookings, members, assignments and private notes. The word “admin” does not make these scopes equivalent.
4. Data and workflow complexity
A form collecting name and email is not the same as a formal enquiry with service, budget, attachment, consent, source and status. A basket is not just a button; it relies on products, options, stock, payment, order records, notifications and exception handling.
Ask:
- Which data records will the website create?
- What statuses can each record have?
- Who can view, edit, delete or export them?
- Is the record retained if email delivery fails?
- How are duplicates, changes, cancellations or refunds handled?
- When is personal information deleted, and by whom?
5. Languages and market versions
A multilingual website is not simply one page with replaced words. Each language needs a stable URL, reviewed content, page title, search description, image alternatives, language navigation, canonical and hreflang. If products, services or legal information vary by market, sentence-by-sentence translation may be inappropriate.
The proposal should separate translation, language review, content entry and technical implementation. It should also define whether an incomplete language version remains private or follows an explicit fallback rule.
6. Third-party services and integrations
Payments, delivery, email, messaging, maps, booking, CRM, accounting, analytics and social login depend on other providers. Each connection may require account setup, permissions, API work, test and production environments, failure handling and recurring fees.
Clarify:
- Does the build include connection and testing?
- Who pays platform, transaction and message fees?
- Who responds when the provider changes or ends a feature?
- Who creates and owns test and production accounts?
- How does the website retain data and alert administrators during failure?
7. Testing, launch and search foundations
Working on the supplier's computer is not the same as being ready for production. Launch may include domain, DNS, HTTPS, production hosting, database, backup, email, error pages, responsive testing, browsers, forms, permissions and performance.
Where SEO foundations are included, define whether the scope covers page titles and descriptions, canonical, hreflang, Sitemap, robots, structured data and redirects from old URLs. Technical SEO helps search engines discover and understand a site; it does not guarantee rankings.
8. Handover, training and maintenance
After launch, the business should know who controls the domain, hosting, source, data, design assets and highest-level access. It should know how content is changed, backups are restored and incidents are escalated. “Launch complete” is not a sufficient handover definition.
Confirm:
- Are training and operating notes included?
- How are the domain, hosting, source and database handed over?
- How are defects distinguished from new requirements?
- What are the warranty scope and period?
- Are maintenance, provider changes and content operations separate services?
- How can accounts and data be transferred when the relationship ends?
A proposal comparison checklist
| Area | Question to answer | Common omission |
|---|---|---|
| Content | Who writes, reviews, translates and approves? | “Client provides content” without format or deadlines |
| Design | Template, brand adaptation or custom system? | Homepage approved without mobile or component states |
| Front end | Which pages, components and interactions? | Pages with the same name have very different depth |
| CMS | Which fields and languages are editable? | Assuming every visible area can be edited |
| Operational data | How are forms, orders or bookings retained and assigned? | Email only, with no record or delivery fallback |
| Integrations | Which external services are connected? | Platform, transaction and account ownership not listed |
| Testing and launch | Which devices, workflows and environment must pass? | No production data, backup or error-state testing |
| SEO | Which technical foundations are delivered? | Treating setup as a ranking guarantee |
| Handover | Who controls accounts, source and data? | No training, recovery or transfer path |
| Maintenance | Which services continue after launch? | Warranty, changes and subscriptions are unclear |
How to compare two proposals fairly
Start with one requirements baseline
Give each supplier the same brand information, page goals, essential functions, languages, data, integrations and timing. If each supplier receives different information, the totals cannot be compared directly.
Mark every item as included, client-supplied, additional or excluded
Do not rely on feature labels. Review content, design, CMS, forms, integrations, testing, launch, training and maintenance. Ask for specific definitions of broad phrases such as “basic SEO” and “admin system”.
Define acceptance
Each important function needs an observable completion condition. “Enquiry system complete” should cover required-field validation, successful receipt, administration retention, notification, duplicate submission and failure handling, not only a visible form.
Separate build cost from recurring cost
Hosting, domain, paid extensions, email, payment, messaging, media rights and maintenance may continue after launch. Separate one-time implementation, provider fees and ongoing support to understand total ownership.
Compare risk and handover as well as feature count
More features do not automatically mean a more complete project. Ownership, backups, permissions, documentation and exception handling often reduce operational risk more effectively than a long list of undefined functions.
Items that should not remain “to be decided later”
- Ownership of domain and hosting.
- Who prepares content and images, and when.
- Migration of production data.
- Where a failed form or order can be found.
- External fees and account ownership.
- Publication rules for incomplete language content.
- Difference between draft, preview and production.
- Backup coverage and restoration responsibility.
- Boundary between warranty, content change and new development.
- Files, data and access delivered at completion.
These are not minor details that appear only after launch. They determine whether the website can be operated, accepted and transferred.
How can a client reduce avoidable cost?
Reducing cost does not mean removing quality controls. It means reducing repeated decisions and unnecessary scope:
- Appoint one owner who can consolidate internal decisions.
- Approve positioning, services and page goals before visual design.
- Prepare publishable copy, images and case permissions early.
- Separate essential functions from future ideas.
- List current systems and required integrations.
- Return consolidated feedback on the agreed schedule.
- Approve data and workflow before refining every visual detail.
- Record scope changes so additions are not lost in conversation.
Frequently asked questions
Is page-based pricing always unreasonable?
No. For simple websites with highly consistent content and layouts, page count can be one useful unit. The problem is using it as the only unit without defining depth, shared design, administration and integration.
Does a higher quote guarantee better work?
No. Price alone is not evidence of quality. Review whether the proposal understands the requirement, defines scope, demonstrates relevant work, explains ownership and acceptance, and provides a workable communication process.
Why does a CMS add scope?
A CMS is not only a set of fields. It needs data structure, validation, permissions, drafts, publishing, media, error handling and front-end output. More roles, fields and languages require broader planning and testing.
Should third-party fees be included in the website quote?
They should be disclosed, but they do not have to be absorbed by the supplier. Implementation, platform subscriptions, transaction charges and maintenance should be separated, with clear account ownership.
Why is an early figure sometimes only an estimate?
Because data, roles, exceptions and integrations are not yet defined. A responsible early estimate states assumptions and ranges or begins with requirements work. A fixed promise based on unclear inputs often creates additions and delays later.
Conclusion: connect price to a clear scope
A useful website quote explains what the business receives, what the business supplies, what is excluded, and how the result can be accepted and taken over. Page count can remain, but it cannot replace definitions for content, design, data, integration, testing and handover.
When each proposal uses the same requirements baseline, the business can compare approach, quality, risk and long-term operation instead of guessing why totals differ.
Continue with seven things to prepare before planning a business website and the website handover checklist. You can also review our website services or start a project with your goals, workflow and essential functions so Stage of Me can help define a comparable scope.
