More software projects die at the brief than at the build. Nobody likes hearing that. Developers would rather the problem be technical. Clients would rather it be the agency they picked. In our experience the real culprit is usually a brief that passed along what the client wanted on the surface and left out the logic underneath it.
So here's what a brief has to carry if you want a dev team to build the right thing.
Start with what the business does, not what the software should do
"I need a dashboard that shows X" is a brief that has already made decisions without the developer in the room. Before you list features, describe the operation. What does the business do all day? Who does each part? In what order?
A developer builds software to serve an operation. If they don't understand the operation, you'll get something technically correct and practically useless. We've inherited a few of those.
Describe users by what they do, not who they are
"Admin users" and "regular users" tell a developer almost nothing. Describe people by the work they do instead:
- The warehouse manager who receives stock, assigns it to locations, and reconciles weekly
- The sales rep who creates quotes, follows up on open ones, and marks them won or lost
- The accounts team who runs month-end and needs every transaction exportable to Tally
Written this way, it's immediately clear what each person needs to see and do. It also exposes the "simple feature" that isn't simple at all, because three roles each handle it a little differently.
Document the exceptions, not just the happy path
Every process has a happy path, where everything goes to plan. Most briefs stop there. Real operations don't. They run on exceptions: the return that arrives damaged, the client who pays in two instalments, the order shipping to an address that isn't on the invoice.
Write down every exception you can think of, and what should happen in each case. It's tedious. Do it anyway. The edge cases are exactly where software either earns its fee or creates a mess.
Briefs that list the exceptions produce software that survives contact with real customers.
Be explicit about what connects to what
Most businesses run on several systems at once: accounts, CRM, inventory, logistics, WhatsApp. Name every integration in the brief and describe what data has to move between them. Should orders from the new system land in Tally on their own? Should a status change send a WhatsApp message? Is the dashboard meant to read from a Google Sheet someone updates by hand every evening?
Each integration is real work. If it isn't in the brief, it isn't in the estimate, and it'll turn up mid-project as scope creep that surprises everyone.
State what you are not building
Scope is defined as much by what's left out. Write down plainly what this version won't do. It stops the very human urge to add "just one more thing" halfway through, keeps the timeline honest, and hands you a ready-made list for version 2.
We're happy to help you shape a brief before anything is built. Sometimes that ends up being the most useful conversation of the whole project. You can also download our free Software Brief Template and come to the first call prepared. Start here.