A mid-sized service firm signs off on a twelve-page website package because the proposal reads clean and the price fits the budget line. Six months later the homepage still cannot explain what makes the firm different, the enquiry form collects names with no context on intent, and the marketing lead is asked in a board meeting why the new site is not producing better leads than the old one.
Nobody on the vendor side did anything wrong by the letter of the contract. The pages were built, the count was met, the invoice was paid. The failure sits one level up.
A page count was priced. A business outcome was never defined.
This happens often enough to be a pattern rather than a mistake: buyers compare proposals on deliverable counts and per-page rates because those numbers are easy to put side by side, while the harder questions, about audience journeys, conversion logic, and governance, go unasked until the site is live and underperforming.
Define The Business Outcome Before Pricing Pages
A page-count package treats a website as inventory: so many templates, so many stock sections, a contact form at the end. A properly scoped custom project treats the same site as a set of connected business assets, each one tied to a decision the visitor is meant to make and a piece of internal work the business is meant to save. The distinction matters because the two framings produce different specifications from the same brief, and only one of them can be checked against results after launch.
The dimensions that separate the two are consistent regardless of company size: primary user journeys, conversion paths, the condition of existing content, who governs decisions, what systems the site must integrate with, and where compliance exposure sits. A firm evaluating web design packages should expect a credible proposal to name these dimensions explicitly rather than folding them into a generic “discovery phase” line item.
Outcome-Led Scope Versus Page-Count Scope
Outcome-led scope starts from what a director-level buyer needs to accomplish on the site, then works backward to the pages and components that accomplish it. Page-count scope starts from a template library and works forward, filling slots. Both can result in a site that looks finished at launch. Only the first can be defended when someone asks what the site is supposed to do for the business.
Custom Work Versus Templates, Builders, And Freelancers
Template-based packages, DIY builders, pre-made themes, freelance designers, and agencies each solve a version of this problem, and none of them is disqualified by definition.
- A template can carry a clear brand identity if the content strategy behind it is sound
- A freelancer can deliver strong UX on a tight scope
- An agency can absorb integration or compliance complexity a solo builder cannot
What changes across these options is not quality in the abstract but who owns the scope decisions, how much customization the underlying structure permits, and how integration or compliance needs get absorbed into the build.
Separate The Scope Into Decision Dimensions
Every one of the following items is a place where a proposal can make an assumption on the buyer’s behalf without saying so. Listing them side by side turns invisible agency judgment into a comparison record the buyer controls.
- Audience journeys: who arrives, from where, and what they need to decide
- Messaging and copy needs: whether content is written new, edited, or supplied as-is
- Information architecture: how pages and sections relate to each other
- Responsive design: behavior across device sizes, not just appearance
- Content migration condition: what exists today and its reusable state
- CMS flexibility: how much structure a non-technical editor can change later
- Required integrations: CRM, booking, payment, or marketing tools in scope
- Accessibility expectations: what standard, if any, is targeted
- Privacy expectations: data handling and consent mechanics
- Analytics: what gets measured and who reviews it
- Decision-makers and approval dependencies: who signs off, and when
This is a comparison record, not a discovery worksheet to be filled in later by whichever vendor wins the deal. When a proposal leaves one of these fields blank, that blank is not neutral. It is an assumption the agency has made on the buyer’s behalf, and it is worth naming out loud before signature rather than discovering it at handover.
Specify The Foundational Deliverables In Every Package
Deliverables need plain-language definitions because vague ones are where scope disputes start. “UX design” can mean a wireframe sketch or a tested interaction model, and a buyer who does not pin the term down has no basis for comparing two proposals that both use it. The baseline that separates a working business asset from an expensive brochure is not exotic. It is a short, consistent list, applied the same way regardless of package size.
Strategy And Content
Discovery should produce a written summary of audience journeys and business goals, not a meeting note. Messaging or copy support should state whether copy is written, edited, or supplied by the client, because that single decision changes both timeline and cost basis.
Information architecture should output a sitemap the client actually approves. This is the document where brand identity starts to take shape as page hierarchy: which message leads, which supporting content sits one click away, and which conversion path each section ultimately feeds.
Build And Validation
UX/UI design should produce visual layouts tied to the approved architecture, carrying the same hierarchy into components: buttons, forms, and calls to action that reflect the brand’s priority actions rather than generic template defaults. Development turns those layouts into a working site. Content migration moves existing material across in a defined condition. Responsive and mobile review confirms the experience holds across device sizes rather than merely resizing.
Launch And Ownership
Basic on-page SEO and SEO setup, meaning titles, metadata, and technical foundations, should be distinguished from any ongoing SEO service, which is a different commitment. QA, analytics configuration, and training should each produce a checked, working state the client can verify before launch. Warranty and post-launch support terms belong in writing at this stage, not negotiated after the invoice is settled.
Compare Three Package Levels By Complexity
Package names and price labels are the least useful part of most proposals, because two vendors can call the same scope by different tier names. What moves a project from one level to the next is documented criteria: number of stakeholders, integration count, content volume, and compliance exposure.
A buyer comparing proposals should ask each vendor to state, in writing, what specifically triggers the next tier up, rather than accepting the tier label at face value. The three tiers below track roughly the same logic across the market, though vendors label them differently:
- Foundational (small): fits a single audience with a straightforward offer and limited content volume. Scope covers baseline deliverables only: discovery, IA, UX/UI, development, QA, launch. The buyer’s job is to supply core content and approve architecture on schedule.
- Growth (medium): fits multiple audience segments or documented conversion paths. Scope adds structured content strategy, expanded journeys, and one or two integrations. The buyer’s job expands to clearer messaging input and coordinating integration access.
- Complex (large): fits multiple stakeholders, advanced integrations, and elevated compliance exposure. Scope adds governance workflow, advanced integration testing, and compliance review. The buyer’s job is to manage the internal approval chain and supply legal or technical constraints early.
Industry pricing references illustrate the range rather than fix it. One 2026 website design guide put custom packages between $2,000 and $10,000 or more depending on page count and complexity, while a separate 2026 pricing guide described tiered structures running from a few hundred dollars at the entry level to several thousand at the enterprise end. Neither figure should be read as a quote. Both confirm that tiering by complexity, not by page count alone, is standard practice across the market.
Sequence The Production Workflow Around Approvals
A workable production sequence runs on approvals, not on a calendar alone.
Discovery findings get reviewed and signed off before messaging or information architecture work begins, because building on unapproved assumptions is the single most common source of rework. Messaging and IA approval then unlocks UX/UI direction: the visual and interaction layer, which itself needs sign-off before build starts, since redesigning after development begins costs more than redesigning before it.
Build activity converts approved components and pages into a working site, feeding directly into a validation stage where content accuracy and integration behavior get checked against what was approved earlier, not against a fresh read of the brief. QA and launch preparation close out technical checks: browser behavior, form function, tracking, and security basics. Handover and support follow, with training and documentation delivered against what was actually built.
Every stage above has a defined input, a defined approval point, and a defined output, which is what makes each one independently checkable. None of it runs on a fixed calendar. Timeline commitments depend on how quickly the client supplies content, how fast stakeholders reach decisions, how cleanly feedback gets consolidated into one round rather than five conflicting ones, and how quickly third-party systems grant integration access.
Control The Commercial Terms Before Work Expands
Pricing is the output of scoped effort and risk, not a substitute for stating what that effort and risk actually are. A number with no attached scope document tells a buyer nothing about what happens when a stakeholder asks for a thirteenth page or a new integration mid-project. The terms below are what make a package defensible after signature, not just attractive before it.
- Assumptions: what the vendor is treating as true, in writing
- Exclusions: what is explicitly out of scope
- Client responsibilities: content, access, and decisions the client owes
- Revision limits: how many rounds are included, and at which stage
- Acceptance criteria: what “done” means for each deliverable
- Timeline dependencies: what client-side delay does to the schedule
- Change-control rules: how a new request gets priced and approved
- Handover rights: what the client owns and receives at close
- Warranty boundaries: what is covered, and for how long
- Ongoing-support terms: what happens after the warranty period ends
A revision is a refinement within agreed scope: adjusting spacing, swapping an image, tightening a headline. A changed requirement is new scope: a different page, a new integration, a different audience segment added mid-project. Add-ons should require a documented business reason, stated by the buyer, not appear as line items introduced by the vendor once the project is already underway.
Add Compliance And Support When Exposure Requires It
Integrations, accessibility review, privacy handling, SSL, and post-launch monitoring are often treated as late additions, which is precisely why they cause the most friction near launch.
Germany’s BFSG began applying accessibility obligations to many digital offerings from June 28, 2025. Separately, accessibility requirements for public-sector entities in the United States changed under the DOJ’s Title II rule. Neither development means every private business in every jurisdiction is automatically covered, and neither is a substitute for advice from someone qualified to assess a specific business’s legal exposure.
What both confirm is that accessibility, alongside WCAG, GDPR, and ADA vocabulary, needs to be raised as a scope question at the proposal stage, with inclusion tied to the buyer’s actual sector and audience, not bolted on afterward as a compliance patch.
Send A Scope Request That Produces Comparable Proposals
Comparable answers are the point. When every vendor responds to the same request, the differences that surface are real differences in how each one manages risk, not differences in how each one chose to interpret a vague brief. That comparison is what makes a recommendation defensible to whoever signs the budget.
Send the same request to every vendor under consideration, before any proposal gets scored:
Please scope a custom website around these primary user journeys: [ ]. Existing content condition: [ ]; required integrations: [ ]. Decision-makers and approval timing: [ ]. Please separate fixed deliverables, exclusions, responsibilities, revisions, ownership, accessibility/privacy assumptions, and post-launch support.
About the Author
