Website Development Specification: How to Write One, with an Example and a Template

A website development specification (also called a website requirements document or technical specification) is the document in which the client and the developer record exactly what will be built: which pages, what goes on each, how forms and the catalogue work, which systems the site connects to, and by what criteria the work is considered finished. A good specification gives you an exact price and timeline before work starts and removes the main source of disputes at handover: “that’s not what I meant”.

Below: how a specification differs from a brief, which sections it consists of, how to write requirements that can’t be read two ways, a sample section, and a downloadable template (Word, 12 sections with hints).

Why the client needs a specification

It may seem that the specification is for the developer. In fact it protects you first of all.

• An exact price. Without a description of the features, an agency estimates by eye and adds a buffer for the unknown, or quotes low and then charges extra for every “surprise”.
• A fair comparison of quotes. When three agencies price the same document, you compare prices for the same scope, not different products under the same name, “a website”.
• Calm acceptance. Finished means matching the specification. Not “I like it or I don’t”, but specific items.
• Independence from the contractor. If you have to change agencies mid-project, the new team doesn’t have to figure everything out from scratch.

Brief vs specification: what’s the difference

The usual order is this: you fill in a brief or describe the task at a meeting, the agency asks clarifying questions, and then together you turn the answers into a specification. You don’t have to write one from scratch yourself. But the more you know about your task, the more precise it will be.

What a website specification contains: 12 sections

These sections follow our template, so you can fill it in as you read.

1. About the company and the website goal

What you do, for whom, and why you need the site: enquiries, sales, partner trust, hiring. And how you’ll know it works, for example “20 enquiries a month from the website”. Add the address of your current site and 2–3 competitors.

2. Audience and target actions

Who comes to the site, what they’re looking for and what they should do: send an enquiry, call, download a catalogue, buy. It helps to write down the questions customers most often ask your sales team; they later become the blocks of your pages.

3. Site structure

A list of pages. Pages of the same type (services, case studies, products) are described by one template, and that matters for the price: the cost depends on the number of unique templates, not pages. More in our article on how much a website costs.

4. Page descriptions

For each template, the blocks from top to bottom: what’s in the block, where the content comes from, what the action is. This is the most useful part of the specification: it’s where you decide whether a visitor will find the answer and the enquiry button. There’s an example below.

5. Functionality

Forms, catalogue and filters, search, calculator, customer account, payment. For each feature, how it works and what happens after a click. “A product catalogue” isn’t a requirement. “A car catalogue with filters by make, year, price and body type, sortable by price” is. That kind of catalogue, incidentally, was one of the key tasks in the A-Finance project.

6. Design

A brand book, or at least a logo and colours. References: 2–3 websites with an explanation of what exactly you like about each, “I like how this site shows prices” rather than “I like the site”. And what definitely doesn’t suit you.

7. Content

Who prepares copy, photos, video and translations, and by what date. Content is the most common reason a finished site doesn’t launch for weeks. How to prepare it is in our article on website content creation.

8. Integrations and analytics

Where enquiries go: CRM, email, team chat. Payments, shipping, accounting system, telephony. Which actions count as conversions in Google Analytics. For example, for the Beauty International School landing page, collecting enquiries in the CRM and tracking every goal action were in the brief from the start, so enquiries have gone into the school’s CRM via API from day one. More in our article on website CRM integration.

9. Technical requirements

The CMS, language versions, responsiveness, browsers, domain and hosting (whose name they’re in), backups, admin panel protection. Also speed requirements in numbers; more on those below.

10. SEO

A separate title and description for every page, editable in the admin panel, a sitemap, human-readable page addresses. If you already have a site, a list of old addresses and redirects to the new ones is a must, or you may lose your Google rankings. Why this is critical is explained in our article on website redesign.

11. Stages and timeline

Structure and prototypes, design, development, content upload, testing, launch, with dates, what you receive at each stage and when you need to give your feedback.

12. Acceptance

A list of what you check before launch: all pages are filled in, the site works properly on a phone, test enquiries have arrived, speed meets the requirements, indexing is allowed, and access to the admin panel, hosting and domain has been handed over to you.

Who writes the specification and how long it takes

