“Build a website like our competitor's, only better” — the most expensive sentence in web development. Not because it is cheeky, but because it cannot be delivered predictably: every participant ends up with their own idea of “better”. A technical specification exists precisely so that everyone shares one picture of scope, deadlines and readiness criteria. Let's look at what happens without a spec, what it should contain, and why it is the most profitable project stage.
What happens without a spec
- Every edit is a haggle. The scope is fixed nowhere, so any “could we also…” becomes a negotiation about extra payment — even when it was the contractor's mistake
- Deadlines drift. “In about a month” without a fixed list of work turns into “two more weeks” — with no consequences for anyone
- Acceptance becomes an argument. Without readiness criteria the dispute runs on feelings, and the parties' feelings never match
- The price grows in plain sight. An estimate built on three inputs gets revised at every stage — not out of greed, but out of ignorance of the real scope
The paradox is that clients who skimp on the specification almost always overpay on edits — it is just harder to see, because the overpayment is smeared across stages and never looks like a single line in the estimate.
What a good specification contains
A good document is not long — it is complete. Five mandatory parts:
- Goals and success criteria. Why the project exists: leads, sales, awareness. Without goals you cannot decide what to sacrifice when the scope doesn't fit the budget
- Structure. A map of pages and screens: what exists, what links to what, what happens on mobile
- Functionality. For each page — what must work: forms, catalog, integrations, authentication. With described behavior, not vague words like “convenient and modern”
- Scope boundaries. What is NOT included in the work. This section matters more than the “what's included” list — future disputes live exactly here
- Acceptance criteria. How readiness is verified: a list of checkable items, not “we like everything”
Add to that: stage deadlines, payment schedule, and the list of materials each side provides. Everything else is a nice extra, not a replacement for these five parts.
How we write design briefs: a real example
At PROWEB we write the specs and briefs ourselves: the client states the tasks, we fix the scope. A recent example is a design brief for a corporate website redesign. What's inside:
- Principles instead of abstractions. The document opens with visual principles in the “less, but better” spirit (Dieter Rams): content in focus, the interface as an “invisible guide”, one accent color taking no more than a tenth of the area
- Design tokens. Colors, typography, spacing, radii and animations are described as named variables; components reference only tokens, so a dark theme or palette change doesn't redo the whole layout
- A component library. Buttons, forms, cards, accordions — each component with variants: light and dark themes, sizes, hover/focus/error states. Pages are assembled from ready components, not drawn from scratch
- Per-page specifications. For every page — desktop and mobile layouts, states of interactive elements, and annotations on behavior and animations
- Acceptance criteria and process. Separate sections: accessibility (text contrast, keyboard navigation), a cap on revision iterations per page, and the demo routine after each stage
Such a document is not bureaucracy for its own sake: the work is accepted against it. The designer knows what to draw, the developer knows what to build, the client knows what to check.
Who should write the spec
A typical mistake is expecting the client to write the spec alone — or, conversely, expecting the contractor to “just get it”. What works is a division of labor:
- The client states the business part: goals, audience, what the site must do, what materials exist, what the constraints are — deadlines, budget, legal requirements
- The contractor translates that into scope: structure, functionality, technology, acceptance criteria, the estimate
- The final edition is joint: the document is fixed when both sides understand it identically
If a contractor is against a spec “because it's all clear anyway” — it is not about the document. It is about how the whole project will go.
What a spec saves
- “We understood it differently” edits — the biggest source of cost overruns in web projects; a fixed scope removes almost all of it
- Acceptance disputes — readiness criteria are written before the start, when the parties still trust each other
- Rework — a change at the spec stage costs hours; the same change after launch costs days
- Everyone's time — “how is this supposed to work?” questions get answers from the document, not from the chat
Working on the spec takes days. Rework without a spec takes weeks. Do the math on which is cheaper.
In short
A specification is not a formality but a fixed scope: goals, structure, functionality, boundaries (“what is NOT included”) and acceptance criteria. Without it, every edit is a haggle, deadlines drift, and acceptance becomes a dispute over feelings. The client states the tasks, the contractor fixes the scope; both parties sign off on the final edition. A good spec — with principles, design tokens, a component library and per-page specifications — saves not only design and development but also nerves: the document people work by is the same document the result is accepted by.