Every custom software project starts with a brief. Sometimes it's three pages, sometimes it's a paragraph in a WhatsApp message: "we need a system to manage our jobs." Both extremes cause the same problem — a developer who has to guess at what you actually meant, and a quote that guesses along with it.
You don't need to write like a product manager. You need to answer a handful of questions clearly enough that two different studios would come back with roughly the same understanding of the project. Here's how.
What a brief actually needs to do
A brief isn't a specification. It's not supposed to describe every screen and button — that's what a discovery phase is for. Its job is narrower: give a developer enough context to ask good questions and price the work within a sensible range, instead of guessing and padding the number to cover the guess.
The five things every brief needs
1. The problem, not the solution
"We need an app" tells a developer nothing. "Our field technicians fill in paper job sheets that take two days to reach the office, and invoicing waits on them" tells them everything. Describe what's broken before you describe what you think fixes it. Sometimes the fix you had in mind isn't the cheapest one.
2. Who uses it, and how often
Ten people using something daily is a different system than 200 people using it once a month. User count and frequency drive almost every architecture decision — and a chunk of the cost.
3. What "done" looks like
One measurable outcome beats ten feature ideas. "Invoices go out within 24 hours of a job closing" is something a developer can build toward and you can verify. "Make invoicing better" is not.
4. What already exists
List every system this needs to touch — your ERP, your accounting package, a spreadsheet, an old in-house tool. Note whether you know if it has an API. This single detail swings integration cost more than almost anything else in the brief.
5. Your real constraints
Budget range, hard deadline, compliance requirements. Studios can't design around constraints they don't know about. "We have €20,000 and need this live before the trade show in October" is more useful than no number at all — it tells a developer what to cut first if the scope doesn't fit.
What to leave out
Don't try to spec every screen yourself unless you're paying for that expertise elsewhere. Wireframes drawn by someone without a background in UX often lock in bad decisions that a proper discovery phase would have caught. Describe the workflow, not the pixels.
Also skip the technology wishlist unless you have a real reason for it. "Must be built in React" only matters if you have an in-house team that needs to maintain it in React specifically. Otherwise you're narrowing your pool of studios for no benefit.
A brief that actually works: an example
Compare these two:
Weak: "We want a dashboard to see our sales data."
Strong: "Our sales team currently checks four separate spreadsheets to see monthly performance per region. We want one screen, refreshed daily, showing revenue and pipeline by region for our 8 sales managers. Data currently lives in HubSpot and our own order database (SQL, no API documentation that we know of). Budget: €10,000–€15,000. No hard deadline, but we'd like it before Q4 planning starts."
The second version is five sentences longer and saves weeks of back-and-forth. A studio can size that project within 10%. The first one, they're guessing — and every guess gets padded with a buffer, which you end up paying for.
What happens after you send it
A good studio reads your brief and comes back with questions, not just a price. If a quote lands in your inbox within a day with no questions attached, that's not efficiency — it's a sign nobody read closely enough to spot what's missing. The brief starts the conversation; it isn't meant to end it.
Want a second pair of eyes on your brief?
Send me what you have — three lines or three pages, doesn't matter. I'll tell you what's missing, what's already clear enough to quote against, and roughly what the project would cost. Get in touch.