The honest short answer is that a Drupal project runs from about $1,000 to well past $200,000, and that range is useless to you on its own. What is useful is knowing which size you are and why, because the thing that moves the number is almost never the thing buyers expect.
These are our real sizes, the same ones published on our pricing page, with an explanation of what actually decides where a project lands.
What does a Drupal website cost? The bands
Indicative sizes, not a price list. Prices are start-from, and where a project lands is settled in discovery — but this is the shape of the work at each scale.
| Size | WeebPal | Typical duration | What it buys |
|---|---|---|---|
| Micro — Basic Informational Website | $1K+ | 2–3 weeks | A credible public presence that one owner can run unaided. |
| Small — Professional Corporate Website | $5K+ | 1–2 months | The point at which content becomes structured rather than hand-placed. |
| Medium — Advanced Digital Experience | $10K+ | 2–4 months | Where the site has to persuade across markets, and every requirement multiplies by language. |
| Large — Complex Content / Transaction Platform | $30K+ | 4–8 months | Where content stops being read and starts being acted on. |
| Extra Large — Secure Portal / Intranet | $50K+ | 6–10 months | Where the audience becomes known, and identity turns into architecture: who you are determines what exists. |
| Enterprise — Integrated Workflow Application | $80K+ | 8–12 months | Where the platform stops supporting a business process and becomes it — so availability is now an operational risk, not an IT preference. |
| Multi-Entity — Enterprise Multisite / Institutional Platform | $100K+ | 10–16 months | Where the governance problem outgrows the technical one: many units, each with its own budget, brand and timetable. |
| Strategic — Mission-critical Digital Ecosystem | $200K+ | 12+ months | Where failure carries consequence beyond the company, so evidence becomes a deliverable: security, accessibility and availability must be demonstrable, not asserted. |
The smaller sizes are fixed price against a fixed scope. From Large upward the price is committed after the architecture is agreed, because that is the first point at which anyone can commit honestly. Maintenance and support is a separate monthly agreement, sized to what you run.
What actually moves the price?
Not the number of pages. Not the design. Five things, in roughly the order they matter.
1. Whether you are starting from a platform or from nothing
This is the single biggest lever and it is usually decided by accident. A booking system, a learning platform or an application portal built from an empty Drupal install spends most of its budget rebuilding things that already exist and already work. Starting from a platform already running in production puts that budget into what is specific to you instead.
It is the difference between the Small size and the Enterprise size for systems that look similar from the outside. Our own platforms are listed under Products; the same logic applies to any well-chosen starting point.
2. How many systems have to agree with each other
One website with its own data is a small build. A website reconciling against an ERP, a CRM, a payment gateway and a warehouse system is mostly integration work, and integration is where estimates live or die.
Each integration carries its own authentication, its own failure modes, its own rate limits and its own release schedule that nobody controls. Two integrations are not twice one integration; they are two integrations plus the question of what happens when they disagree.
3. How many kinds of user there are
"The site has an admin area" is one sentence and can mean anything from a single editor role to fifteen roles with overlapping permissions, approval chains and audit requirements. Roles multiply the testing surface, not just the build. A system with eight roles has to be correct for eight different views of every screen.
4. Whether existing content and data have to come across
A migration is a project in its own right. Old content models rarely map cleanly onto new ones, the data is always messier than the documentation suggests, and the decisions about what to keep are business decisions that take time to get answered. A migration from an end-of-life Drupal version is our Drupal migration practice rather than a line item on a build.
5. How much of the requirement is actually known
Uncertainty has a price. A supplier quoting a fixed price against a vague brief is either padding heavily to cover the unknowns, or intending to renegotiate once you are committed. Both of those cost you money; the first one costs it visibly.
This is why we scope large programmes rather than estimate them, and commit a fixed price only after the architecture exists.
What does not move the price as much as people think
- Page count. Ten page templates used across two hundred pages is a smaller build than twenty templates used once each.
- Visual design ambition. A distinctive design costs design time, which is real but rarely dominant. What costs is design that fights the content model.
- "Drupal versus something else." The platform matters far less than whether the work starts from something already built. A greenfield build is expensive in any technology.
How does the money get paid?
Projects here pay across four milestones, and you see working software before each one.
| Milestone | Share | What has happened |
|---|---|---|
| 0 | 0% | Proof of concept or product demo, on your data |
| 1 | 30% | Project kickoff |
| 2 | 40% | User acceptance testing and approval |
| 3 | 30% | Go-live and handover |
From the Enterprise size upward, work is structured differently: paid discovery, then phase gates (foundation, core delivery, scale and migration), each released against written acceptance criteria, followed by hypercare under a service level agreement. Change control, steering cadence and escalation paths are agreed before kickoff rather than invented during it.
What is a discovery engagement, and why is it paid?
For large programmes, the first engagement is discovery and architecture, priced against its own scope and credited against the delivery contract on award. It produces the solution architecture, an integration map, a working prototype of the highest-risk workflows, a delivery plan broken into phases with acceptance gates, a risk register with mitigations, and a costed estimate with stated confidence bands.
It is paid for two reasons. Work that is given away is work that is done cheaply, and an architecture done cheaply is the most expensive thing on a project. And because it is paid, the output is yours to keep (architecture, prototype and plan, handed over with full source code), whether or not you continue with us. It is credited against the delivery contract on award.
Smaller engagements keep the free proof of concept: for product-based work we build a working demo on your data before you commit.
What is included in the price that is sometimes charged separately elsewhere?
Three things worth checking line by line when comparing quotes.
- The source code. Every engagement ships with the full repository (application code, custom modules, theme, build tooling, deployment configuration) from day one, with no licence fee on your own platform. Why we contract that way.
- The warranty. One year as standard, extendable up to three by agreement, included in the project price rather than billed separately. What it covers and what it excludes.
- Documentation and training. Written for a developer who has never met us, because that is the only version of documentation that is worth anything later.
What is genuinely separate is ongoing maintenance, which is a different thing from a warranty and is priced monthly: support and maintenance.
So what should you budget?
If you can answer these four questions, you can place yourself on the ladder without speaking to anyone.
- Is there an existing platform that already does most of this, or is this genuinely new? (Platform: Small to Large. New: Enterprise and above.)
- How many other systems must it exchange data with? (Zero to one: the lower end of your size. Three or more: the upper end, or the next size up.)
- How many distinct kinds of user, with different permissions? (Two or three: fine. Eight or more: this is an application, not a website.)
- Does existing content or data have to come across? (If yes, treat the migration as its own project.)
If your answers put you somewhere you did not expect, that is worth knowing before you write a brief. The full pricing page sets out every size step by step, with the milestone structure, and you can describe what you are planning and get an honest read on where it lands.