How Much Does a Website Cost, and How Long Does It Take?

There are three questions that come up in almost every first conversation I have. What will it cost? How long will it take? What do you build it with?

They're fair questions, and they're usually asked slightly apologetically, as if it's rude to ask about money before we've talked about the creative work. It isn't. You're trying to work out whether this is worth your time, and you can't do that without numbers.

The trouble is that the honest answer to all three is "it depends", which is useless when you're trying to plan a budget or take something to whoever signs it off. So this is my attempt at a proper answer. Real ranges, realistic timelines, and a straight description of how I actually work.

The honest bit about pricing first

Nobody can give you an accurate price for a website in a first email. Anyone who does is either guessing, or they've already decided what they're going to build regardless of what you need. Both should worry you.

What I can give you is a range, and more usefully, an explanation of what moves you up and down inside it.

Two things to keep in mind. These are my numbers as a freelance web designer working out of London, so an agency will quote higher and a marketplace freelancer will quote a lot lower. And the gap between the bottom and the top of a range is scope, not margin. Something real is different between a £3,000 project and a £9,000 one.

What a website actually costs

Most of the projects I take on land somewhere between £3,000 and £9,000. Here's roughly what sits at each point.

£3,000 to £6,000

A well-designed, well-built site of around five to ten pages. Proper discovery, a design phase in Figma, a fast and accessible build, a simple CMS, and a clean launch.

This assumes you know broadly what you want and your content is either ready or close to it. It's the right budget for a business that needs its website to look credible, load quickly, and explain clearly what it does.

What you won't get at this level is a full design system, complex functionality, or a lot of room to change direction halfway through.

£6,000 to £9,000

More thinking and more surface area. Fifteen to twenty-five pages, a design system rather than a set of individual page designs, a CMS structured around how your team actually works, some custom functionality, and genuine room to iterate before anything is locked down.

This is where a project stops being "we need a website" and starts being "we need this website to do a specific job." More time goes into strategy, structure, and the details that make a site feel considered rather than assembled.

Above £9,000

You're usually into e-commerce, integrations with systems you already run, membership or gated areas, multiple languages, or genuinely complex content models. At this level the price is driven by functionality rather than page count.

Below £3,000

It's still possible to build something good, but something has to give. Usually it's the discovery phase, which is exactly the part you shouldn't cut. If your budget is genuinely under this, I'd rather tell you honestly than take the work and quietly deliver less than you were hoping for.

I've written more detail on this in what a £5,000 to £15,000 website project should include if you want the full breakdown.

What actually moves the price

If you want to understand a quote rather than just accept it, these are the levers.

Page count, but less than you'd think. Ten pages that are variations of the same template cost far less than five pages that each do something different. Ask about templates, not pages.

How much thinking is needed. If you arrive knowing your audience, your message, and your structure, you're buying design and build. If we have to work all that out together, you're buying strategy too, and that's real time.

Custom functionality. Booking systems, calculators, filtered listings, payment flows, integrations with a CRM or a booking tool you already use. Each of these is its own small project.

Content readiness. Not a line item, but it affects everything. Projects where the copy was ready have consistently come in faster and cheaper than ones where we were still writing during the build.

Migration. Moving from an existing site means auditing what's there, mapping redirects, and preserving whatever search visibility you've built up. It's not glamorous and it does take time.

How many people need to approve things. One decision maker is quick. A committee is not. That's not a criticism, it's just something worth pricing in honestly.

What's usually not included

Being straight about this early saves a difficult conversation in month three.

• Copywriting. Writing for the web is its own skill. Most projects assume you're providing the words, or that copy is scoped separately.
• Photography and video. Stock images can fill gaps, but anything custom needs its own budget.
• Ongoing marketing. A new website doesn't bring traffic on its own. SEO content, ads, and social are separate disciplines.
• Brand identity. If you need a logo and a full visual identity as well as a website, that's a separate piece of work. I do offer branding, it just isn't folded into a web design quote by default.

A designer worth working with will flag any of these at proposal stage rather than let you discover them later.

How long it takes

Most projects run eight to twelve weeks from signed proposal to going live. Here's how that breaks down.

Discovery and brief: around 1 week

We start with a conversation, not a twelve-page questionnaire. I want to understand your goals, your audience, what success actually looks like, and what's happened with your website so far.

From that I put together a proposal covering scope, timeline, and cost. No guesswork on either side before anything is signed.

Design: 4 to 6 weeks

I start with structure, essentially wireframes, before any visual design happens. It's much easier to have a useful argument about what belongs on a page when nothing is pretty yet.

Then comes the visual work: typography, colour, layout, interaction. You get two rounds of feedback built in as standard. I don't disappear for a month and come back with a surprise.

Build: 2 to 4 weeks

Designs get turned into a real website. Clean HTML, performant CSS, minimal JavaScript. Any CMS setup, third-party integrations, or bespoke functionality happens here.

Performance and accessibility aren't a final polish, they're part of how the thing gets built.

Launch and handover: around 1 week

