How to Write a Software Brief: A 12-Question Template That Locks the Price

"We need a system where customers can place orders and we can see them" — we receive descriptions like this often. It is honest, but it could be built for €500 or for €15,000. A brief is not a document for the developer; it is the way you yourself understand what you are buying. Below are twelve questions that turn a three-sentence description into a document against which price and deadline can be fixed.

Why three sentences are not enough

A developer who receives a vague description has two options: ask twenty questions or decide alone. The second path is faster — and the most expensive, because a month later it turns out that "orders" also meant invoices, delivery tracking and three staff roles. Every "oh, and we also need" after kick-off costs 2–3 times more than the same item written in the brief.

The twelve questions

About the goal

1. What problem are we solving? One sentence: "We take orders by phone and forget them; we want customers to order themselves and us to get a notification." Not "we want a modern system".
2. How will we measure success? A number: "80 % of orders come through the system within 3 months", "admin time drops from 10 to 3 hours a week".
3. Who will use it? Every role, with numbers: 2 receptionists, 6 technicians, ~300 customers a month. Each role is a separate set of screens and a separate cost.

About the work

1. How is it done today? Step by step, with tools: "customer calls → we write it in a paper diary → in the evening we retype it into Excel → the day before we call to remind". This line is exactly where the developer sees what can be automated.
2. What must the system do in version one? A list of 5–10 actions, each starting with a verb: "customer picks a service and a time", "receptionist sees the day's list", "system sends a reminder the day before".
3. What is definitely NOT needed in version one? An equally important list. "Online payments — no, loyalty programme — no, mobile app — no." This halves the cost of version one and lets you launch in weeks rather than months.

About data and systems

1. What data do we store? Objects and their fields in plain language: "customer — name, phone, notes; order — service, time, price, status". Mark personal data separately — it determines the storage and the GDPR part.
2. What must it connect to? Existing systems and their role: "WordPress website (the form stays), accounting software (invoice export), Google Calendar (technicians' schedules)". Each integration is a line in the quote.
3. Where does existing data come from? If you have 2,000 customers in Excel, migration is work. If there is no data, it is simpler.

About limits

1. Budget and deadline. Not "how much will it cost?" but "we have up to €3,000 and want it by March". The developer can then propose what fits instead of guessing. For orientation: a single automated workflow starts at €150, a system with its own database and roles at €1,500; the full web application pricing table is on the service page.
2. Who makes decisions on your side? One person who answers questions within a day. Projects where "the team" decides take twice as long.
3. What happens after launch? Who maintains it, who edits texts, whom to call if it breaks. Support terms are agreed before, not after.

One page, not twenty

A good brief for a small project is 1–2 pages. If it runs to ten, the project is too big for a first version: go back to question 6 and move half of it to "later".

Example: filled in within 40 minutes

A car repair shop, 3 mechanics. Problem: bookings by phone, 15 calls a day, a double booking once a week. Success: half of bookings online within 2 months, double bookings — 0. Roles: customer, receptionist, mechanic. Today: call → paper → Excel in the evening. Version one: customer picks a service, mechanic and time; receptionist sees the day and edits it; mechanic sees their day on a phone; system sends an SMS reminder the day before. Not in version one: payments, parts ordering, customer history with photos. Data: customer (name, phone, car), booking (service, mechanic, time, status). Integrations: none; later — accounting. Existing data: none. Budget: up to €2,500, by February. Decides: the owner, replies the same day. After launch: texts in-house, technical support as needed.

With a sheet like this, a quote with an exact figure arrives the next day.

What to leave out of the brief

• Technologies. "It must be PHP" or "we want React" — unless you have a team that will maintain it. Choosing the technology for the task is the developer's job.
• Design details. "Blue, rounded button" — that is settled with mockups, not in the brief. "Styled like our website" or links to two examples is enough.
• "Simple", "intuitive", "modern". These words fix nothing. Replace them with a concrete action and time: "a customer books in 3 taps".

What to do tomorrow

Copy the twelve questions into a document. Answer the first six — that is half the work and enough for a first conversation. Fill in the rest together with the developer: that beats guessing. If after question 6 your "not needed" list is shorter than your "needed" list, go back and move at least two more items.

Frequently asked questions

Should the developer write the brief?

The first version — you: only you know how you work and what you want. The developer adds questions and technical notes. If an agency offers to write the brief for you at a separate fee, that is normal for larger projects (several thousand and up); for small ones it is an unnecessary step.

What if we want to change something during the project?

Normal and expected. The difference is that the change is priced separately ("that is +2 days and +€300") and you decide whether it is worth it now or in version two. Without a brief there is nothing to compare against, and the "but that was obvious" argument is inevitable.

Does the brief fix the price?

Yes — we agree the price and deadline against it before starting, and they do not change unless the brief does. That is the whole point: both sides know what will be built.