How to Scope a Website Build

Most website projects that go badly went wrong before anyone wrote code. The build itself is rarely the hard part — the hard part is that nobody agreed what was being built, who owned it afterwards, or what happens when the requirements turn out to be different from the brief. Here is what to settle first.

Start With What the Site Has to Do, Not How It Should Look

A brief that opens with visual references skips the only question that decides cost: what does this site actually have to do? Publish weekly? Take payments? Hold customer accounts? Sync with an inventory system? Each of those changes the answer, and none of them is visible in a design reference.

The useful exercise is to list every task someone needs to complete on the site, including the internal ones — an editor publishing a post, a salesperson checking an inquiry. That list is the requirements document, and it is far more useful than a mood board.

The Content Model Decides Whether You Need a Developer Later

This is the part that gets skipped most often and costs the most afterwards. The content model is how your pages and fields are structured behind the scenes — whether "service page" is a real type with defined fields, or just a blank editor someone pastes into.

Get it right and your team publishes without help. Get it wrong and every routine change becomes a support ticket. If you are commissioning CMS development, ask to see the field structure before the design, not after.

Choose the Platform for the Next Three Years

The most common platform mistake is choosing for the launch rather than for the maintenance. A stack nobody on your team can hire for is a liability however good it is technically.

WordPress development suits content-led businesses that publish regularly and want editors working independently. Shopify suits product-led ecommerce where hosting, security and checkout being handled is worth the platform constraints. A custom build suits applications, unusual business logic, or deep integration with systems you already run. Anyone who recommends the same platform for all three is selling what they like building.

Name the Integrations Early

CRMs, payment providers, shipping calculators, ERP systems, email platforms. Every one of these is a place the project can stall, usually because a third-party API behaves differently from its documentation or because nobody has the credentials.

List them in the brief with a named owner for each. If the work is mostly connecting systems rather than building screens, what you actually need is API development, which is scoped and priced differently.

Agree What Performance Means Before You Need It

Performance is cheap to design in and expensive to retrofit. Set a page-weight ceiling and a Core Web Vitals target in the brief, and check them as work lands rather than at the end. Rendering approach matters here too: a site built as a client-side application can look fine to a visitor and be close to invisible to a crawler, and fixing that later means rebuilding the front end.

That overlap is why technical SEO belongs in a build conversation rather than after one.

Settle Ownership in Writing

Four things to have in the contract: who owns the code, who holds the repository, who controls the hosting and domain, and what you receive at handover. "You own it" should mean repository access, source files, deployment steps and documentation — not a zip file and a login.

This is the single question that most reliably separates a serious web development company from a reseller, and it costs nothing to ask.

Budget for After Launch

Dependencies need updating, security patches need applying, integrations change their APIs, and content grows in ways the original build did not anticipate. A quote that covers only the build is quoting half the project.

Ask what ongoing maintenance costs before you sign, not after the first thing breaks. If the answer is vague, that is the answer.

What a Real Quote Looks Like

A quote worth trusting names its deliverables, its assumptions and its exclusions. It says what happens if the scope changes. It gives you a staging environment to review work as it lands rather than one reveal at the end.

If you want that conversation for a specific project, tell us what the site has to do — or see how engagements are structured on our pricing page.