What Actually Determines the Cost of a Custom Website?

The cost of a custom website is determined by the work required to achieve an agreed business purpose—not simply by its number of pages. Content preparation, design depth, reusable page types, integrations, languages, editing requirements and launch responsibilities all affect the scope. A reliable fixed quote becomes possible when those decisions are clear enough to define what will be delivered.

Two five-page websites can therefore be entirely different projects. One might use finished copy, existing brand assets and a simple enquiry form. Another may need a new content structure, original design system, two languages, a searchable catalogue and a connection to an external platform.

Both have five pages. They do not require the same work.

Start with the commercial job

Before discussing layouts or technology, define what the website is meant to do.

A website may need to:

• explain a complex service;
• generate qualified enquiries;
• support a sales conversation;
• establish credibility in a new market;
• present a portfolio or catalogue;
• route visitors towards a booking or application;
• give an internal team control over publishing.

This purpose affects almost every later decision. A lead-generation website needs a clear offer, evidence, useful qualification and dependable enquiry handling. A site supporting expansion into several European markets may need localized content, language-specific navigation and a structure that can grow without duplicating every implementation decision.

Choose one primary job for the first release. Supporting goals are useful, but treating every possible outcome as equally important usually creates a larger and less coherent scope.

Map the scope across six areas

You do not need to arrive with a technical specification. You do need enough clarity for the designer and developer to understand the work and identify the remaining unknowns.

The following six areas form a practical scoping framework.

1. Audience, offer and conversion path

Who is the site for, what do they need to understand, and what should they do next?

A website aimed at local owner-managed businesses will not need the same journey as a B2B startup selling to several decision-makers. The latter may require material for technical evaluators, commercial buyers and end users, each entering the site with different questions.

For each important audience, define:

1. what brings them to the site;
2. what problem they are trying to solve;
3. what information they need before acting;
4. what a useful next step looks like.

This determines the information architecture, calls to action, form design and content hierarchy. Without it, estimating “a homepage and four subpages” says little about the actual work.

2. Content and page types

Page count matters less than the number of distinct content patterns.

Ten articles using one template are different from ten pages that each require a separate structure. A services page, case study, team profile, resource library and location page all have different content models and design requirements.

The quote also depends on who is responsible for:

• writing or rewriting copy;
• translating or localizing it;
• sourcing and preparing photography;
• creating diagrams or illustrations;
• entering content into the finished site;
• moving material from an existing website;
• reviewing and approving each language version.

“Content will be provided” is not a complete scope unless the content exists, has an owner and can be delivered in a usable format.

3. Design depth

Custom design is not a single level of effort.

A business with an established brand system may need that system applied thoughtfully to the web. Another may have only a logo and require decisions about typography, colour, spacing, imagery, interface components and visual tone.

Interactive details also matter. A restrained transition reused across the site differs from several bespoke animated sections with special behaviour on desktop and mobile.

The useful question is not whether the website should “look premium”. It is which design decisions must be created specifically for the project and which existing brand rules can be reused.

4. Functionality and integrations

A requirement should be described as a user flow, not only as a feature name.

Consider an “enquiry form”. The scope changes depending on whether it:

• contains three fields or several conditional steps;
• accepts file uploads;
• sends one notification or routes enquiries by type;
• writes data to another system;
• needs consent controls for different markets;
• shows availability or booking options;
• must handle several languages;
• requires protection against repeated or automated submissions.

The same principle applies to search, calculators, maps, gated downloads, user accounts and external APIs.

For each function, document what the visitor does, what data is involved, where that data goes, who manages the result and what should happen when a third-party service is unavailable. This exposes hidden complexity before it becomes a development surprise.

5. Publishing and internal ownership

A content management system should reflect the tasks the team needs to perform after launch.

“Editable content” could mean changing a paragraph twice a year. It could also mean publishing case studies, managing locations, updating team profiles and maintaining several localized versions of every service.

List the actions the team expects to complete without a developer:

• add a service;
• publish an article;
• replace a document;
• update a team member;
• create a translated page;
• change navigation;
• manage redirects.

This helps distinguish useful editorial control from unnecessary flexibility. Making every detail editable can increase complexity without making the site easier to operate.

6. Migration, launch and handover

A website is not complete merely because its templates have been coded.

The scope may also include content import, domain configuration, redirects from old URLs, form testing, analytics setup, access handover and coordination around the final release.

Existing sites introduce additional questions. Which URLs must be preserved? Is old content being rewritten, retained or removed? Are there active campaigns pointing to specific pages? Who can provide access to the domain, hosting, analytics and connected tools?

These responsibilities should be visible in the quote rather than left as assumptions at the end of the project.

Turn uncertainty into explicit assumptions

Not every decision needs to be final before a quote is prepared. Uncertainty does, however, need to be named.

A quotable scope might state that the first release includes one language, a defined set of page types and one enquiry flow. A second language, advanced filtering and a CRM integration can remain separate options.

This is more useful than adding a vague contingency for “anything else we may need”. It gives both sides a shared baseline and makes later decisions easier to evaluate.

Where an unknown could materially change the architecture—such as user accounts, payments or a large content migration—it should be resolved or separated into a discovery phase before the complete build is priced.

What changes a fixed quote?

A fixed quote applies to the agreed scope. It cannot sensibly cover unlimited changes to that scope.

A simple test is to ask whether a new request changes a template, user flow, data source, integration, language or delivery responsibility. If it does, it probably needs a separate estimate.

Typical quote-change triggers include:

• adding a new type of page;
• introducing another language;
• turning a basic form into a multi-step workflow;
• adding user accounts or restricted content;
• connecting a CRM, booking tool or other external system;
• requesting content migration that was not included;
• changing an approved structure after development has begun;
• transferring copywriting or asset preparation from the client to the project;
• adding functionality that requires new data or administration controls.

A change is not automatically a problem. The problem is allowing it to enter the project without acknowledging its effect on work, timing and responsibility.

What can be deferred?

A strong first release does not need to contain every planned feature.

Items that can often be considered for a later phase include additional languages, complex animations, secondary integrations, advanced filters, calculators and automations whose internal process is not yet settled.

Deferral is less appropriate for foundations such as clear navigation, coherent content, mobile usability, accessible key actions and reliable enquiry handling. Those elements shape the usefulness of the whole site.

Phasing should produce a complete, purposeful first release—not an unfinished site that depends on hypothetical future work.

When custom development is a poor fit

A custom website is not automatically the right answer.

A simpler solution may be more appropriate when the requirement is a temporary online presence, the organisation already has a suitable template, or the only meaningful selection criterion is the lowest initial cost.

A fixed-scope custom project is also a poor fit when:

• no one can approve the site’s goals or content;
• essential requirements change continually;
• the brief expects every possible future feature to be included;
• success depends on guaranteed rankings, sales or another outcome that a website alone cannot promise;
• the team cannot provide content, access or feedback;
• there is no distinction between launch requirements and future ideas.

In those situations, clarifying the business problem first is more responsible than presenting a precise-looking quote built on unstable assumptions.

Prepare a better enquiry

A useful first enquiry can be concise. Include:

• what the business offers;
• who the website needs to reach;
• the primary action visitors should take;
• what content and brand material already exist;
• required languages;
• essential functions or integrations;
• who will maintain the site;
• any deadline linked to a real business event;
• who will approve decisions.

It is also helpful to separate requirements into needed for launch, useful later and not yet decided.

I handle both design and development, so you communicate directly with the person doing the work. The agreed scope receives a fixed quote before work starts.

You can read more about custom website design and development. If you already have a rough scope, send it through the contact section; I reply within 24 hours.

← Back to the blog