Writing a Technical Specification Without Overpaying

Quotes for the very same project can differ threefold between studios. Usually that does not mean somebody is greedy — it means the task was described vaguely and each of them costed their own version. Where there is uncertainty, a contractor prices in risk, sometimes 30–50 percent on top. A good specification removes that buffer, and it is often the spec rather than the haggling that brings the price down.

A spec is boundaries, not dreams

The document's main function is to fix what is in scope and what is not. The second matters even more than the first. The sentence "version one has no mobile app, no 1C integration and no multi-language support" is worth more than ten pages describing beautiful screens, because it is at the boundaries that payment disputes arise. Anything not in the document is treated by default as additional work — and both sides need to understand that the same way.

What a working spec consists of

• Goal and metric: why the system is needed and which number will tell you it worked.
• User roles and what each one can do. This doubles as the basis for the access model.
• Scenarios: the sequence of steps from start to result, in plain words.
• Data: which entities are stored, how they relate, where they come from and where they are exported.
• Integrations, naming the specific systems and whether they have documented APIs.
• Non-functional requirements: load, speed, hosting location, personal data storage requirements.
• What is explicitly out of scope.

How to write scenarios

The most useful part of a spec is the description of the user's path from intent to result. Not "the system shall support customer booking" but "the customer opens the service page, picks a specialist or skips that step, sees free slots two weeks ahead, enters a phone number, receives a code, confirms, and gets a message with the address". Text like that can be costed, and it can then be used to accept the result. Abstract phrases such as "convenient interface" and "modern design" are no help at acceptance, because they cannot be verified.

Who writes the document

There are three options. Writing it yourself is cheap, but you end up with a description of wishes that ignores technical constraints, and the contractor rewrites it anyway. Commissioning it from the same contractor is the most common and sensible route: 40,000–150,000 roubles and one to three weeks, and you end up with a document that can actually be costed. The formal risk is that the document gets written around a solution convenient to that contractor, and it is mitigated by the spec remaining your property, so you can take it to another studio for a comparative quote. The third option, an independent analyst, is justified on projects of several million and up. With us, design work is a separate paid stage before development, and its output belongs to the client whether or not they continue working with us.

What to add so you do not rebuild later

State the accessibility and mobile requirements explicitly: if 70 percent of users will arrive from a phone, that affects the interface architecture, not just the markup; there are good benchmarks in the accessibility guide on web.dev. Fix the security requirements at least at the level of "the system is checked against the OWASP Top 10" — that gives a clear acceptance criterion instead of a vague "it should be secure", and what exactly we check is described in the security section. And specify what happens to the data and the access credentials when the project ends.

What should not be in a spec

Do not turn the document into two hundred pages describing every button: by the time you finish writing it the task will have changed, and nobody will read it anyway. For a system of medium complexity, 15–30 pages is about right. Do not fix technologies unless you have a reason to: requiring "a specific framework" without justification narrows your choice of contractors and pushes the price up. And do not put deadlines in the spec — they belong in the contract, tied to stages and liability.

A check before you send it out

Give the document to someone who had no part in writing it and ask them to describe what the system should do. If their account matches your intent, the spec works. If questions of the "but what happens if..." kind come up, write them down — those are your future points of dispute. And finally: send the identical document to every contractor. Only then can the quotes be compared rather than guessed at. The structure of a document for a specific project can be discussed before work begins — that part of the conversation is free.