Most founders treat the brief like an essay. They think more is more. So they send a 30-page RFP with detailed wireframes and a tech stack and a security appendix. The senior developers stop reading at page three and decline. The junior ones eyeball it, add 30% padding for "things they're missing," and quote.
The brief that actually works is two pages. Here's the structure I've seen win the cleanest quotes from the best developers, hundreds of times now.
Page one: the problem
Five short sections. No wireframes. No tech stack. No project plan.
Who it's for
One paragraph naming the user, what they currently do, and where the pain is. Not "small businesses", "warehouse managers at fulfilment centres in Western Sydney who currently track inventory in three separate Excel files."
What we're building
One paragraph describing the product in plain language. "A mobile-first web app that replaces the three Excel files with a live inventory view, lets staff scan barcodes from their phones, and emails the warehouse manager when stock dips below thresholds."
Why now
One short paragraph on what's triggering this. "We just signed a contract that triples our throughput in November. We need this live by October."
What success looks like
Three bullets, no more. "1. Warehouse staff can scan and track stock in under 10 seconds per item. 2. Manager has a real-time dashboard. 3. Re-order alerts replace the current manual stock-take."
What's not in scope
This is the section founders skip and developers love. "We don't need: customer-facing pages, integration with our ERP, multi-warehouse support. Those are version two."
Page two: the practical
Five more short sections.
Screens or flows
A flat list with one sentence each. "Login. Inventory list (sortable, searchable). Item detail. Scan-to-update. Manager dashboard. Settings." That's six lines and it tells a senior developer the size of the build immediately.
Integrations
List every external system you need to talk to. "Xero for invoice generation. Twilio for SMS alerts. Our existing Cognito user pool." If you don't know, write "none confirmed yet."
Data and volume
"Around 8,000 SKUs. 12 staff. Peak load is 200 scans/minute during morning intake."
Constraints
Hosting preferences, languages your team already knows, regulatory needs. "Must run on our existing AWS account. Our internal team is comfortable with Node and React."
Budget and timeline
The single most contentious section, and the one founders skip most often. Always include it.
"We don't want to anchor the developer" is the most expensive mistake in software hiring. You're not anchoring them, you're saving everyone a fortnight of wasted scoping calls.
State a target and a ceiling: "Target $25k. Hard ceiling $40k. Need it live by November 15."
What to leave out
- The tech stack. Unless you have a real constraint, let the developer pick. Anything else suggests you don't trust them, which is a bad start.
- Wireframes. They anchor the build to a design that probably isn't right. Trust the developer to design a flow with you.
- Detailed acceptance criteria. Save them for the SOW after you've hired.
- Background paragraphs about your company history. Two sentences max.
What gets you the cleanest quote
The brief that wins is the one that lets a senior developer reply with: "I've read this in fifteen minutes. I have three clarifying questions. If those answers go the way I expect, the price is X and the timeline is Y."
That's it. If your brief produces that response, you've done your job. If it produces "we'd love to schedule a discovery workshop to scope this properly," you've underspecified, and you'll either pay for the workshop or get a padded quote.
The bottom line
Two pages. Five sections per page. Always state the budget. Skip the wireframes and tech stack.
If you don't want to write a brief at all, FindDevs does the brief writing for you, we translate a two-minute conversation into a developer-ready spec, then send it to three vetted Australians for quotes. Free.