How to Write a Good Brief for a Software Project

You’ve decided you need custom software. You’ve found a company you want to talk to. Now comes the part that trips most people up: what do you actually say?

You don’t need a 50-page technical document. But “I need an app” doesn’t give anyone enough to work with either. The sweet spot is somewhere in between, and it’s simpler than you think.

Here’s what actually helps us (and any good development partner) give you a useful answer fast.

Start with the problem, not the solution

This is the single most important thing. Don’t tell us what to build. Tell us what’s not working.

“Our sales team wastes two hours a day copying data between three tools” is a better starting point than “I need a CRM with a dashboard and API integrations.” The first one gives us enough to understand your world. The second one jumps to conclusions and might be solving the wrong problem entirely.

A good brief describes the pain. The solution is what we figure out together.

Who will actually use it?

A tool for your warehouse team has completely different needs than one for your clients. Tell us:

• Who uses it: employees, clients, partners, or a mix?
• How many people: 3 people in one office, or 200 across the country?
• What devices: do they sit at a desk, or are they in the field with a phone?
• Technical skill level: are your users comfortable with technology, or do they need something extremely simple?

These details shape the entire design. A field worker scanning barcodes on a phone needs a very different interface than an accountant working on two monitors.

Describe the “before” state

Tell us what you’re using right now. Even if it’s embarrassing. Especially if it’s embarrassing.

“We track everything in a shared Excel file that breaks every other week” is incredibly helpful. “We currently use software X but it doesn’t support Y” is even better.

Knowing where you’re coming from helps us understand the gap between where you are and where you want to be. It also prevents us from building something that’s accidentally worse than what you already have in some important way.

What does success look like?

This is the question most people skip, but it’s one of the most valuable things you can answer.

How will you know the project worked? Be specific:

• “Our monthly reporting goes from 8 hours of manual work to one click”
• “Clients can place orders without calling us”
• “New employees can learn the process in a day instead of two weeks”

These aren’t features. They’re outcomes. And they help us make better decisions about what to prioritize and what to leave out.

It’s OK to share your budget

Many people avoid mentioning budget because they’re afraid of being overcharged. But hiding your budget actually works against you.

If your budget is 5,000 euros, we’ll propose a different solution than if it’s 50,000. A smaller budget sometimes means a simpler approach that still solves the core problem, and sometimes it means starting with phase one and building from there. Without knowing your range, we might spend time designing something you can’t afford, or propose something too basic when you’re ready for more.

You don’t need an exact number. “We’re thinking somewhere between X and Y” is plenty. It helps us give you an honest answer quickly.

Show us something you like

Is there a tool you genuinely enjoy using? A booking system you like as a customer? An internal tool at a previous job that just worked?

Send us a link or a screenshot. This tells us more about your expectations than a paragraph of description. It’s not about copying someone else’s product. It’s about understanding what “good” looks like to you.

What you don’t need to worry about

You don’t need to decide:

• Which programming language to use
• Whether to use a cloud server or on-premise
• What the database structure should look like
• How the API should work

That’s our job. If you have opinions on these, great, we’ll discuss them. But don’t let technical decisions block you from writing the brief.

A good brief fits on one page

Seriously. If you can answer these questions in a page or two, you’ve given us more than 90% of clients do on first contact:

1. What problem are you trying to solve?
2. Who will use the solution and how?
3. What do you use today?
4. What does success look like?
5. Rough budget range
6. Any important deadlines?

That’s it. Curious what happens from brief to finished product? Read about the full process here.

---

Want to skip the brief entirely? That’s fine too. Get in touch and we’ll work through these questions together. Some people prefer talking it out, and that works just as well.