What does it cost to build a website?

What determines the price of building a website?

Anyone searching for "how much does it cost to have a website built" is quickly faced with a wide range of prices, from a few hundred euros for a template site to a serious six-figure budget for a complex web application. That spread isn't a marketing trick. It simply reflects how broad the term "website" is. A one-pager with a contact form and a SaaS portal serving thousands of users both fall under the heading "website", but the build behind them is completely different.

For a realistic price picture, there are five factors that recur, whether you want a corporate brochure site, an online shop or a complex platform. Understanding these five levers lets you assess a quote better, and also know what happens when one of them is adjusted during the project.

• Functionality and complexity: how many different page types, how much interaction, and how much logic sits behind the scenes? A static site with ten pages is fundamentally different from a platform where users log in, carry out transactions and view data.
• Integrations with other systems: does the site need to talk to your CRM, ERP, accounting software, email marketing tool, a PIM or an external API? Each integration is a mini-project in its own right, with its own testing and maintenance.
• Design and branding: are you working with an existing brand book, or does a visual concept need to be developed first? How many rounds of revisions and how much custom work on components? Standard templates are inexpensive; custom design requires design days.
• Content volume and complexity: ten pages or three hundred? In one language or multilingual? Do you already have the text and images ready, or do editorial and photography also need to be arranged?
• Technical choices (CMS and codebase): an off-the-shelf CMS such as WordPress, a headless setup, a framework like Astro or Next.js, or fully custom in your own codebase. Each choice affects build time, maintenance burden and flexibility.

What types of websites are there, and how does the cost structure differ?

It helps to place your own requirements within a few clear categories. We typically see five types of project, and for each the bulk of the costs sits in a different place. Bear in mind that this is about where the budget goes, not about absolute amounts.

1. The brochure site or one-pager

A handful of static pages presenting your organisation: home, about us, services, contact. No accounts, no complex forms, no integrations. Most of the budget goes on design and content; the technology is relatively simple. For many freelancers, service providers and local businesses, this is the right level, provided it looks good and is technically sound for SEO.

2. The WordPress or template-based site

A more extensive site with a blog, news, case studies, and possibly a simple form or resource library. Often built on WordPress with a premium theme or a page builder. Here the budget shifts towards configuration, plugin selection, performance optimisation and setting up a CMS so that your own marketing team can work independently.

3. The webshop

For webshops, we look at the number of products and variants, the complexity of pricing rules, stock management, shipping and payment methods, and integrations with your back office. A Shopify store with ten products sits at the lower end of this range. A B2B webshop with customer-specific pricing, ERP integration, stock synchronisation and a complex quoting process sits at the upper end. You can read more about that on our Magento 2 website page.

4. The headless or custom corporate site

A site where marketing teams manage content in a modern headless CMS (Directus, Sanity, Contentful), while the frontend runs on a framework such as Astro or Next.js. Fast, SEO-friendly, multi-channel and flexible. The budget goes on architecture, component library, integrations with marketing tools and setting up an editorial workflow.

5. The web app or platform

A user portal, a SaaS product, a marketplace, a dashboard. This is no longer a "website" in the classic sense; it is a product. Here the bulk of the budget goes on functionality, user authentication, data models, business logic and testing. For the broader context, see our page on web development.

WordPress versus custom: what are the trade-offs?

This is probably the question we get asked most often: "Should we go for WordPress or custom?" The honest answer is that it depends on what you want to achieve, how long you expect the site to run and how closely your requirements match what WordPress does out of the box. Both options have legitimate use cases. The problem arises when you choose WordPress for something it wasn't designed for, or choose custom where WordPress would have been perfectly adequate.

The case for WordPress

• Lower initial investment. The CMS is free, there are thousands of themes and plugins, and many developers are available.
• Quick to get started. A professional site can go live relatively quickly if the functionality falls within standard capabilities.
• Familiar to marketing teams. Many marketers already have experience with the editor, so there's less of a learning curve.
• Huge plugin ecosystem. For SEO, forms, analytics, e-commerce, member portals: there is almost always a plugin already available.

The case against WordPress

• Performance. A typical WordPress site with multiple plugins is rarely as fast as a well-built headless or static site. For some use cases (think SEO-critical content or heavy media sites), that makes a real difference.
• Security and maintenance. Because of its popularity, WordPress is a major target for attacks. Whoever runs it needs to update it structurally, or vulnerabilities will emerge.
• Plugin rot. The more plugins you have, the more dependencies you have, and the more things that can break with an update.
• The custom-build limit. The moment your requirements fall outside what plugins can deliver, you end up with a tangle of workarounds.

Custom development comes into play as soon as you want to build something the standard tools don't offer, when performance is business-critical, or when you want to keep the site for more than a few years without maintenance becoming a second full-time job. We wrote about this at length in our knowledge base article build vs buy: when to choose what. The same reasoning applies to websites.

How is a website quote put together?

Broadly speaking, agencies build quotes for a website project in three ways. Which format suits your situation depends on how clearly you've already defined your requirements and how much uncertainty you can live with.

Fixed scope, fixed price

The classic approach. You provide a requirements document, the agency estimates it and then builds for a fixed amount. Advantage: budget certainty. Disadvantage: all the uncertainty is hidden in the price (agencies add a risk premium) or in the scope (if anything changes, extra work follows). It works well for projects where you know exactly what you want and the scope is no longer shifting, for example a redesign of an existing corporate site with the same functionality.

Sprint budget (time and materials)

The way we usually work. We work in sprints, at a fixed rate per sprint, and you decide sprint by sprint what has the highest priority. Advantage: you can adjust along the way, prioritise what matters most and stop when what's there is good enough. Disadvantage: you have to accept up front that the exact end date and final cost only become clear as you make decisions about scope.

