Website Specs: Writing a Brief That Protects Your Budget
The structure of a working technical spec, the sections you cannot skip, and phrasing that removes ambiguity — plus a template for comparing vendor quotes.
Three studios quoted you $1,800, $3,400 and $9,000 for "a company website". Those numbers cannot be compared, because each vendor priced a different imaginary project. A technical specification is the document that makes proposals comparable and scope arguments impossible. Below: the structure of a spec section by section, the phrasing that removes ambiguity, acceptance criteria, and the mistakes that leave a 40-page document protecting nothing.
3x
typical quote spread with no spec
20%
of budget eaten by unrecorded "small things"
5–15
pages is enough for a small business
2–5
days of work for a solid spec
What a spec actually protects
The common assumption is that specs exist for developers. They exist for clients, and here is why. Without one, every difference in understanding gets settled in favour of whoever holds the stronger position — and mid-project that is always the vendor, because they hold your files and your deposit.
- It makes quotes comparable. Against an identical spec, the gap between proposals stops being a lottery: you can see who priced testing in and who did not.
- It fixes the line marked "that is separate work". The most expensive conflicts are not about quality, they follow the sentence "we assumed that was included".
- It sets the moment of payment. Acceptance attaches to checkable criteria instead of a feeling that something looks finished.
- It leaves you with a project if the relationship ends. If you have to change vendors, the spec is the only document from which a new team can reconstruct what was supposed to exist.
A structure you can write from scratch
Section order matters, because each one leans on the previous. Start with a page list and you will end up with a website nobody designed against a business goal.
- 1Goal and measurable outcome. Not "improve our image" but "30 enquiries a month from organic search within six months". This decides half the technical choices downstream.
- 2Audiences and journeys. Two or three typical visitors and the path each takes to the target action. Your navigation structure comes from here.
- 3Sitemap with template types. The budget-critical section: vendors price templates, not pages. State explicitly that a 300-item catalogue is one template.
- 4Functional requirements, block by block. Forms, filters, accounts, calculators, search. For each: what the user enters, what they see back, where the data goes.
- 5Third-party integrations. System name, direction of data flow, frequency. "CRM integration" is not a requirement; "create a deal in the CRM on form submission with name, phone and source fields" is.
- 6Content: who supplies it and when. The single most common cause of missed deadlines. Specify volume, language, deadline, and what happens if copy is late.
- 7Design and revision limits. Number of revision rounds per layout, handoff format, whose brand assets are used.
- 8Technical requirements. Stack or constraints on it, supported browsers, speed targets, multilingual needs, admin panel expectations.
- 9Minimum SEO and analytics. Meta tags, clean URLs, sitemap, structured data, tracking, goals. Without this section, none of it "was included".
- 10Acceptance, ownership and support. Sign-off criteria, handover of access and source code, warranty period, terms for support afterwards.
Sections 1–3 are written before choosing a vendor; the rest are often drafted together with them, which is fine and usually better. How that maps onto a project calendar is laid out in our breakdown of the website development stages.
Phrasing that removes ambiguity
One rule governs everything: a requirement must be answerable with yes or no. If judging it needs a discussion about taste, it is a preference rather than a requirement, and it carries no weight when things go wrong.
| Vague | Checkable |
|---|---|
| The site should load fast | LCP under 2.5s on mobile, throttled connection, home and service pages |
| A convenient admin panel | Publishing a news item with image and SEO fields without a developer |
| Responsive design | Renders correctly from 360 px wide with no horizontal scrolling |
| Payment integration | Card payment, refunds from the admin panel, order status email |
| Basic SEO | Unique title and description on every page, sitemap, robots, Organization markup |
| A few design revisions | Up to 3 revision rounds per layout, further rounds at an hourly rate |
A requirement you cannot verify in five minutes does not exist when there is a dispute.
Acceptance and comparing proposals
- 1
Split payment into three or four milestones
A common split: 30% to start, 30% on design approval, 30% on a working staging demo, 10% on acceptance. That final payment is your only leverage during final fixes.
- 2
Define "done" for each milestone
Not "design is finished" but "approved layouts for every page template at mobile and desktop widths, including form states".
- 3
Send the identical spec to every vendor
And ask for a quote broken down against your own section numbers. A single figure with no breakdown is a reason to ask follow-up questions.
- 4
Compare composition, not totals
The cheaper proposal usually omits analytics, testing or the technical SEO foundation. What to verify about a vendor is covered in our guide to choosing a web agency.
- 5
Put access handover in writing
Domain, hosting, repository, admin panel, analytics — all registered to you, not to the vendor. This is the clause people remember far too late.
Five mistakes that void the document
Check your own spec against these
- A page list exists but template types do not — the quote will be inaccurate
- Not a single number anywhere: no dates, no speed targets, no revision limits
- Feature descriptions copied from someone else’s spec that nobody read to the end
- No statement of who supplies copy and images, or what happens when they are late
- No section on access, code ownership or the warranty period
And on budget: do not hide it. Naming a range saves both sides two weeks, because the vendor can tell you immediately which parts of your list fit inside it. Market benchmarks are collected in our breakdown of what a website costs.
Frequently asked questions about website specs
Can I write the spec myself without a developer?
Yes, and the sections on goals, audience, structure and content are always written better by the client — it is their business. The technical sections covering stack, speed targets and integration formats are usually refined together with the vendor after selection. That split saves time and avoids requirements that cannot be built within the budget.
What does it cost to have a specification written?
As a standalone service it typically runs 5–10% of development cost: roughly $150–400 for a small site and $400–1,200 for a store with integrations. Many studios credit that amount against the build if you commission it from them. The condition worth agreeing upfront is that the document belongs to you and you may take it to another vendor.
What should happen when requirements change mid-project?
Changes during a project are normal; making them verbally is not. The working mechanism is that every new requirement becomes a separate change request with an hour estimate and a schedule impact, and work starts only after written approval. That removes both uncontrolled scope growth and surprise invoices at the end.
Does a simple landing page need a spec?
It does, but a short one — two or three pages is enough. Record the section structure, the target action, who supplies copy and images, the number of revision rounds, and where enquiries are delivered. Even at that size the document prevents about 90% of common disputes and takes a couple of hours to write.
Should post-launch support be part of the spec?
It should be its own section, agreed while you still have negotiating leverage. Fix the warranty period for defect fixes, usually one to three months, and separately the ongoing maintenance terms with response times and rates. What this cost line consists of is broken down in our article on website maintenance costs.
In short
- A spec primarily protects the client: it makes quotes comparable and fixes the boundary of scope.
- Quotes are calculated from template types and integrations, so those sections deserve the most detail.
- A requirement that cannot be answered yes or no is worth nothing in a dispute.
- Split payment into milestones with a written definition of "done", and keep 10% for final acceptance.
- Always cover access, code ownership, the warranty period and who is responsible for content.
Related reading
Website Project Stages: What Happens and How Long It Takes
Projects rarely stall in the code. They stall in approvals. Here is the full route and where it slows.
Choosing a Web Agency: 15 Questions to Ask Before You Sign
The worst projects start with the best presentations. These questions cut through it.
What a Website Really Costs in 2026: An Honest Breakdown
From $300 to $15,000 — and both numbers are honest. Here is exactly what you buy at each level.