Two competent website providers can quote very different prices for what looks, at first glance, like the same job.
There is no single useful market price for a small-business website because the category covers very different kinds of work. A simple DIY or template-led site and a site that is professionally planned, written, migrated, integrated, and launched may both be called a small-business website, yet the prices can end up very far apart because the work and responsibility are not the same.
Both proposals may say “five-page website.” One may assume you are supplying final copy, an approved page structure, photos, and a straightforward technical setup. The provider’s job is mainly to implement those inputs well.
The other may include figuring out what the site should say, how the pages should be organized, what needs to move from the old site, how existing search traffic should be protected, how forms should route, what should be tracked, and what has to be checked before launch.
Those are not two prices for the same five pages. They are different jobs hiding under the same label.
That is the useful way to think about website cost: not as a universal price per page, but as the amount of responsibility the provider is taking on.
Start with what the provider is actually responsible for#
Before comparing totals, compare assumptions.
A proposal can stay short and still make these responsibilities clear:
| Part of the project | A lighter implementation may assume | A broader project may include |
|---|---|---|
| Content | Final copy, proof, and images are supplied | Positioning, messaging, copy, proof selection, and content development |
| Page structure | The page list and hierarchy are already decided | The provider determines what pages are needed and how they fit together |
| Design | An established template or design system is adapted | More page-specific design decisions or custom patterns are developed |
| Existing website | Little content needs to move | Content migration, redirect planning, search preservation, and cleanup are required |
| Technical work | Basic forms and standard platform behavior | Booking, payments, customer relationship management (CRM) connections, tracking, unusual content-management needs, or other integrations |
| Launch | The finished site is published | Launch testing, domain configuration, analytics continuity, vendor coordination, and post-launch support |
Neither side of that table is automatically better.
If a business already has strong copy, a clear page plan, good photos, and simple technical requirements, paying someone mainly for implementation can be entirely sensible. If those inputs do not exist, the project needs someone to create or coordinate them before the finished site can be good.
The mistake is comparing the two as though the provider is only charging for the visible pages.
Content responsibility can change the job substantially#
“Website copy included” can describe anything from light editing to developing the business’s positioning from scratch.
If you already know the offer, audience, proof, page structure, and key messages, a provider can work from solid inputs. If those questions are unresolved, someone has to decide what the homepage should lead with, how services should be separated, which claims need proof, what belongs on each page, and how the business should sound.
That work happens before a polished page can be built.
The same is true for images, case material, testimonials, service details, pricing language, and other source material. A project where the client supplies organized, approved inputs is different from one where the provider has to find gaps, chase missing material, edit weak inputs, or help create them.
When comparing quotes, ask who owns that work rather than assuming “copy” or “content” means the same thing in both proposals.
Design responsibility is not just “custom” versus “template”#
A strong website can be built by adapting an established system. A weak website can be custom-designed from a blank canvas.
Custom does not automatically mean better.
What matters is how many design decisions the project actually requires. A provider working from a mature component system may already have reliable patterns for service pages, proof, forms, mobile layouts, calls to action, and common content structures. That can reduce design time without reducing quality.
Another project may genuinely need more page-specific decisions because the content, brand, interaction, or information is unusual.
The useful question is not, “Is this custom?” It is, “How much design thinking is actually included, and does this project need it?”
Technical complexity often hides behind a simple-looking page#
Two pages can look equally simple in a screenshot and require very different implementation work.
A contact page with one basic form is not the same job as a page that needs to send leads into a CRM, assign them correctly, trigger an acknowledgement, record advertising conversions, preserve source information, and behave reliably across several systems.
The same goes for:
- booking tools;
- payment flows;
- customer portals;
- calculators or other custom interactions;
- analytics and advertising tracking;
- email or CRM integrations;
- unusual content-management requirements;
- membership or gated content;
- third-party systems with awkward limitations.
None of those features automatically makes a website better. They simply create more implementation and more ways for the project to fail if the connections are not handled carefully.
An existing website can make the project harder, not easier#
A rebuild is not always a blank-slate design project.
The current site may have pages that already receive search traffic, old URLs that need redirects, analytics that should continue working, forms connected to other systems, content that has to be migrated, a domain controlled by another vendor, or years of technical decisions nobody fully remembers.
Those details can add work even if the new site has fewer pages than the old one.
They can also raise the stakes. Replacing a small brochure site that gets little traffic is different from replacing a site that already generates inquiries or ranks for important searches.
If you are still deciding whether the existing site needs replacement at all, use the rebuild-versus-fix guide first. Project size should follow the actual problem.
Project complexity is real work too#
Some price differences come from the website itself. Others come from how the project has to be run.
A project with one owner who can approve decisions quickly is different from a project with several decision-makers, multiple revision rounds, outside photographers or writers, legal review, hard launch dates, or requirements that keep changing as the work progresses.
Coordination takes time. Uncertainty creates risk. Tight deadlines can require a provider to reserve capacity or compress work that would normally happen in sequence.
That does not mean every meeting should become a mysterious line item. It means the way the project has to be managed is part of the job, especially when the provider is expected to keep the whole project moving.
Page count matters, but it is a weak universal pricing measure#
More pages usually create more work. That part is not controversial.
The problem is treating every page as the same unit.
Ten location pages built from one established structure may require less original thinking than four pages that each have a different audience, message, proof burden, and action.
Likewise:
- a page built from supplied copy is different from a page whose copy has to be developed;
- a new page is different from an old page that has to be migrated and redirected carefully;
- a simple informational page is different from a page with custom functionality;
- several pages using one proven layout can be more efficient than a smaller set of pages that each need a distinct solution.
Page count belongs in the estimate. It just should not be mistaken for a universal price-per-page formula.
Even identical scopes can be priced differently#
Responsibility explains a lot of price variation, but not all of it.
Two competent providers can look at essentially the same job and still charge different amounts.
Legitimate reasons include experience, specialization, demand, efficiency, operating costs, geography, business model, and whether the work is being done by one person or a team.
Risk matters too. A provider who agrees to own a difficult migration, coordinate several vendors, or fix problems discovered during launch may charge more to account for what could go wrong than someone whose responsibility ends earlier.
Efficiency can move the other direction. An experienced specialist with strong systems may complete certain work faster because they have solved the same kind of problem many times.
So a higher price does not automatically mean more work, and a lower price does not automatically mean less competence. Price by itself does not prove quality.
Pricing models are not quality signals either#
Website professionals use many legitimate pricing models:
- fixed prices;
- starting prices;
- quoted project prices;
- hourly billing;
- day rates;
- retainers;
- predefined packages;
- hybrids of several models.
The pricing method should fit how predictable the work is.
A tightly bounded project can support a fixed price. A variable build may need a project quote after the provider understands the job. Ongoing or uncertain work may make hourly billing, a day rate, or a retainer more practical.
The useful comparison is not which pricing label sounds most professional. It is whether you understand what will be done, what can change the price, and what happens when the work changes.
How I handle pricing at ZacWine.com#
I publish current pricing rather than making every buyer ask for it.
Where the work is tightly bounded, I can publish an exact price. Where there is a reliable minimum, I can publish a starting point. Larger variable projects such as website builds may need an actual project quote after I understand the work.
For variable projects, we agree on the project price before I start. Hourly work can still make sense in special cases, but it is not the public or default pricing model.
The Pricing page is the source for current ZacWine.com pricing.
Compare two quotes by assumptions and exclusions#
When two website quotes are far apart, compare the assumptions and exclusions before comparing the totals.
Ask each provider:
- Who is responsible for the copy? Are you supplying finished copy, is the provider editing it, or are they developing the messaging and writing?
- Who determines the site and page structure? Is the page map already decided, or is that part of the work?
- How custom is the implementation? Is the provider adapting a proven system, creating new page-specific patterns, or doing some mix of both?
- What happens to the existing website? Who handles migration, redirects, old URLs, analytics continuity, and anything that should not disappear at launch?
- What technical work is included? Forms, booking, CRM connections, payments, tracking, and third-party tools should be named where they matter.
- What is explicitly excluded? Photography, copy, hosting, plugins, paid software, ongoing edits, accessibility work, or outside-vendor work may sit outside the quote.
- What happens at launch and afterward? Ask who handles testing, publishing, domain changes, handoff, bug fixes, training, and post-launch support.
If one proposal includes work the other expects you to provide, the totals are not directly comparable yet.
That is often where the apparent pricing mystery disappears.
Spend for the job you actually have#
A lighter, lower-cost implementation can be entirely appropriate when the offer is simple, the content is ready, and the technical needs are straightforward. If the owner can supply good inputs and the site carries little existing traffic or technical risk, extra strategy and coordination may solve problems the business does not have.
Paying more can make sense when the provider has to figure out more of the site, protect valuable existing traffic, handle a migration or integrations, or keep a more complex launch from going wrong. The question is not whether one option looks more premium. It is how much of the job you need the provider to own, and what happens if important details are missed.
Price is not a proxy for seriousness, quality, or prestige. Match the project to the business and the stakes.
When you compare website proposals, “How many pages do I get?” is a reasonable question. It is just not the question that explains most large price differences.
The more useful question is: What is this person taking responsibility for?
Once that is clear, the totals become much easier to compare. And if you want to see how I currently price my own work, the ZacWine.com Pricing page has the current numbers.