How to draw up a technical specification (TOR) for a web application: A practical guide for Founders

For most startups and founders, the story begins the same way: there is a breakthrough idea for a platform, all the screens are drawn in your head, and in the Telegram Favorites there are links to analogues with a note "Do the same thing, only better".

And then the development team or studio asks one question: "Please send me technical specifications". And the process stalls. In this article, we will look at how to draw up a technical specification for a web application (SRS - Software Requirements Specification), without falling into the bureaucracy of GOST, but protecting ourselves from losing millions of rubles on rework.

---

1. What is technical specification in modern development?

Thick 150-page Talmuds are a thing of the past. In the Agile methodology, the Technical Specification is a living contract document. Its goal is to synchronize the picture in the head of the founder with the picture in the head of the database architect.

Why do you need a document if everything is “already clear”:

1. Protection from "surprises": The developer made registration only by email, but you wanted by phone number with an SMS code.
2. Exact estimate: Without detailed screens, it is impossible to calculate development hours. They will give you a range from 1 to 5 million rubles, and choose the upper limit for insurance.
3. MVP trim: Recording what we are WE DON'T DO in the first version.

---

2. Structure of the working technical specifications

Take a blank Google Doc and fill it out in 6 key blocks. This is enough to transfer the project to a systems analyst for evaluation.

Block 1. Business context and essence (Elevator Pitch)

Describe the essence of the project in 3 sentences:

• What are we doing? (B2B marketplace for auto parts).
• Who's buying? (Wholesale bases, service stations).
• What is our product feature? (Integration of warehouses in real time, instead of daily price lists).

Block 2. Roles and User Stories (Scenarios)

Avoid describing buttons (“There must be a red button”). Describe scenarios (US):

• Role "Buyer": I want to register using the company’s TIN so that the system itself will pull up my details. I want to add an item to the cart and upload a PDF invoice.
• Role "Manager": I want to see a kanban order board. I want to change the order status so that the client receives an SMS.
• Role "Super Admin": I want to be able to ban Buyers and download a monthly margin report.

Block 3. Integrations with external APIs (Critical block)

Specify what your web application should "talk" to:

• Accounting: 1C:Enterprise (how often to synchronize?).
• Payments: Acquiring T-Bank, YuKassa.
• Telephony and Messengers: Notifications in Telegram, AmoCRM.
• Delivery services: SDEK, Yandex.Delivery (tariff calculation based on dimensions).

Block 4. Non-functional requirements (NFRs)

This is what founders forget about, but then pay for:

• Load: Are you expecting 100 users per day or 10,000 per second?
• Security: Do you need two-factor authentication (2FA)? How to store pers. data (FZ-152)?
• Availability: Does the application work in a mobile phone browser (PWA/Adaptive), or is it a strict Desktop interface for accountants?

---

3. Top 4 Mistakes when setting technical specifications

1. "Make an analogue of Avito/Wildberries": Wildberries employs 5,000 programmers, and the system took 15 years to build. It is impossible to specify a billionaire service as a benchmark for an MVP for 2 million rubles. Indicate a specific narrow flow (Flow) that you like (for example, “Make a cart like in Yandex.Shop”).
2. "The design must be modern": This is subjective. Attach 3 links to sites that you visually like (References) and 3 links that you think are ugly.
3. No "Stupid User" stage: It is not described what the system should do if the client entered the word “Kitty” instead of the TIN. Mention basic validation.
4. The threat of endless Scope Creep: Constantly adding new “wants” during the development process.

Summary

You don't need to be a programmer to write a good technical specification. Your task is to describe the business logic in detail. How exactly the information will be stored in the database will be decided by the IT contractor.

B NBM-IT we do not require clients to have ideal technical specifications in accordance with GOST 34. At the Presale stage, our system analysts themselves conduct a series of in-depth interviews with the customer, formalize business processes in BPMN diagrams and write a clear technical specification that protects your project from going over budget. Discuss your idea with our technical director.

Useful on the topic

• Typical MAX bot scenarios: lead generation, support and booking (Booking)
• 10 best examples of corporate websites: Design analysis
• Case on the topic
• Profile service