How to Write a Brief That Gets Better Results From Your Development Team.
Most briefs are either a single paragraph that could mean anything or a forty-page document that specifies nothing clearly. Here's how to write one that actually works.
The quality of what gets built is directly proportional to the quality of what was asked for. This is the uncomfortable truth behind most software projects that go sideways: the team didn't fail at building. The brief failed at communicating.
A great brief doesn't just describe what you want. It gives a development team — whether in-house or external — everything they need to make good decisions on your behalf. It answers the questions they'd ask before they have to ask them. And it creates a shared understanding that prevents the slow, expensive drift between what you imagined and what actually gets built.
Most briefs we receive are either a single paragraph that could mean almost anything or a forty-page document that tries to specify everything and ends up specifying nothing clearly. Both lead to the same result: weeks of back-and-forth, misaligned expectations, and a product that misses the mark.
Here's how to write the kind of brief that gets you better proposals, better estimates, and better outcomes.
What a brief is and what it isn't.
A software development brief is a document that communicates your project's goals, constraints, and requirements to the team who will build it. It's the starting point of every engagement — whether you're hiring a development partner, briefing an internal team, or writing an RFP for a competitive bid.
A brief is not a specification. You're not expected to define every screen, every API endpoint, or every database table. That's the development team's job, informed by the direction you set in the brief.
Think of it this way: a brief tells the team where to go. The specification — which comes out of the discovery phase — tells them how to get there. Mixing these up is one of the most common mistakes, and it leads to one of two problems: either you over-specify and constrain the team from finding better solutions, or you exhaust yourself trying to define technical details you shouldn't be responsible for.
Your job is to communicate the problem, the context, and the constraints. Their job is to design the solution.
The anatomy of a strong brief.
Every effective brief covers the same ground, regardless of project size. Here are the sections that matter, in the order a development team needs to read them.
1. Company and context.
Start with who you are and why this project exists. A development team can't design the right solution without understanding the business behind it.
What to include:
- A one-paragraph description of your company — what you do, who your customers are, and how you make money.
- The business context for this project. Why now? Is this a new product, an expansion of an existing one, a replacement for something that's not working?
- Any relevant history. If this is a rebuild, what exists today and why is it being replaced? If you've worked with other development teams before, what worked and what didn't?
Why this matters: A team building a compliance tool for a regulated fintech company will make fundamentally different architectural decisions than a team building a content platform for a media startup — even if the feature list looks similar on paper. Context changes everything.
2. The problem you're solving.
This is the most important section of the entire brief, and the one most often skipped or glossed over.
Don't start with the solution. Start with the problem. Describe, in concrete terms, what your users are struggling with today. What's painful, slow, expensive, or impossible without this product?
A weak problem statement: "We need a project management tool for our team."
A strong problem statement: "Our team of twelve manages client projects across spreadsheets, email threads, and a shared Notion workspace. Nothing is connected. Project status requires asking three people. Deadlines get missed because there's no single view of what's due and who's responsible. We need a system where every project has a clear owner, a visible timeline, and automated reminders — so our account managers spend less time chasing updates and more time with clients."
The difference is specificity. The second version gives the development team a clear picture of the pain, the users, and the outcome you're after. It also — critically — leaves room for the team to propose a solution you might not have considered.
3. Target users.
Who will use this product, and what are they trying to accomplish?
For each distinct user type, describe:
- Who they are. Their role, technical comfort level, and relationship to your business.
- What they need to do. The specific tasks or workflows this product should support for them.
- What success looks like. How will you know this product is working for them?
Keep this practical. You don't need marketing personas with stock photos and fictional backstories. You need enough detail that the development team can design for real human behaviour.
Example:
Account Manager (primary user): Manages eight to twelve active client projects. Needs to see all project timelines, update statuses, assign tasks to team members, and flag at-risk deadlines. Currently spends two hours per day on status tracking — success means cutting that in half.
Client (secondary user): Needs read-only access to their project's progress. Currently gets updates via weekly email. Success means they can check status themselves without emailing their account manager.
4. Core requirements.
This is where you describe what the product needs to do — but at the right level of abstraction. Focus on capabilities, not implementation.
Write this: "Users need to receive a notification when a deadline is approaching."
Not this: "Build a cron job that checks the deadlines table every hour and sends a push notification via Firebase Cloud Messaging to the user's registered device token."
The first version tells the team what the user needs. The second version tells the team how to build it — which is their expertise, not yours. You might accidentally rule out a simpler, better solution by being too prescriptive.
Organise your requirements by priority. The framework from our discovery process works well here:
- Must have — the product doesn't work without these. This is your MVP.
- Should have — important for a complete experience, but the product is usable without them.
- Nice to have — desirable, but only if time and budget allow.
Be ruthless with the must-have category. If everything is a must-have, nothing is — and the team can't make intelligent trade-offs when reality forces compromises.
5. Existing systems and integrations.
Software rarely exists in isolation. Tell the team what your product needs to connect to:
- Existing tools your team uses (CRM, accounting software, communication platforms)
- Data sources the product needs to read from or write to
- Authentication systems (do users log in with existing company credentials?)
- Third-party services that are non-negotiable (a specific payment provider, an industry-specific API)
Also mention what you're currently using that this product will replace. The development team needs to understand the migration path — moving data and users from an old system to a new one is often the most underestimated part of any project.
6. Constraints.
Every project has constraints. Being explicit about them saves everyone time.
Budget. You don't need to share an exact figure, but a range is essential. There's a difference between a €20,000 project and a €100,000 project, and the team needs to know which universe they're designing for. Withholding budget information doesn't give you negotiating leverage — it just means you'll receive proposals that are wildly misaligned with your reality.
Timeline. When do you need this delivered, and is that date flexible or fixed? If there's an external driver — a product launch, a regulatory deadline, a seasonal window — say so. If the timeline is aspirational rather than contractual, say that too.
Technical constraints. Does the product need to run on specific infrastructure? Are there technology mandates from your organisation? Compliance or regulatory requirements? Data residency restrictions?
Team constraints. Who on your side will be available for feedback, testing, and decisions during the project? How quickly can you turn around reviews? A team that responds in hours gets different results than a team that responds in days.
7. Design expectations.
Communicate how the product should look and feel, without doing the designer's job for them.
What helps:
- Links to products you admire — not to copy, but to convey a sensibility. "We like the clarity of Linear and the simplicity of Notion" tells a designer more than a page of adjectives.
- Your brand guidelines, if they exist — logos, colours, typography, tone of voice.
- Any existing design work — wireframes, sketches, Figma files, even napkin drawings. Anything that externalises what's in your head.
- What you explicitly don't want. "We don't want it to feel like enterprise software" is useful direction.
What doesn't help:
- "Make it modern." (Everything is modern when it's new.)
- "We want it to look like Apple." (You want a billion-dollar design team's output on a startup budget.)
- No design direction at all. (The team will guess, and they'll guess wrong.)
8. Success criteria.
How will you know this project succeeded? Define this upfront, because it shapes every decision the team makes.
Good success criteria are specific and measurable:
- "Account managers spend less than one hour per day on status tracking, down from two."
- "80% of clients check their project status through the portal instead of emailing."
- "The team can onboard a new client project in under fifteen minutes."
Vague success criteria — "the team is happier" or "things work better" — make it impossible to evaluate the outcome and create endless scope discussions about whether the project is actually done.
Common mistakes that kill good projects.
Solutioning instead of problem-stating.
When a brief says "build us a Kanban board with drag-and-drop cards and swimlanes," the team builds exactly that — even if a simple task list with due dates would have solved the actual problem in half the time. Describe the problem and let the experts design the solution.
Including everything you've ever thought of.
A brief with forty features is not a brief. It's a product roadmap pretending to be a single project. Prioritise. A focused brief that describes ten features clearly will get you a better product than a sprawling brief that mentions fifty features vaguely.
Being vague about budget.
"We're flexible on budget" usually means "we have a specific number in mind but won't tell you." This wastes everyone's time. Teams design different solutions at different price points. A €25,000 solution and a €75,000 solution for the same problem are both valid — but they're fundamentally different products. Help the team help you by being transparent.
Skipping the why.
Requirements without context are dangerous. "Add an export to CSV button" is a requirement. "Our finance team needs to pull transaction data into their reporting tool every month, and they currently do it by copying and pasting from the screen" is a problem — and it might have a better solution than a CSV export.
Writing it in isolation.
The best briefs are reviewed by someone outside the project before they're sent. A colleague, an advisor, or even a friend. If they can't understand the document, neither will the development team. Clarity isn't about dumbing things down — it's about making sure the signal gets through.
A brief template you can use.
If you want a starting structure, here's a template you can adapt:
Project title: [Name]
Company overview: [2–3 sentences on who you are and what your business does]
Problem statement: [What pain exists today, for whom, and why it matters]
Target users: [For each user type: who they are, what they need to do, what success looks like for them]
Core requirements:
- Must have: [list]
- Should have: [list]
- Nice to have: [list]
Existing systems and integrations: [What this product needs to connect to]
Constraints:
- Budget range: [€X – €Y]
- Timeline: [target date and whether it's fixed or flexible]
- Technical: [any mandates or restrictions]
- Team availability: [who's available for reviews/decisions and how quickly]
Design direction: [Links to products you admire, brand assets, explicit preferences]
Success criteria: [How you'll measure whether this project worked]
Appendix (optional): [Wireframes, sketches, data samples, competitive references]
This template fits on two pages. If your brief is longer than five pages, you're probably over-specifying.
What happens after you send it.
A good development partner will read your brief and come back with questions — not because the brief was bad, but because good teams dig deeper. They'll challenge assumptions, suggest alternatives, and flag risks you hadn't considered.
This is the conversation the brief is designed to start. The document isn't the finish line — it's the starting gun for a discovery process that turns your brief into a detailed plan.
If a team reads your brief and immediately quotes you a fixed price without asking a single question, that's a signal to be cautious. Either the project is genuinely simple, or they're not thinking hard enough about it.
The bottom line.
A brief is a communication tool. Its job is to transfer what's in your head into someone else's head with minimal distortion. The closer the development team's understanding matches your intent, the closer the final product matches your vision.
You don't need to be technical to write a great brief. You need to be clear about the problem, honest about the constraints, and disciplined about priorities. Everything else is the team's job.
Working on a brief right now?
At Nortis, we've reviewed hundreds of project briefs — and we're happy to review yours, no strings attached. If you're preparing to engage a development partner and want a second pair of eyes on your brief before you send it out, drop us a line.