What should I put in a brief for a software developer?

Matt Turley, Continuum. Updated November 5, 2026.

The one-page brief that gets comparable quotes, with the questions to answer and the mistakes to avoid.

The short answer

What should I put in a brief for a software developer?

One page: the problem and who has it, the three journeys the software must handle, what it must connect to, what you already have, your deadline and budget range, and what success looks like. Describe outcomes, not screens. A good brief lets three developers quote the same job and lets you compare them.

The one-page brief

The problem and who has it: what goes wrong today and which people feel it.
Three journeys: the three things a user must be able to do from start to finish, in a sentence each.
Connections: the booking, accounting, email or database systems it must talk to.
What exists: any current app, spreadsheet, brand files or data to start from.
Constraints: the date that matters, the budget range you can live with, and anything regulated.
Success: how you will know it worked, such as fewer errors, faster quotes or more completed orders.

Describe outcomes, not screens

A brief that dictates screens locks in your first guess. A brief that states the outcome lets a good developer propose something simpler. Say what must happen when a customer orders, not where the button goes.

Our post on how to write a SaaS development brief has a template. Share the same brief with every bidder so their quotes are comparable.

What to ask for back

Ask each bidder to return a written scope that says what is included and what is not, the price, the timeline tied to deliverables, who owns the code and accounts, and what happens after launch. Quotes that skip those are not yet quotes. How to tell whether a quote is fair goes through the warning signs.

Want a number for your own project?

Describe what you want built or fixed and get a ballpark from the published price list straight away. It is labeled as a ballpark, not a quote, and a real quote comes from me after we talk.

Get a free ballpark. Or book a call and talk it through.

Book a call →See all services and prices →

FAQ

Straight answers

Do I need technical language in the brief?

No. Plain words about your customers and your process are better. A good developer translates it; a developer who needs you to speak their language is a poor fit.

Should I put my budget in the brief?

Give a range. It stops proposals that are far off in either direction and lets bidders suggest what fits. Hiding the budget usually wastes everyone’s time.

How long should the brief be?

One page is enough to start. More detail helps once you are talking to a short list, and it can be a shared document rather than a longer brief.

What if I do not know the three journeys yet?

Then that is the first piece of work. Watch how customers or staff do the job today, write the steps, and pick the three that matter most. A short call with a senior engineer can help.

Keep reading

Get a free ballparkFree ballpark, then a real quote.How to write a SaaS development briefThe format developers want to receive before they quote.Hire someone to build an appWho to approach and what to ask before you sign.Agency, freelancer or one senior developerWho should build a business app, and why.How do I know if a software quote is fair?What a good quote contains and the warning signs.How much does it cost to build a booking app?What moves the price and what we charge.Outsource app developmentWhat to keep in your own name and what to hand off.

Sources

1. How to write a SaaS development brief, Continuum: Used for the brief template and the advice to give every bidder the same document.