Blog
Field guidesMar 3, 20261 min read

How we scope a website project

What's in, what's out, how we price it, and why the brief conversation matters more than anything else in the process.

How we scope a website project

How we scope a website project

Website projects go wrong in predictable ways. The scope expands. The brief was wrong. The content wasn't ready when it needed to be. The decision-maker who approved the wireframes turned out not to have approval authority.

This is how we prevent those problems — or at least how we try to.

The brief conversation

Before any proposal, we have a 45-minute conversation. The agenda is simple: what does the current website fail to do, what does success look like, and who makes the final call on this project?

The third question is the most important. If we can't get a clear answer, we don't propose.

What we include by default

A website engagement includes: information architecture, wireframes, visual design (desktop and mobile), a component library in Figma, copy for all pages (written by us or reviewed by us if the client is supplying it), and a developer handoff with specification notes.

What it doesn't include: development. We design. We don't build. We recommend developers when asked — we have relationships with several independent developers we trust — but the build is a separate engagement.

How we price

We use fixed fees scoped by page count and functional complexity. A five-page marketing site for a B2B SaaS has a different price from a twenty-page site with custom interactive elements. We're transparent about the factors: pages, features, content complexity, revision rounds.

One revision round is included in every project. Additional revision rounds are available at a day rate. In practice, projects that are briefed well rarely need the additional rounds.

The content dependency

The number one reason website projects are delayed: content. Design requires content to design from. If we're designing with Lorem ipsum and the client provides the copy three weeks late, the timeline slips.

We address this upfront: content-ready before design begins is a dependency, and we build it into the contract. If a client isn't ready to supply content by the agreed date, the timeline extends. There's no exception.

After launch

We don't offer hosting. We don't offer ongoing maintenance as a standard service. What we do offer is a three-month post-launch advisory period: a monthly call to review performance, answer questions, and flag anything that should be addressed.

Most clients don't need ongoing support. The ones who do eventually commission us for a Phase Two.

Share

Ask AI

Have a question about this post?

Ask the AI reader. It pulls quotes from this post (and the rest of the archive) and answers in a few sentences.

Related

Keep reading.

Loading…