What determines website cost?

By Uniqode

Two websites with a similar number of pages can require very different budgets. The difference often sits behind the design: the content model, integrations, migration and decisions needed to get the site live. A useful price conversation starts with the scope.

Look beyond the page count

Twenty pages built from a few reusable templates are different from twenty unique layouts with individual functionality. Ask how many page types and components are needed, what editors can change and which behaviours require development.

Use representative examples in the brief: a service page, project, event or product listing. Real content exposes requirements that a list of page names can miss.

The main scope decisions

  • Content and design: Is the structure ready? Who writes, edits and approves the text? Are brand assets and photography available?
  • Languages: How many language versions are needed, and do they share layouts, content and approval steps?
  • Migration: How much existing content will move? Does it need cleaning, restructuring or manual review?
  • Integrations: Which external systems exchange data with the website? Are documentation, test access and a responsible contact available?
  • Quality requirements: What needs to be checked for accessibility, performance, browsers, devices and important user journeys?
  • Delivery: Who can make decisions, how many review rounds are planned and what dependencies could hold up launch?

Two illustrative briefs

Brief A: a focused organisational website. A team has approved copy, one language, a small set of page templates and a straightforward contact journey. Most effort goes into design, implementation and testing within a stable brief.

Brief B: a multilingual publishing platform. Another team needs several languages, regional content differences, a large migration and a connection to an external system. Content modelling, coordination, migration validation and integration testing become substantial parts of the project.

These hypothetical examples explain why page count alone is a weak basis for comparison. They are not price estimates or descriptions of a particular client project.

Compare proposals on the same basis

Check whether each proposal includes the same work. A lower build price may exclude content preparation, licences, hosting or migration. Equally, a larger proposal may include work you do not need in the first release.

Ask how assumptions and changes are handled, which deliverables you receive and how completion will be assessed. Separate one-off project costs from recurring costs. Identify who owns the code, accounts and content, and how the website can be handed over later.

A brief you can copy

  • Our website must help these audiences complete these tasks: …
  • The first release must include: …
  • These features can wait: …
  • Our languages, page types and integrations are: …
  • We have this content ready, and these gaps remain: …
  • These people prepare content and approve decisions: …
  • Our budget range and target date are: …
  • We need these services after launch: …
  • These assumptions still need investigation: …

Get the unknowns into the open

A precise quote based on unclear assumptions is not necessarily a reliable plan. If the scope is still uncertain, a Website Roadmap can define the first phase before you commission the build. If the requirements are clearer, explore our Multilingual Website Rebuild.