How to Prepare for a Software Project: Brief and Requirements

In short: a good brief isn't a technical specification, it's a clear description of your business problem, goals and users. The more precise it is, the more accurate the quote and the smaller the chance of surprises along the way.

You don't need to be a programmer to write a good brief. The business side is what you know best, and what matters most to a developer.

The 8 parts of a brief

1. The business problem

What doesn't work now? What does it cost (time, money, errors)? For example: "Excel-based order processing takes 15 hours a week and causes several errors a month."

2. The goal and how to measure success

What do you want to achieve and how will we know it worked? For example: "Admin time halves and there are no data entry errors."

3. Who uses it?

The user types (for example salesperson, warehouse worker, manager), their number, technical skill, and what they do in the system.

4. Current process

Describe step by step how the process works now, which tools you use and where the pain points are. Attach spreadsheets or sample documents. You'll find the signs of outgrowing Excel here.

5. Desired features with priority

List what the system must do and mark each as must-have (first version), important (soon), or nice to have (later). This helps define the MVP.

6. Integrations and data

Which systems must it connect to (invoicing, e-commerce, CRM)? What data must be transferred? I wrote about integration here.

7. Constraints

Budget (even a range), deadline, legal and data protection requirements, existing technology constraints.

8. Decision makers and process

Who decides, who approves the work, and who is the contact on your side?

What NOT to put in the brief

• A specific technology, unless justified. Leave the technical side of the solution to the developer.
• Detailed UI designs before there's a validated process.
• Everything that is "nice to have" in the first version.

How does this help the quote?

The more precise the brief, the narrower the quote's uncertainty range. I wrote separately about the factors that drive cost. Good preparation often reduces changes mid-project by 10–20%.

No finished brief? No problem

My consultation is for exactly that: together we clarify the problem, goals and priorities, then you get a written proposal. You don't need to know everything up front.

If you'd like to get started, book a 30-minute consultation. You can read about my services here.