Technical specification
What is a technical specification?
A technical specification is the document that says exactly what will be built: which pages and functions, who supplies what, by when, and the conditions under which the work is accepted. It turns a conversation into a checkable list, so that “a site with a shop” becomes a named set of features. Written before the quote, it decides the scope and what later counts as a change.
Example
A furniture maker asks for “a site with a catalogue and an enquiry form”. Both sides picture something different: the builder counts 12 pages and one form, the client expects 40 products with colour and fabric variants, a filter by size, a PDF of dimensions on every product, and a second language.
A technical specification separates those two pictures before anyone writes code. It lists 12 text pages; a catalogue of 40 products with up to six variants each; a filter on three attributes; a PDF field; Bulgarian and English; a form of five fields that sends an email and stores the enquiry in the admin panel. Anything outside that list is a change: described, priced and accepted separately.
The same document says who supplies what. The client sends photographs and copy by a stated date; the builder delivers structure, design and code. When the photographs arrive three weeks late, the specification already says the deadline moves, and nobody argues about whose fault it was.
Why it matters for a business
Without one you compare quotes that describe different work. One covers 12 pages, another 40 products, and the lower number looks better only because it is for less. Send the same specification to three builders and the numbers become comparable. What moves the number in a quote is set out on the pricing page, and what else to ask in how to choose a web development company.
It is also the test for acceptance. “Done” stops being a feeling: the pages are listed, every function is described, and every one of them can be checked. And it is what protects you when the team changes — the next people start from a document instead of reconstructing decisions from memory.
We start the same way: structure and scope are fixed before code is written. What goes into a project is set out on the website development page.
What to ask
- Who writes the specification — you, the builder or both — and is it part of the contract?
- Does every function have an acceptance test, or is there only a list of pages?
- What is recorded as your obligation, and by when: copy, photographs, access, data?
- How is a change handled: who describes it, who prices it, who approves it in writing?
- What stays with you at the end — the specification, the documentation, the accounts and the code?