Key takeaways
- 63% of agencies quote between $1,000 and $15,000. Most of the market sells in a band that cannot deliver what its sales page promises.
- Price is not the variable that matters most. What changes across bands is who can touch the site after launch.
- You can judge quality without reading code: run PageSpeed on the provider's own portfolio, and ask to see the CMS instead of the design.
- The invoice on day one is rarely the cost. Industry survey data puts the real total 100-200% higher once hosting, maintenance and post-launch changes are counted.
- The most expensive outcome is not a bad website. It is a good one your team is afraid to touch.
You need a website. You ask around, and within a week you have five quotes.
A freelancer says $3,000 and four weeks. A local agency says $12,000 and eight weeks. A studio says $40,000 and wants to talk about discovery before quoting anything. Someone's cousin says they can do it in a weekend with AI. A WordPress shop says $6,000 and mentions a plugin you have never heard of.
Every one of them used the word custom. Every one showed a portfolio that looked fine. And you have no way to tell them apart, because the thing that separates them is not visible in a proposal or in a screenshot.
This is a guide to reading those five quotes. What each budget band buys, what breaks later at each level, and the checks you can run yourself without knowing a line of code. Some of it will point you away from a studio like ours. That is deliberate. If you are in the wrong band, we both waste a month finding out.
The market is cheaper than you think, and that is the confusing part
In 2026, GoodFirms surveyed more than 300 web development firms across 31 countries. Fixed-price website projects across that market run from $1,000 to $150,000 and up. But 63% of those firms quote between $1,000 and $15,000.
63%
of agencies quote between $1,000 and $15,000
$1K-$150K+
the full spread of fixed-price website projects
100-200%
how much higher the real cost runs after hosting and maintenance
83%
of surveyed agencies still build on WordPress
Read that again, because it explains most of your confusion. The centre of gravity of this entire market sits below $15,000. When you ask five people for a website, four of them are selling from that band. They are not lying to you and they are not running a scam. They are selling a different product to the one you might think you are buying.
The word doing the damage is "custom." A theme with your colours applied is custom. A design drawn from scratch in Figma and built to a component system is also custom. Both providers will use the word. The gap between them is the difference between custom web development and a template with a new coat of paint — and nothing in a proposal tells you which one you are getting.
What each budget actually buys
Prices are in USD and describe the international market rather than any one country. Rates move sharply with geography: the same survey found hourly rates of $10-15 in South and Southeast Asia against $50-100 in the US, UK and Canada. Adjust the bands to your market, but the pattern of what you get holds everywhere.
Who sells here
DIY builders, AI site generators, and template setup by a generalist. GoodFirms found 33.5% of AI-builder projects come in at $500-$1,500, and another 24% below $500.
What you realistically get
A working site in under two weeks that looks like the template it came from. Fine for validating an idea, a single-page launch, or a business that needs an address on the internet more than it needs a website.
What breaks later
The ceiling arrives fast. Content limits, no real structure, and design that cannot follow your brand as it develops. Nothing here transfers to whatever you build next.
Five bands, four questions
The differences that matter are not in the design. They show up the week after launch.
The $2,000 website that cost a lot more than $2,000
A founder asked us what a new website would cost. We gave him a number. He winced, and then told us he had been lucky: someone had built his current site for about $2,000.
A few months later he came back. Not for a website. He wanted an audit, and he wanted us to write his blog posts, because publishing had become something nobody on his team was willing to do.
Here is what the audit found. Every kind of content on that site lived in one collection. Blog posts, authors, categories, all of it, in a single structure carrying roughly fifty fields, most of them empty on most entries. Adding an author meant creating a blog post and leaving forty fields blank. There was no content model behind it at all, just one box with everything in it. The images had never been through any optimization. The build underneath was the kind that works right up until somebody needs to change something.
He paid about $2,000 and got a site that looked fine. What he actually bought was a structure nobody could publish into.
The part that stayed with us: he still thinks he got lucky. And by the arithmetic he can see, he did. The invoice was small. The cost showed up somewhere he was never going to look for it.
Warning: The build was never the expensive part
GoodFirms puts the real cost of a professionally built website at 100-200% above the first invoice once hosting, maintenance, integrations and post-launch changes are counted. For a badly structured site the multiple is worse, because the bill does not arrive as a bill. It arrives as an audit, a rescue, or a rebuild.
This is the trap in the cheap band. The failure is not visible. The site loads, the pages are there, the design is acceptable. What is missing is structure, and structure is the one thing you cannot see from the outside — until the day you need to publish something and discover you cannot. Then you are paying for a redesign you had not planned, eighteen months earlier than you expected.
Five checks you can run without reading a line of code
The buyer's real problem is not price. It is that quality is invisible to you. You are being asked to judge engineering work using the only evidence you can read, which is how the portfolio looks. Every provider knows this, which is why every portfolio looks good.
These five checks take under an hour and need no technical background. Run them on anyone you are considering, at any price.
The one-hour vetting pass
Do these in order. Most providers fail at step three.
Check 1
Check 1
Run their portfolio through PageSpeed
Not your future site — the sites they have already shipped. Take three links from their work page, run each through PageSpeed Insights, and read the mobile score. A studio that ships slow sites will ship you a slow site. This is the single most honest signal available to you, and almost nobody checks it.
Check 2
Check 2
View the page source
Right-click any page in their portfolio and choose View Page Source. If you can find the headline and body copy in that text, the page is server-rendered and both Google and AI assistants can read it. If you see an empty container and a wall of scripts, they cannot. You do not need to understand the code. You only need to find the words.
Check 3
Check 3
Ask to see the CMS, not the design
Everyone will show you Figma files. Ask instead to see the back end of a site they built, with a real editor logged in, and ask them to add a section to a page while you watch. Watch how long it takes and how many ways there are to get it wrong. This is the room your team will live in for the next three years.
Check 4
Check 4
Ask what a landing page costs in month six
Not the build price. The price of the thing you will need forty times over the next three years. If the answer is a day rate, you are buying a website. If the answer is that your team does it themselves, ask them to prove it using check three.
Check 5
Check 5
Ask who owns what, in writing
The code, the design files, the CMS account, the domain, the hosting. Get the list before you sign, not after. Some of it will be licensed rather than owned, and that is normal — what matters is that nobody is vague about which is which.
Two of these deserve a note. PageSpeed Insights is free and it reports Google's own Core Web Vitals, which feed into search ranking. And the view-source check is about more than speed: server-side rendering is what decides whether ChatGPT, Perplexity and Google's AI answers can read your pages at all. A site that renders entirely in the browser is close to invisible to them.
What to look for in the proposal itself
A proposal tells you how a provider thinks. Most buyers read it for the number at the bottom. Read it instead for what is missing — particularly whether there is a discovery phase before anyone opens a design tool.
Five things that should stop you signing:
No discovery. A proposal that arrives without anyone asking about your content, your team, or who publishes is a proposal for a template with your logo on it. They are quoting a shape, not your business.
Design mockups with no content structure behind them. Beautiful pages that only work with the exact words in the mockup. The first real blog post, the first long product name, the first missing image, and the layout falls apart.
Unlimited revisions. Nobody offers unlimited anything. It means the scope was never defined, and it will get defined later, in an argument, when one of you is already unhappy.
Nothing about life after launch. If the document ends at go-live, you are buying a website rather than a way to run one. Ask what page two looks like: who makes it, how long it takes, what it costs.
A price with no timeline attached. The survey data is clear that basic builds ship in two to four weeks and larger work runs eight to twenty-eight. A quote with no schedule is a guess, and guesses get revised upward.
The inverse is also useful. A good proposal will have a project timeline with named phases, will mention wireframes before visual design, and will say plainly what is not included. Providers who write down what they will not do are usually the ones who finish.
The cost nobody puts in a quote
We built more than thirty sites in our Webflow years. We were proud of them. We wrote the guides. We recorded the walkthroughs. We handed over documentation covering every part of the CMS, and we answered questions after launch.
And a lot of those marketing teams still would not touch the site.
Not because they could not work out how. Because they were afraid of breaking something in front of customers. One wrong paste into a rich text field, one image at the wrong size, one section dropped in the wrong place, and the page looks wrong to everyone visiting it. Weighed against that, sending a message and waiting two days feels like the responsible choice.
That fear is not a line item in anybody's proposal. It never gets quoted, never gets discussed on a sales call, and it decides whether the site you paid for gets used or quietly frozen. We watched it happen often enough that it became the reason we changed how we build.
The fix is not more documentation. We tried more documentation. The fix is a system where the wrong thing is not possible in the first place.
In practice that means fields that only appear when they are relevant, character limits that stop a headline from breaking a layout, validation that names the exact field that is wrong instead of saying something went wrong, and publishing that is blocked rather than merely discouraged when something required is missing. Then draft mode and version history underneath all of it, so anything can be previewed before it goes live and reverted after it does.
None of that is glamorous and none of it shows up in a portfolio screenshot. It is also the difference between a website your team runs and a website your team is scared of.
The name for this is a content operating system, and we have written about what the term means and where it came from separately. For this article the only part that matters is the price implication: it sits in the $15K-50K band, and it exists to remove a cost that nobody quoted you for in the first place.
So which one are you?
The question is not which option is best. It is which one matches how your business actually uses a website. Read these three and be honest about which describes you today, not the version of you that intends to publish weekly starting next month.
Hire a freelancer if:
Your site is small and mostly static, and it changes a few times a year rather than a few times a week.
You need to be live in weeks, and being live matters more right now than being able to grow into it.
Nobody on your team has publishing in their job description. If there is no marketing person, there is no self-serve problem to solve.
You can accept rebuilding in two years and would rather spend the money then than now. This is a legitimate choice, not a mistake.
Hire a boutique agency if:
You need design work that a single freelancer cannot deliver, but your content stays fairly simple.
One or two people will edit the site occasionally, and occasional is the honest word.
You want a team for the build, and you are comfortable with a retainer covering changes afterwards.
Think twice if you are already multi-language, or will be within a year. That is where this band tends to run out of room.
Hire a studio if:
Someone's actual job includes publishing to the website, and their time is worth more than the queue they sit in.
You run campaigns, launches, or landing pages more than a handful of times a year.
You are publishing in more than one language, or you will be.
You have rebuilt once already and you do not want a third version of this conversation in two years.
Info: Be honest about the frequency
If you update your website twice a year, a content operating system is a solution to a problem you do not have. Everything about it pays back through repetition — each page your team ships without asking anyone. Ship rarely, and it never pays back. Spend the money on a good freelancer and put the difference somewhere it earns.
Where we sit, and where we do not
We are a two-person studio with a small circle of senior contractors. We run strategy, design and development as one engagement, and we build on Next.js with Sanity. Every component we ship has guardrails on it, because of the thirty-odd sites we handed over before we worked that way.
One engagement covers four things. We do not split them up, because the handover between them is where most website projects come apart.
What we deliver:
Strategy. Discovery first: who buys from you, what the site has to do, and how your team publishes. The content structure comes out of that, not out of a design file.
Custom design. Wireframes, then visual design, drawn from scratch in Figma around your brand. No theme, no template, no starting point somebody else is already using.
Development. Built on standard technology any developer can pick up, so nothing about the build ties you to us. Fast by default, and readable by search engines and AI assistants.
The content operating system. Your dashboard set up as something your team runs: components with guardrails, validation that blocks a bad publish, one place for images and video, draft previews, and full version history.
The apps. Your dashboard is not a fixed product. Today that means a publishing app — what is live, what is still a draft across the whole site, and bulk publishing when a campaign goes out — and an asset app: one searchable library for images and video, with tags, renaming and bulk actions.
Not sure which band you are in?
Tell us how often your site changes and who changes it, and we will tell you what you should be paying for.
That puts us in the $15K-50K band on this page — studios running strategy, design and development as one engagement, with the content system treated as part of the build rather than an afterthought. We are not the cheapest option and we do not try to be. If your budget or your publishing rhythm puts you somewhere else on this page, we will say so on the first call rather than after a month of proposals. That is not generosity. It saves us both the month.
Read next
Once you know your band, the next question is the technology. Webflow, WordPress, AI builders, or custom: who actually runs your website after launch compares the five ways of building on the thing that matters after go-live.
If the developer queue is the part that stings, what your marketing team should be able to change without a developer draws the ownership line, and the real cost of asking a developer for every change puts numbers on what the waiting costs.