How much does a website cost? A practical guide to pricing

The question behind the price

Business owners rarely want a number for its own sake. They want to know whether the investment is justified, what could go wrong, and what will happen after the website launches.

“How much does a website cost?” is therefore several questions combined:

• How large and complex is the project?
• How much uncertainty or technical risk does it involve?
• Who will maintain the website after launch?
• Who will own the domain, accounts, content, and code?
• What business result is the website expected to support?

Once you frame the question this way, proposals with very different prices begin to look less arbitrary.

What you are paying for beyond the number of pages

A website proposal usually includes more than visual design and development. Depending on the project, it may cover:

• discovery and project planning
• information architecture and page structure
• messaging and content organization
• visual design and UX decisions
• frontend and CMS development
• mobile behavior and performance optimization
• accessibility and technical SEO foundations
• forms, analytics, booking systems, CRM, or payment integrations
• testing, launch, documentation, and handover
• training and post-launch support

The more of these responsibilities are included, and the more judgment they require, the higher the price will usually be.

When an offer appears unusually cheap, I tend to find one of two explanations: either the scope is much smaller than the buyer assumes, or important work has been marked as optional or left out completely.

Scope is the largest pricing factor

Five pages based on one reusable layout are not the same project as fifteen pages with several templates, custom components, multilingual content, and multiple conversion paths.

Before comparing prices, clarify:

• How many unique page types and layouts are required?
• How much content already exists, and who will prepare the rest?
• How many forms, integrations, and workflows are needed?
• Is the design custom, adapted from an existing system, or based on a template?
• Does the project require custom functionality?
• How many languages, markets, or audience segments must the website support?

Without those answers, comparing two prices is mostly guesswork.

A page count alone is not enough. Ten pages using the same structure may require less work than three pages with completely different functionality.

Uncertainty is where cheap projects become expensive

Price also reflects how much uncertainty the developer or agency is expected to absorb.

A fixed-price proposal based on a vague brief usually leads to one of two outcomes: the price includes a large safety margin, or the project eventually produces compromises, extra charges, and disagreement about what was supposed to be included.

I have seen businesses accept a low initial price and pay again six months later because:

• the information architecture did not match the business
• the CMS was difficult for the team to use
• mobile performance was poor
• the website could not support the intended marketing plan
• ownership of important accounts was unclear
• seemingly simple changes required rebuilding entire sections

Technical risk can also hide in the delivery model:

• no staging environment or reliable backup process
• dependence on one account controlled by the vendor
• an excessive plugin stack
• a page builder that makes future changes fragile
• custom functionality with no documentation or tests

A serious proposal clearly states what is included, what is excluded, and which assumptions the price depends on.

Maintenance is part of the actual cost

Launch day is not the end of the investment. Websites need software updates, security checks, content changes, performance reviews, and occasional repairs.

If nobody owns that work internally, the business will eventually choose between:

• a monthly maintenance agreement
• support billed when needed
• technical debt that remains invisible until something breaks

Before signing a proposal, ask:

• Who handles updates after launch?
• Is a post-launch support period included?
• What counts as a bug, and what counts as a new request?
• What are the hourly or monthly support rates?
• Who responds if something breaks on a Friday afternoon?
• Are backups and security monitoring included?

The initial build price matters, but so does the total cost of ownership over the next several years.

Ownership matters more than most buyers expect

You should know who controls:

• the domain
• hosting and DNS
• CMS administrator accounts
• analytics and Search Console properties
• third-party services and API accounts
• design files and source code
• website content and media

If a provider keeps everything inside its own accounts “for convenience,” moving to another partner later can become slower and more expensive.

Some managed platforms legitimately retain parts of the underlying code or infrastructure. That can be a valid model when it is explained before signing. The problem is not the arrangement itself, but discovering it only when you want to leave.

Clear ownership and handover terms are signs of a professional proposal, not optional extras.

Business value matters as much as production cost

Two websites can cost similar amounts and deliver very different results.

A simple website that confirms a business exists may be perfectly adequate for some companies. A website expected to generate qualified inquiries, support a sales team, process bookings, or reduce support requests is a different product and should be planned accordingly.

When discussing a website budget, I ask:

• What should a visitor do after arriving?
• Which pages carry most of that responsibility?
• What information or proof does the visitor need before acting?
• How will we measure whether the website is doing its job?
• What would make the investment successful after six or twelve months?

If those answers are unclear, the main problem is not the price. It is the brief.

Market ranges are useful orientation, not quotations

Internet price lists and forum discussions can provide context, but they are not reliable quotes. Markets, currencies, team structures, quality standards, and project expectations differ too much.

In my guide to choosing between an agency and a freelancer, I include very rough European price ranges as orientation. A basic business website is often discussed in the lower thousands, while complex corporate, multilingual, and e-commerce projects move into much higher ranges.

Those numbers are not promises or fixed packages. They simply demonstrate how quickly costs change when scope, risk, and quality expectations increase.

The real price depends on your project, market, requirements, and choice of partner.

How to compare proposals properly

Use the same questions for every proposal:

1. Pages and templates: How many are included, and which require unique layouts?
2. Content: Who writes, edits, translates, and uploads it?
3. Design: Is it custom, adapted, or template-based?
4. Technical quality: Are mobile behavior, performance, accessibility, and browser testing explicitly included?
5. SEO and measurement: Will metadata, redirects, analytics, forms, and indexing be configured?
6. CMS workflow: Who will update the website, and is training included?
7. Support: What happens after launch, and how is additional work billed?
8. Ownership: Who controls the domain, hosting, accounts, design files, and code?
9. Exclusions: Which apparently necessary items are not included in the quoted price?

If two proposals differ by thousands but one cannot answer these questions clearly, the cheaper option may simply be incomplete.

Where it makes sense to save money

A limited budget does not automatically mean accepting a poor website. It usually means reducing scope deliberately.

Reasonable ways to save include:

• launching with fewer, better pages
• using a strong reusable design system instead of many unique layouts
• preparing content internally before development starts
• postponing non-essential integrations
• starting with one language
• improving an existing technical foundation instead of rebuilding everything

Saving money becomes risky when it removes testing, mobile quality, accessibility, ownership, backups, or basic performance work. Those shortcuts are likely to create costs later.

The decision I would make

Choose the proposal that matches the real scope, explains the risks, and leaves you in control after launch, not simply the one with the smallest number on the first page.

A website is rarely a one-time purchase. It is part of how the business presents itself, builds trust, supports sales, and serves customers. The appropriate price follows from the job it needs to perform.

Want a realistic opinion on your website budget?

Contact me with a short description of your project. I can help you understand what level of website you actually need, what the proposal should include, and where it makes sense to reduce costs without weakening the result.