The best specification is written by two sides. The client brings knowledge of the business: customers, services, prices, sales processes. The agency brings experience of what needs to be clarified and how to build it: an analyst or project manager asks questions, proposes solutions and records the agreements.

The options you’ll see in practice:

• The client writes it alone. Possible if you’ve done such projects before. The risk is describing a solution (“we need a slider on the home page”) instead of the task (“show our three main services”).
• The agency writes it from a brief and meetings. The most common route: it’s the analysis stage at the start of the project, and you approve the result before design begins.
• It’s commissioned separately from an independent analyst, to send to several agencies and compare prices.

It takes from a few days for a landing page to a few weeks for a store with integrations. What usually delays a specification isn’t its size but the answers: the faster the client signs off on items, the sooner work starts.

Example: a specification section for a service page

Here’s what the “Page descriptions” section might look like for a fictional ventilation installation company. The example is made up, but the level of detail is realistic.

Template “Service” (6 pages: ventilation for warehouses, factories, offices, restaurants, air conditioning, maintenance).

1. First screen. Heading: service name + who it’s for (“Ventilation installation for warehouses”). Subheading up to 20 words: what we do and how long it takes. A “Get a quote” button opens the form (item 7). A photo from a real project.

2. What’s included. 4–6 items with icons: design, equipment, installation, commissioning, warranty.

3. Prices. A table: type of premises, price from (per m²), timeline. Under the table: “Exact price after a free site visit”.

4. Project stages. 5 steps from enquiry to handover, each with a timeline.

5. Case studies. 3 cards: photo, project name, area, timeline. They link to case study pages. Managed from the admin panel: for each service we choose which case studies to show.

6. FAQ. 5–7 questions, editable in the admin panel.

7. Form. Fields: name, phone (required), floor area, comment. After submission, a message: “Thank you, we’ll call you back within a working hour.” The enquiry goes into the CRM, pipeline “Website”, with the service name and UTM tags, with a copy to the sales team’s email. Form submission counts as a conversion in Google Analytics.

Notice that the developer, the designer and you all read this text the same way. That’s exactly what a good specification achieves.

What to add to a specification for an online store

For a store, a separate block about selling is added to the 12 sections. This is where “unexpected” extra charges most often appear, so describe it in the most detail:

• Product page: which fields (price, old price, stock, specifications), how many photos, whether there are variants such as size, colour, configuration.
• Catalogue: categories, filters by attributes, sorting, search.
• Cart and checkout: steps, required fields, whether guests can buy without registering.
• Payment and shipping: which payment methods and carriers, how shipping cost is calculated.
• Data exchange: where products, prices and stock come from (an accounting system, a spreadsheet, manual entry), and whether you need feeds to marketplaces.
• After the order: statuses, emails and notifications to the customer, where the order goes in the CRM.
• Promotions: promo codes, discounts, gifts, loyalty discounts.

A poorly thought-out checkout is one of the main reasons people abandon their carts. What else causes it is covered in our article on cart abandonment.

How to write requirements that can’t be misread

The main problem with most specifications is evaluative words that everyone reads differently. Replace them with verifiable facts:

The speed numbers are the Core Web Vitals thresholds Google uses to assess pages. What they mean is explained in our article on website loading speed.

Common specification mistakes

1. Evaluative words instead of requirements: “nice”, “convenient”, “modern”. See the table above.
2. No mobile version. If the specification describes only the desktop, the developer will decide how mobile looks, and not necessarily the way you’d want.
3. Features “for the future”. A customer account that “we’ll need some day” doubles the price today. It’s better to launch the essentials and extend based on real data.
4. Nobody is assigned to content. In the end the design is done, development is done, and the site sits there without copy.
5. No acceptance criteria. Then “finished” means whenever the contractor thinks it’s finished.
6. The specification isn’t updated. Changes along the way are normal, but each one should go into the document, together with its effect on price and timeline.

A broader list of expensive decisions worth weighing before you start is in our article on website development mistakes.

Website specification template

We’ve put all 12 sections into one Word document: tables to fill in, hints for every item and an acceptance checklist at the end.

Download the specification template (.docx, 13 KB)

You don’t have to fill in everything. Even the first three sections (goal, audience, structure) give an agency enough to name a realistic price and timeline range in the first conversation. The rest is easier to complete together.