Hybrid: discovery and build

You start with a short, paid discovery phase in which scope, design and technical approach are worked out. Only after that phase is the actual build budget estimated, often far more precisely, because the uncertainty has been removed. It works well for larger or more complex projects where you'd like to take the first step separately without being immediately committed to a large amount.

Where are the hidden costs?

The purchase price of a website is rarely the whole story. There are four categories of costs that are often overlooked, and which after a few years can add up to as much as the initial build costs.

Hosting and infrastructure

A site has to run somewhere. For a small WordPress site, that's a few tens of euros a month. For a serious e-commerce or platform application, it can rise to considerable monthly sums, especially once CDN, redundancy, backups and staging environments are involved. Always ask a supplier to estimate the annual hosting costs, not just the build budget.

Maintenance, updates and security

CMS updates, plugin updates, framework updates, security patches. A site that isn't maintained will sooner or later run into trouble. Plan for an ongoing hour or so a month, or a maintenance contract, depending on complexity. For a WordPress site with many plugins this is a more significant cost than for a static headless site.

Content creation and editorial

Many quotes assume that you will supply the texts and images. That sounds logical, until launch approaches and it turns out nobody in your organisation has the time. Budget for copywriting, photography, video and, if needed, SEO content in advance, or you'll go live with a beautiful shell and empty pages.

SEO, analytics and ongoing optimisation

Launching a new site is not the same as being found. Allow for a programme of technical SEO work (sitemaps, structured data, Core Web Vitals), setting up analytics and conversion tracking, and a steady rhythm of content expansion and optimisation. Agencies promising "SEO included" often only do the technical part, so ask exactly what is covered.

What determines a web developer's hourly rate?

A frequently asked question is "how much does a web developer charge per hour?". The answer varies widely by market, by level and by type of agency. We won't quote figures here, but we will outline the factors that explain why the range is so wide.

• Experience and specialisation. A junior front-end developer from a large pool sits at the lower end. A senior full-stack developer with domain experience in, for example, fintech, e-commerce or manufacturing sits considerably higher.
• Agency versus freelance. With an agency you pay for account management, project management, quality assurance and continuity. A freelancer is usually cheaper per hour, but the risk profile is different.
• Location and currency. Dutch agencies sit in a different price bracket from offshore teams in Eastern Europe or Asia. Both have their place; for projects where close collaboration, language and domain knowledge are crucial, Dutch availability carries real weight.
• Responsibility within the contract. Someone who only delivers code is cheaper than an agency that takes on delivery guarantees, security responsibility and timelines.
• Stack and scarcity. Scarce skills (think experienced Astro developers, DevOps engineers with Kubernetes experience, or specialist ERP integration developers) command higher rates than general frontend work.

So the question "what does an hour of web developer cost?" is less relevant than "what do I get delivered for that hour?". A cheap hourly rate that ends up requiring three times as many hours costs more than a higher rate with an efficient specialist.

Can we start small and expand later?

The short answer is yes, provided you set up the architecture for growth from day one. Many clients choose to build in phases: first an MVP with the core functionality live, then build out based on what users and the market show.

That works well under two conditions. First, the initial version must be technically set up so that expanding it doesn't mean rebuilding everything. That calls for a considered stack, a clean component library and a CMS that can grow with you. Second, the first version must deliver enough value that it doesn't feel half-finished; an MVP is not the same as an unfinished site.

The alternative, planning everything perfectly in advance and only going live once everything is finished, takes more time and budget, and keeps you guessing about what users want for longer. For most organisations we see a phased approach working well, especially on larger projects. You can read how we put this into practice on our page on web development and in the broader piece on custom software costs.

Frequently asked questions about website costs

What determines the price of a website most?

The combination of functionality and integrations weighs most heavily. A static site with ten pages and no integrations is fundamentally different to estimate from a platform with user accounts, payment flows and integrations with an ERP or CRM. Design and content volume are the second major factor. A corporate redesign with photography and editorial work costs considerably more than reusing existing brand material.

Is WordPress cheaper than custom development?

Often, yes, during the build phase. In the long term it is rarely that simple. WordPress is cheaper if your requirements fall within standard capabilities and you accept that ongoing maintenance is needed. Once your requirements go beyond what plugins can realistically deliver, or once performance and security become business-critical, the calculation shifts. We advise you to first look honestly at what the site needs to do, rather than at what is popular.

What is usually INCLUDED and NOT INCLUDED in a website quote?

Typically included: design, development, basic SEO, a CMS environment, a set of pages or templates, and go-live support. Typically NOT included: content creation (text and imagery), hosting beyond the first few months, ongoing maintenance, advanced SEO projects, multi-language translation work, and marketing integrations that require specific configuration work. Read every quote against these items, as this is where most confusion arises later.

How long does it take to have a website built?

That depends on scope and complexity. A brochure site can be live within a few weeks if design and content are ready quickly. A serious online shop or corporate redesign runs over a few sprints. A complex platform is a project of several sprints with several people. We work in sprints so you can see what is being built along the way and steer it; nobody has to wait for a big-bang delivery after a long silence.

Can we start small and scale up later?

Yes, and we often recommend it. The crucial point is that the architecture should be ready for expansion from the start, otherwise you'll be rebuilding after a year. We regularly help clients launch a first version with the core functionality, then expand in phases based on user feedback and business priorities. A similar approach works for app projects, which you can read more about in how much does it cost to build an app.

How can we avoid hidden costs?

For every quote, ask explicitly about annual hosting costs, the maintenance regime, what happens with additional work, and who is responsible for updates and security patches. Also ask whether content creation is included. Hidden costs almost always arise from items that were never explicitly discussed, not from bad intent, but from assumptions that were never stated out loud.