How to write a software brief: what a developer needs before giving you a price

Two companies quote for the same project, and one price is three times the other. Usually neither is wrong: they priced two different projects, because the request left room for both. A short written brief closes that gap. It does not need to be long or technical. It needs to say what the software is for, who uses it, and what the first version must do.

Why does the brief decide the price?

A developer prices what they understand. When a request says "an app for our orders", one team pictures a form and a list, another a customer portal with invoicing and a connection to your accounting. Both offers are honest, and you cannot compare them.

A brief gives every offer the same starting point. It also shows you early which questions are still open, while answering them is cheap. How to read the offers that come back is explained in what drives the cost of custom software.

What belongs in a brief?

Seven points cover most projects. A sentence or a short list for each is enough.

1. The problem: what goes wrong or takes too long today, and what it costs you. For example: orders arrive by email and phone, and two people spend a day a week typing them into the system.
2. The people: who will use the software, how many of them, and what each may see and do. Staff, customers, partners, an external accountant.
3. The process today: the steps as they happen now, with the spreadsheets, forms and tools involved. A photo of a whiteboard sketch counts.
4. The first version: what it must do on day one, and what can wait. A short list of musts is worth more than a long list of wishes; what should an MVP include shows how to draw the line.
5. The data: what information the software keeps, where it lives today, and how much of it there is. Say whether personal data is involved.
6. The connections: which systems it has to work with, such as bexio, Abacus, an online shop or a bank. See what an integration involves.
7. The limits: a budget range, a date that matters and why, and who will look after the software once it is live.

What should you leave out?

A brief describes what is needed, not how to build it. Leave out:

• The technology: unless you have a reason, such as a system your team already runs, let the developer propose it and explain why.
• Finished screen designs: a rough sketch helps. Detailed layouts fix decisions before anyone has tried them.
• Every feature you can think of: list them separately as later ideas, so they are not priced into the first version.

In German-speaking Switzerland the brief is often called a Lastenheft: it says what is needed and why. The answer to it, the developer's description of how they will build it, is the Pflichtenheft. Writing the first is your job; the second is theirs.

What is specific to Switzerland?

• Personal data: since September 2023, the revised Data Protection Act requires data protection to be built into software from the start, with privacy-friendly default settings. If the developer knows early which personal data the software handles, they can plan for it instead of adding it later.
• Languages: Switzerland has four national languages. Say which languages the software needs, for staff and for customers: each language adds text to translate and screens to test.
• Swiss formats: if the software creates invoices or reads bank data, name the formats, such as the QR-bill or camt.053 bank statements.

A one-page template.

Copy these headings into a document and write a few lines under each. Anything you cannot answer yet, write down as an open question: that helps too.

1. What goes wrong today, and what it costs us
2. Who will use it, and what each person may do
3. How the process runs today, step by step
4. What the first version must do, and what can wait
5. Which data it keeps, and whether personal data is involved
6. Which systems it connects to
7. Budget range, dates that matter, who looks after it after launch
8. Open questions

Then send the same document to every company you ask for an offer, and ask each one which questions it raised. The questions you get back tell you as much as the price, and what to ask before you sign covers the rest.