What to charge for building a website in the UK

The number your client has already seen

This page is about the UK market, so the market figures on it are in pounds. A search for what a website costs in the UK, run in August 2026, returned nine agency or studio pages in the top ten results. The prices quoted on those pages ran from £1,500 to £5,000. That is a range rather than a going rate, and it is the range your client read on Sunday night before they emailed you at five on Monday.

So the short answer: you can charge from a few hundred pounds for a single page you write in an afternoon, and a typical five-page brief with words, revisions and a handover in it sits inside that same £1,500 to £5,000 band the client is already comparing you against. Nobody has measured what UK freelancers actually charge in a way worth quoting, so this page will not hand you an average and pretend it is data. It will show you how to build the number from your own floor instead.

Before the price, the thing being priced. What comes out of a build here is a standard React and Vite project. You can download the whole project as a zip, or push it to your own GitHub or Vercel account, and that export sits on the free tier rather than behind a paid plan. The artefact at the end of the job is ordinary source code another developer can open, which is the fact the rest of this page rests on.

Your side of the arithmetic is the plan, and it is priced in US dollars rather than pounds. Paid plans start at $20 a month for Trade. Studio is $299 a month and Agency starts at $399, both written for people who build sites for other people. Set against one £1,500 job, that is still a small share of the job, and it gets smaller across a year of them.

The last column of the table is the honest one. What you get through in a month is decided by which model the turn runs on, how many pages the site has, and how many rounds of changes the client asks for — not by the name on the plan.

Note. Decide the handover before you quote rather than after. The deliverable is code the client can hold — a zip, or a repository in an account with their name on it — and a quote that does not say so is a quote about your hours.

Three shapes a price comes in, and how each one fails

Almost every quote for client web work is one of three shapes, or two of them stapled together. They fail in different places, and knowing where yours fails is most of the job of writing it.

A fixed price is the right default for a defined site. It is also the one an AI build breaks fastest, and for an unobvious reason: changes become cheap to make, so they become easy to agree to. The client asks for the contact form to move up, then for a fourth service page, then for the whole thing in a different tone. Each one costs you four minutes, so you say yes. Eleven yeses later you have worked a fortnight for a five-page fee, and the tool did not cause it — your ceiling being unwritten did.

A day rate is the shape that genuinely stops working. If a five-page site takes an afternoon, you cannot bill three days for it without lying about the hours, and if you bill the afternoon honestly you have just priced your judgement at zero. Day rates suit open-ended work: a client with a backlog, a retained afternoon a week, a month of changes nobody can scope. They are the wrong instrument for a fixed deliverable, and they were the wrong instrument before any of this.

A monthly care plan is the most valuable of the three and the easiest to turn into something shabby. Done properly it sells the thing the client actually worries about — that the site will drift out of date and there will be nobody to ring. Done badly it is financing for a build the client never owns, at £150 a month for three years, and that is precisely the deal buyers are warned to walk away from. If you would not explain the total to the client out loud, do not offer it.

Note. Whichever shape you pick, write the revision ceiling into the quote as a number. Not "reasonable amendments" — a number, and a price for the round after it.

Build the quote from your floor upwards

Your floor is not the build. The build is the cheapest part of the job now, and it will keep getting cheaper. Your floor is the hours that did not go anywhere: the call where you work out what the business actually sells, the afternoon spent writing words that sound like a bookkeeper rather than like a category, the two rounds of changes, the handover, and the hour in three weeks when they ring about something small.

Price those honestly and the tooling stays predictable. A month of Studio at $299 spread over three jobs is roughly one hundred US dollars a job before conversion. The client's domain is £8 to £15 a year and should be bought on their card, in their name, at a registrar they can log into — that one is not your cost and should never sit on your invoice as though it were.

One wrinkle worth knowing before you write a fixed price. Billing here is metered: a hold is taken before a turn and the difference refunded after, so what a job costs you is not a fixed figure until the job is finished. A site with a lot of pages and a client who wants four rounds costs you more than a three-page job with none. That is an argument for pricing the job rather than the turn, and for having a rough idea of your own consumption on two or three jobs before you quote a fourth at a flat rate.

Then set the number by test rather than by theory. Quote your next three jobs at figures that feel slightly uncomfortable to type, and watch which ones are accepted without a pause. A price accepted instantly was too low. That is worth more than any survey figure, because it is measured on your clients, in your town, for the work you actually do.

• The brief. An hour on the phone, and the hour after it deciding what the site should not say.
• The words. The slowest part of every one of these jobs, and the part clients cannot do for themselves.
• Photographs, or the conversation where you tell them their existing ones are unusable.
• Revision rounds, which are cheap in effort and expensive in calendar time.
• Handover: the files, the domain, the contact form going to an address someone reads.
• The aftercare month. Something always surfaces in the first four weeks.

Note. Top-up credits sit in a second bucket that never expires and are spent after the monthly allowance, so a month that ran long does not reset your floor for the next one.

You were never selling build hours

Here is the argument this page exists for. Using an AI builder on paid client work is a delivery choice rather than an admission, because the client ends up owning downloadable code either way.

Whether the components were typed by hand over three days or generated in two minutes, what lands at the end is the same class of artefact: a React and Vite project, downloadable as a zip or pushed to a repository in the client's own account. Nothing the client owns is worse for how it was made. If your deliverable is as good and it arrives sooner, the honest word for that is delivery, not compromise.

What the client is buying, and always was, is the list that has nothing to do with typing. Someone who worked out that the money in the business is in commercial contracts rather than one-off jobs, and built the site around that. Words that a customer recognises. The judgement to say the photo gallery matters less than a page about how to get a quote. The aftercare. And a person to ring in March when the price list changes and the site still says the old number.