Testing across devices, browsers, and slow connections. Accessibility checks. Redirects mapped from your old URLs. Analytics in place from day one. Then we launch on your schedule, not mine.

You get documentation, a walkthrough of anything you'll manage yourself, and 30 days of post-launch support as standard.

You can see this laid out in more detail on my process page.

What actually decides your timeline

Here's the part most timelines leave out. The eight to twelve weeks assumes things come back from your side at a reasonable pace. The three things that stretch a project are almost always the same.

Content. By a distance the biggest one. Every page needs words, and the words need signing off. If copy is still being written during the build phase, the build phase gets longer. There's no clever way around it.

Feedback speed. A round of design feedback that takes a week to come back adds a week. Two rounds, two weeks. It adds up faster than people expect.

Approvals. If a page needs sign-off from three people who are rarely in the same room, build that reality into the plan rather than hoping.

None of this is a complaint. It's just that the honest version of a timeline includes the client's side of it, and most quotes only show mine.

If you have a fixed deadline, say so at the very start rather than at the end. Some deadlines are workable if we phase things differently. Some aren't, and I'd rather tell you upfront than let you find out in week nine.

The systems I use

People often expect a longer list than they get. I've deliberately kept my stack small, because a small stack is one I can genuinely know inside out.

Design: Figma

Every project runs through Figma, and you have access to the file throughout. No working in secret for a month and hoping you like the reveal.

Reviewing and refining at the design stage is quick. Making the same changes halfway through a build is not, which is why I don't skip ahead to code.

Build: Eleventy and the Jamstack

I build with Eleventy, a static site generator, alongside hand-written HTML, CSS and JavaScript. No page builders, no off-the-shelf themes, no WordPress.

The reason isn't ideology, it's outcomes. A static site is fast by default, has no database sitting there waiting to be attacked, and doesn't break because a plugin decided to update itself overnight. If you want the detail, I've written about how I approach development.

It also means no lock-in. It's standard code in a Git repository. Any competent developer can pick it up later, including one who isn't me.

Content: a headless CMS

Where you need to edit content yourself, I use a headless CMS, usually Sanity. Headless just means the place you write content is kept separate from the place it gets displayed.

I build the editing interface around your content rather than the other way round. If you're never going to change the footer, you don't get a footer editor. Fewer fields means more people on your team will actually use it.

Hosting and deployment: Netlify and Git

Everything is version controlled in Git and deployed through Netlify. In practice you'll notice a few things:

• Every change gets its own preview link, so you can review before anything goes live.
• Deployments are atomic. If a build fails, the current site stays up and nothing breaks in front of your customers.
• Rolling back is one click.
• Hosting costs are low, often under £20 a month and sometimes nothing at all.

A note on getting the copy right first

If you're working on your messaging before commissioning the design, you're doing this in the right order, and I'd say that even if it delayed a project of mine.

Design that comes before the words is decoration. You end up with a beautiful layout that the real content doesn't fit into, and then someone cuts a perfectly good paragraph to fit a box that was invented before anyone knew what the paragraph would say. I've been on both sides of that and it's a poor use of a budget.

What genuinely helps when the copy work is done:

• A clear sentence on what the business does and who for.
• The rough page list, even if the wording isn't final.
• Your key messages in priority order, so I know what needs to be visible before anyone scrolls.
• Any hard rules on tone or terminology.
• Draft copy for the homepage and one or two key pages. It doesn't need to be signed off, it just needs to be roughly the right length and saying roughly the right thing.

You don't need finished copy for every page before we start. But the sooner I can see how you actually talk about your business, the better the design will fit it.

What I'd need to know to give you a real number

If you want a proper proposal rather than a ballpark, this is the list. Most of it you can answer in ten minutes.

1. What does the business do, and who's the website for?
2. Roughly how many pages, and how different are they from each other?
3. Does the site need to do anything beyond displaying information? Forms, bookings, payments, logins, integrations with tools you already use.
4. Is there an existing site to migrate, and are there URLs worth preserving?
5. Do you have branding already, or does that need doing too?
6. Who's writing the copy, and when will it be ready?
7. Who needs to sign things off?
8. Is there a deadline that genuinely matters, and why?
9. What budget are you working with?

That last one isn't me working out how much I can charge. It's the fastest way for me to tell you honestly whether what you want is achievable, and if it isn't, what I'd suggest instead. A budget shared early gets you a proposal that fits it, rather than three rounds of cutting things back.

If you want a head start, I've put together a sample website brief that covers most of the same ground in more detail.

One last thought

The best projects I've worked on have had one thing in common, and it isn't budget. It's that the client arrived with clear goals rather than a vague sense of wanting a new website.

You don't need to know what technology to use or how any of it gets built. That's my job. But if you can tell me what you're trying to achieve, who you're trying to reach, and what you want someone to do when they land on your site, you'll get a much better result for your money than someone who spends twice as much without ever answering those questions.

If you're at that stage, get in touch or book a call. Bring what you have, even if it's messy. I'd rather talk through a half-formed idea than wait around for a perfect brief.