When a software project runs over budget or delivers the wrong thing, most clients blame the developer. Most developers blame unclear requirements. Both are usually right.
A developer can only build what they understand. If the brief says "we need a dashboard," the developer builds a dashboard — and it will not be the one you imagined, because "dashboard" means something different to every person who says it.
The brief is where shared understanding is established. Get it right and the project runs. Get it wrong and you spend the budget negotiating scope.
What a useful brief contains
A brief that developers can actually build from has five sections.
1. Context
One paragraph. Who is the company? What problem does this project solve? Who is the end user and how technical are they? Why does this need to exist now?
This sounds obvious. Most briefs skip it entirely. The context determines which trade-offs matter: a brief for an internal tool used by ten staff has different priorities than a consumer app serving ten thousand users. A developer without context cannot make good architecture decisions.
2. Scope — what to build
A list of every feature required for the first version. Not the full roadmap — the first version.
Write each feature as a user action: "A user can log in with email and password." "An admin can export all orders as a CSV file." "A customer can track the status of their delivery." Specific. Unambiguous. Testable — you either can or cannot perform the action.
Feature lists written as nouns ("user management", "reporting module", "dashboard") are ambiguous and will produce disagreements at delivery. Feature lists written as actions are buildable and verifiable.
Separate must-have from nice-to-have. The must-have list is your version one. Everything else is version two.
3. Out of scope
Equally important as the scope list. Write down explicitly what this project does not include.
"This phase does not include a mobile app." "This does not include integration with the legacy ERP." "This does not include multilingual support."
Out-of-scope items prevent scope creep. When a developer asks "should we also handle X?", you point to this list. X is not in scope, and therefore not in the budget.
4. Technical constraints
- Are there existing systems this must connect to? (Which CRM, payment gateway, database?)
- Is there an existing codebase, or is this a new build?
- Are there technology preferences? (Your team already uses Next.js. Your CTO insists on AWS.)
- Are there compliance requirements? (GDPR data residency, HIPAA, SOC 2, PCI DSS)
- What are the performance expectations? (100 concurrent users or 100,000?)
Developers make architecture decisions based on constraints. Missing constraints produce systems that do not fit your actual situation — discovered at integration or launch, not before.
5. Success criteria
How will you know if the project succeeded? Write down three to five observable outcomes.
"A new staff member can use the system without training after 30 minutes."
"The system processes 1,000 orders per day without manual intervention."
"Onboarding a new client takes under 20 minutes, down from three hours."
Success criteria become the acceptance criteria for the delivered work. They protect both parties from the subjective judgment call of "is this done?"
The questions developers will ask — answer them in the brief
Good developers ask clarifying questions before writing code. Save time by pre-empting them.
Who are the users and how many? A tool for 5 internal staff is architected differently from a platform expecting 5,000 external users.
Are there multiple user types? Admin, customer, supplier, viewer — each role that sees or does something different adds complexity. Define all roles and what each can access.
What does the data model look like? Even a rough description helps: "a customer has many orders, each order has many line items, each line item references a product." This tells a developer more than a paragraph of prose.
What are the critical edge cases? What happens when a payment fails? When two people edit the same record simultaneously? When a user tries to do something they are not allowed to do? Thinking through failure modes before development starts prevents expensive rework.
What does launch-ready look like? If you deployed today, what would you demo to a stakeholder to call it done? That answer defines the minimum viable scope.
Common brief mistakes
"I'll know it when I see it." This is not a brief. It is an invitation for an expensive discovery process funded at your hourly rate. If you genuinely do not know what you want, hire a product consultant to help you define it — before you hire anyone to build it.
Writing the technical solution instead of the problem. "We need a React dashboard with a PostgreSQL backend and a REST API." This specifies the implementation before the requirement. Write what the system needs to do, not how it should be built. Let the developer propose the architecture.
Listing forty features for version one. Every feature is a multiplier on cost and timeline. A forty-feature brief is almost always a wishlist, not a requirement. Force a prioritisation exercise: what are the five things without which this product is useless?
No design references. Screenshots of apps with the right feel, competitors, or products you admire tell developers more than paragraphs of written description. "Something like this, but for our industry" is a legitimate input that saves hours of back-and-forth.
A one-page brief — the minimum viable document
If you write nothing else, answer these five questions before talking to any developer:
- What is this product and who uses it?
- What are the five features it must have on launch day?
- What does it explicitly not include?
- What existing systems does it need to connect to?
- How will we know when it is done?
One page. One afternoon to write. More valuable than a forty-page specification document that nobody reads in full and that will be out of date by month two.
Once you have a brief, our team can turn it into a fixed-price proposal within 48 hours. Use the estimate tool or send the brief directly.