What affects the cost of a business website?

A useful estimate starts with decisions, not a universal price

A five-page brochure site and a five-page booking product can have very different workloads. The second may need availability checks, account permissions, payment handoffs, failure states and ongoing coordination with another supplier. The page count hides that difference.

This guide does not offer a market price range. It explains what should be specified before a quote is meaningful. Ask for the currency, applicable charges, payment milestones and assumptions in writing, and compare the same work across proposals. A price without its scope is difficult to judge.

Identify the work that changes the build cost

Use the following questions to turn a vague request into a scope discussion. Not every row needs custom work. Reusing an existing identity, retaining a suitable booking platform or supplying approved photographs may simplify delivery.

Separate the four parts of the budget

The build budget covers the agreed planning, content, design, implementation and launch work. Recurring service costs may include domain renewal, hosting, email, booking software, paid assets or usage-based tools. Maintenance covers agreed operational tasks. New pages, features or campaigns belong in a future-change budget unless explicitly included.

Ask for an ownership and payment list: the service, account holder, billing frequency, renewal responsibility and what happens if it is cancelled. Record which subscriptions are essential to the launched site and which are optional.

A practical comparison is the initial build plus the known operating and support costs for your chosen planning period. Add any agreed migration, training or exit costs. Keep paid advertising separate; funding a website does not automatically fund the work needed to bring visitors to it.

• Initial: discovery, content, design, implementation and launch.
• Recurring: domain, hosting, email, paid services and usage charges.
• Ongoing: maintenance, content changes, monitoring and support as agreed.
• Future: additional languages, functionality, campaigns and integrations.

Fictional scope comparison: the same business, two different projects

This is a fictional planning example, not a quote or a client result. A six-room guesthouse wants to improve its online presence. It already uses a booking service. In the first version, visitors can compare room types, read practical information and continue to that existing service to reserve.

A second version adds guest accounts, a custom reservation calendar, deposits, staff permissions and automated changes to inventory. Both could be described casually as “a guesthouse website,” but the second introduces a much larger operating system.

The buyer should first ask whether the booking service already handles those needs. If it does, a clear handoff may be a better use of the first budget. If it does not, the missing functions should become a separate specification with maintenance responsibilities, rather than an assumed extra in the visual redesign.

Cut scope in ways that preserve usefulness

When the budget is tight, choose the smallest complete customer journey. That might mean launching one priority service and one approved language before expanding, or using an existing booking tool while the business tests demand. Record deferred work so it does not disappear into an ambiguous promise.

Keep the essential facts, mobile usability, working contact route and honest confirmation messages. Removing those can leave a visually finished site that your customers cannot use. Elaborate motion, secondary pages or an early-stage custom dashboard may be easier to defer.

Content readiness also matters. An agreed launch date should explain dependencies: approved copy, real product photographs, third-party access and feedback from a named decision-maker. Repeatedly changing the offer late in the build creates work even when the page count stays the same.

Understand what “ownership” buys you

Ask which source files, accounts and editing permissions are included in the price. Clarify how another developer would continue the work. A managed service can be a good choice, but its ongoing cost and transfer limits should be understandable before you buy.

For example, WordPress’s built-in content export creates an XML file containing supported content records. That is useful, but you should not assume a content export alone recreates the complete website. Ask for a separate explanation of backups, media, themes, plugins, configuration and the proposed recovery process.

For support, distinguish an agreed post-launch correction period from an ongoing change service. Ask how a broken form is handled, how routine updates are scheduled and how additional work is approved. “Maintenance included” is incomplete unless the tasks, duration and responsibilities are named.

Prepare a brief that can receive a useful quote

A suitable fixed scope is possible when the core journey, content and dependencies are understood. Paid discovery or a smaller pilot can be more sensible when several systems must connect or the product’s behaviour is still being decided. A template-led setup can also be appropriate for a straightforward need with a capable internal editor.

Before requesting a proposal, write down the business goal, required pages or journeys, launch languages, available assets, existing domain and tools, editing needs and preferred support arrangement. Separate “must launch” from “later.”

Bring that brief to a consultation and ask for a recommended first release, exclusions, recurring costs and a change process. You can then decide whether the proposal solves the right problem at a commitment your business can maintain.