How to write a technical brief is usually the first question before ordering a website, a Telegram bot or an app. A brief (locally often called a TZ) describes the project in writing: who it is for, what it does and when it counts as finished. Below: the sections, a checklist, clear vs vague wording, common mistakes and a template.
Why a brief matters: fixed price and deadline
A developer prices a project by the amount of work. With an unclear scope, either a "buffer" goes into the price, or every new requirement is negotiated along the way. Either you overpay, or the final cost and deadline stay unknown until the end.
With a good brief, every page, feature and integration is known upfront. That is why we fix the price and deadline in the contract once the brief is agreed, and they do not change. At handover, you check the result against written criteria, not gut feeling.
If it is not in the brief, it is not in the project. If a feature matters to you, put it on paper, even if it is just two or three sentences.
Sections of a brief: a checklist
A brief does not have to be long; a landing page needs a page or two. What matters is that every section has an answer:
| Section | What to write | Example |
|---|---|---|
| Goal and audience | Why the project exists and who uses it | "Cafe customers order delivery from their phones" |
| Pages or screens | The full list and what is on each | "Home, menu, cart, contacts, about us" |
| Features | Written as user scenarios | "The customer picks a dish, enters an address and pays" |
| Content | Who provides texts and photos | "We write the texts, a photographer shoots the dishes" |
| Design | Sites you like and dislike; logo, colors | "Two or three reference sites, we have a brand book" |
| Integrations | Which systems it connects to | "Click and Payme, orders to a Telegram group, stock levels from 1C" |
| Languages | Which languages and who translates | "Uzbek (Latin) and Russian, we handle translation" |
| Admin and roles | Who manages what | "The manager sees orders, the owner changes prices" |
| Non-functional requirements | Speed, mobile version, hosting, domain, CRM | "Fast on phones, domain in the company's name" |
| Deadline and acceptance | When you need it and how the work is checked | "Before the season; accepted when a test order goes through" |
How to describe features: clear vs vague
Most misunderstandings happen here. Describe features through user actions, not technical terms: "who does what, and what happens". Examples:
- Vague: "We need a user-friendly site". Clear: "The customer opens the order form from the home page in two clicks".
- Vague: "Online payment". Clear: "The customer pays via Click or Payme, the order becomes 'Paid' and the manager gets a Telegram message".
- Vague: "The bot should feel modern". Clear: "The bot works in Uzbek and Russian, asks for a language on first launch and remembers the choice".
- Vague: "We need an admin panel". Clear: "The manager adds products, edits prices and photos, and hides out-of-stock items".
- Vague: "CRM integration". Clear: "Every request from the site lands in the CRM as a new lead with name, phone and the chosen service".
Test: two people reading it picture the same thing.
Common mistakes in a brief
- Describing only the look: "blue, beautiful", with nothing about what the site should do.
- Writing "like our competitor". Nobody knows what is inside a competitor's site.
- Forgetting content. If nobody agrees who provides texts and photos, a finished project cannot launch.
- Leaving integrations for later. Adding 1C or a CRM at the end often means reworking the structure.
- Skipping acceptance criteria. Then everyone has their own idea of "done".
- Putting everything into version one. Launching the core scenario first is cheaper and faster.
A technical brief template
Copy this skeleton and write a few sentences under each point. If you do not know an answer, write "not sure, need advice" rather than leaving it empty.
- About the project: the company, what you sell, the goal.
- Audience: who uses it, on which device, in which language.
- Structure: the list of pages or screens.
- Scenarios: a list in the form "the user does ..., as a result ...".
- Content and design: who prepares what, links to references.
- Integrations and admin: payments, CRM, 1C, Telegram; roles.
- Non-functional requirements: mobile version, speed, hosting, domain, languages.
- Deadline and acceptance: the target date and how the work is checked.
The template works for a site, a bot or an app; only details differ (pages, commands and buttons, or screens). More on each: website development, Telegram bot development and mobile app development. Not sure which site you need? Read landing page or corporate website.
No time to write a brief?
Writing a brief is not most clients' line of work, and that is fine. We can draft it together: during the free 15-minute consultation we ask about the goal, main scenarios and integrations, then write the document and send it to you for approval. You only read it and suggest edits.
Once the brief is approved, the price and deadline are fixed in the contract and do not change. To estimate your budget in advance, see prices and the calculator: for example, a landing page costs from 1.5M UZS. If you are not sure which solution fits, take the short quiz.
FAQ
Who should write the brief, the client or the developer?
You know the business side, the developer knows the technical side. It works best together: you describe goals and scenarios, we turn them into technical language, you approve.
Can the brief be changed after it is approved?
Yes. A new requirement is estimated separately and its effect on price and deadline is agreed in writing. The agreed part stays at the contract price.
Does a small landing page need a brief too?
Yes, a short one: the blocks, where form requests go, who writes the texts, which languages. One page is enough.
