A technical specification, also known as a technical task, is the document that describes what a website or app must do and how each part should work: its pages, features, integrations, content and technical requirements. Developers build and test against it, and an agency prices the project from it.
The two names mean the same thing. “Technical task” is a literal translation of the name used in some other countries, so it turns up in documents written by international teams. In the UK the usual name is technical specification, or simply “the spec”.
What a website specification covers
A good specification is detailed wherever a detail changes the cost or the way something works. For a typical business website it describes:
- Pages and templates. The full page list, which pages share a layout, and what each template contains.
- Functions. Forms and where their data goes, search, filters, booking, customer accounts, payments, file downloads.
- Integrations. The systems the site exchanges data with, such as a CRM, a booking system, a stock database or accounting software, and in which direction the data flows.
- Content. Who writes the copy, who supplies photos and product data, and how much of it moves over from the current site.
- Admin and editing. What your team needs to change without a developer: prices, opening hours, team members, blog posts.
- Technical requirements. Hosting, supported browsers and devices, page speed targets, security, cookie consent and data protection.
- SEO and migration. Which existing URLs stay, which change, and how the old addresses redirect to the new ones.
- Acceptance criteria. How everyone will know that a feature works, and what is out of scope for this stage.
Who writes the specification
In practice it is a joint document. You know the business: who your customers are, how orders or bookings are handled, which rules the site must follow. The agency knows how to turn that into requirements a developer can build and test.
Larger organisations often write their own specification for a tender. Smaller businesses usually start with a short brief, and the specification is written with the agency during a discovery stage, through questions, calls and review rounds. Whoever drafts it, the business should read it line by line and sign it off. A spec written only by the client tends to describe solutions (“we need a pop-up”) where the agency needs the underlying goal (“we want more newsletter sign-ups”). A spec nobody on the client side has read tends to miss the business rules that only staff know.
Website Technical Specification Example
Here is how the specification for an online furniture shop selling made-to-order sofas might be organised:
- Overview. Goals of the project, target customers, launch date and any fixed deadlines.
- Site map. Home, category pages, product pages, fabric samples, delivery information, about, contact, account area, checkout.
- Product catalogue. Product types, options (size, fabric, leg finish), how options affect price and lead time, how stock and made-to-order items differ.
- Checkout and payment. Payment providers, delivery zones and charges, deposits for made-to-order items, order confirmation emails.
- Integrations. Order export to the warehouse system, accounting software, email marketing platform.
- Admin panel. What staff can edit, user roles, order statuses.
- Design inputs. Brand guidelines, approved wireframes and prototypes.
- Non-functional requirements. Speed, security, accessibility, cookie consent, backups.
- SEO and analytics. URL structure, redirects from the old site, the tracking that needs to be in place at launch.
- Acceptance and handover. Test scenarios, what counts as done, documentation and training.
The order can change from project to project. What matters is that every feature someone will pay for appears somewhere in the document.
How the specification affects price and timeline
Every line of a specification turns into hours of work, so the document is what makes an estimate precise. Vague requirements push an agency to add a buffer or to exclude the uncertain part, and either way you pay for the gap later. Changes after sign-off are handled as change requests, with their own cost and time.
A clear specification also lets you split the work. If it separates what must be ready at launch from what can follow, the first release can go live sooner and the rest gets planned as a second phase.
On our website development projects, we confirm the final price after a short Discovery stage, with a line-item estimate, so each item in the scope has its own cost.
FAQ
Is a brief the same as a specification?
No. A brief is the short document you write to explain what you need and why; a specification describes in detail how every part of the site will work, and it usually comes after the brief. The website brief page linked above compares the two side by side.
How do you write a technical specification for a website?
Start from the goals and the page list, then take one function at a time and describe it as a scenario: who does what, what the site shows in response, and what happens when something goes wrong. Add the systems each function exchanges data with, and end every section with a test that proves it works. Number every item, so the estimate, the change requests and the acceptance tests can all refer to it.
What is the difference between functional and non-functional requirements?
Functional requirements describe what the site does: a customer filters sofas by fabric, pays a deposit and receives a confirmation email. Non-functional requirements describe how well it does it: how fast pages load, which browsers it supports, how often it is backed up and how it protects personal data. Both affect the price, and the second group is easy to forget because none of it shows up in a design.
How long should a website technical specification be?
As long as it takes to describe every feature someone will pay for, and no longer. A brochure site with a contact form can be covered in a few pages, while a shop with customer accounts, integrations and several user roles needs far more. Length matters less than whether a developer can build each item, and you can check it, without asking what was meant.
Is there a template for a technical specification?
The example structure above works as a starting template for most business websites: keep the sections that apply and delete the rest. A template only gives you the headings, though. The value of the document is in the answers your team writes under each one.