There is a version of this where the price should fall, and it is worth naming so the rest is believable. If the only thing you sold was the labour of assembling a template, then yes, that labour is worth less this year than it was last year, and a client who works that out is not being unreasonable. Most freelancers were never selling that. They priced as though they were, because hours are easy to explain and judgement is not, and the tooling has taken that hiding place away.

On disclosure: you do not itemise which editor you typed in, and you do not owe anyone a tools list. What you owe is honesty about whatever you are actually billing. Sell a deliverable at a fixed price and the hours are yours to manage. Sell days and the days had better have happened.

Note. The test for whether you can defend the fee: if the client asked what they got for it, could you answer without mentioning how long it took? If not, the problem is the brief you took, not the tool you used.

When to quote for the hand build and stop reading

Some of these jobs should not be done this way, and taking them anyway is how a good delivery choice turns into an apology six weeks later.

If the client needs a content system their staff will edit weekly, an integration with the booking or stock software they already run, or a design their brand team signs off page by page, quote for the hand build and stop reading here. Those are real requirements and they are not what this is for.

There is a softer version of the same call. If the client has an in-house marketing person who will want to move a section on a Thursday afternoon, you are not selling them a site, you are selling them a workflow, and the workflow is the thing to scope. Say so at the quoting stage. A job declined in an email on Monday costs nothing. The same job declined in week five costs a relationship.

• Staff editing content weekly without you in the loop.
• A real-time tie-in to the diary, stock or payment system they already pay for.
• Page-by-page brand sign-off, or a design system you must implement to the pixel.
• Anything where a specific accessibility or procurement standard has to be evidenced.
• A client who wants to see the hours, because they are buying reassurance rather than a site.

What you can put in writing, and what you cannot

A quote is a set of promises, and the ones people get sued over are the vague ones. Promise the countable things: the number of pages, the number of revision rounds, a response time for changes after handover, where the files end up, and who holds the domain.

Do not promise a ranking or a number of leads, however the client fishes for it. Nobody can deliver either, no builder or agency has ever been able to, and the moment it is in an email it is the thing you get measured against in month three. If they want a number attached to marketing, that is a separate conversation about a budget you would be spending on their behalf.

Build in front of the client if you can stand it, because it is a genuinely good sales moment, and it is survivable for a specific reason: every build turn is snapshotted before it runs, and reverting is itself revertible. A turn that goes somewhere strange with a client watching is a thing you undo rather than a thing you apologise for.

Two billing details worth knowing before you promise a fixed fee. A turn that produced nothing is refunded in full, and the app says so on the turn. Do not read that as retries being free — they are not, and a turn that produced something is charged whether or not you liked what it produced. And when a turn reports no usage at all, the hold stands rather than being refunded on a guess.

• Promise: page count, revision rounds, response time, the handover artefact, who owns what.
• Promise: a contact form that reaches an address someone actually reads, and that you tested it.
• Do not promise: a position on Google, a volume of leads, or a date you do not control.
• Do not promise: unlimited changes. Say a number, then a price for the round after.
• Put in writing what happens if they leave, and what happens if you do.

The quote you send on Monday morning

One page, five lines, no adjectives. Discovery and brief. Words and structure. Build, stated as a deliverable rather than a duration. Two rounds of changes, with the third priced. Handover, naming the zip or the repository and the account it lands in.

Put the total at the top and the assumptions at the bottom — how many pages, who supplies photographs, what happens if the content does not arrive by the date. Most fixed-price jobs go wrong on content the client promised and did not send, so give that its own line and a consequence.

Then do the thing that closes these jobs, which is to stop describing and start showing. Describe the client site you owe this month — the business, the pages, the contact form — and have the first version in front of you before the follow-up call. A quote read beside a working site is a different conversation from a quote read on its own.

Note. Send the quote and the first build within twenty-four hours of the brief call. Nothing you write about your process will beat the client seeing their own business on a screen while the email is still near the top of their inbox.

Common questions

Will the client be able to tell the site was built by AI?

Not from the layout, and not from the code, which is an ordinary React and Vite project any developer can read. What gives a site away is generic wording and stock photography, and both of those are your decisions rather than the tool's. Put their words and their photographs on it and the question stops arising.

What do I actually hand over at the end of the job?

The project itself. You can download the whole thing as a zip, or push it to a GitHub or Vercel account, and it is worth pushing to an account in the client's name so ownership is settled on the day rather than argued about later. Hand over the domain login too, and confirm in writing that the contact form goes to an address they read.

What happens to the client's site if I stop paying for the plan?

This is exactly why the handover matters and why it should happen at the end of the job rather than whenever someone asks. Files the client already holds, in their own zip or their own repository, do not depend on your subscription. What lapsing a plan costs you is the ability to keep running build turns on that month's allowance, which is your problem rather than theirs.

Can I charge three thousand pounds for something a tool built in two minutes?

You can charge for what you delivered, which is a brief, a set of decisions about what the business sells, words a customer recognises, revisions and someone to ring in March. If the answer to what the client got is only the two minutes, the fee is wrong. If it is that list, the two minutes is not the client's business any more than which editor you type in is.

What if the client wants changes in two years and I have moved on?

They hold the source code, so any competent developer can pick it up, which is more than can be said for a proprietary builder. Say this in the quote rather than saving it for the awkward call. It is one of the strongest lines you have, and it costs you nothing to give away.

Does the client need their own account?

Not to receive the work. A zip needs nothing from them at all. A push lands in whichever GitHub or Vercel account is connected, so use theirs when you want the repository in their name from day one. They would need an account of their own only if you want them making changes without you, which is a decision to make deliberately rather than by accident.