You've decided you need custom software. Now you need to explain what you want to developers. The quality of that explanation directly affects what you get back: accurate estimates, relevant questions, and ultimately, software that solves your problem.
Here's how to write a project brief that actually helps—no technical knowledge required.
Why This Matters
A good brief:
- Gets you accurate estimates (not wild guesses)
- Attracts the right developers (ones who understand your problem)
- Reduces back-and-forth (saving everyone time)
- Prevents scope creep (clear boundaries from the start)
A vague brief gets you vague estimates and misaligned expectations. Garbage in, garbage out.
The Essential Elements
1. The Problem (Not the Solution)
Start with what's broken, not what you want built.
Bad: "I need a customer portal with login, dashboard, and file upload."
Good: "Our customers constantly email us asking for project status updates. We're spending 5+ hours per week answering the same questions. We need a way for customers to self-serve this information."
The second version tells developers why you need something. That context leads to better solutions—sometimes ones you wouldn't have thought of.
2. Who Will Use It
Different users have different needs. Be specific:
- Who are they? (Employees? Customers? Both?)
- How technical are they? (Will they need training?)
- How often will they use it? (Daily? Weekly? Once a month?)
- What devices? (Desktop only? Mobile essential?)
Example: "Used by our 12-person warehouse team on tablets while walking the floor. They're not technical—needs to be dead simple. Daily use, probably 20+ times per day."
3. What Success Looks Like
How will you know the project worked? Be concrete:
- "Customer support emails drop by 50%"
- "Inventory counts take 2 hours instead of 8"
- "New employees can start using it within 30 minutes"
- "Zero manual data entry between systems"
If you can't define success, you can't evaluate solutions.
4. What You've Tried
Developers learn a lot from your failed attempts:
- Off-the-shelf tools that didn't fit
- Spreadsheet solutions that broke down
- Previous custom attempts that went wrong
This prevents them from suggesting things you've already ruled out—and helps them understand why existing solutions don't work.
5. Constraints
Be upfront about limitations:
- Budget: Even a rough range helps ("under $20K" vs "we have $100K")
- Timeline: Hard deadlines vs. flexible timing
- Technical: Systems it must integrate with, security requirements
- Organizational: Approval processes, stakeholders who need buy-in
Constraints aren't obstacles—they're design parameters.
6. Must-Haves vs. Nice-to-Haves
Not everything is equally important. Separate:
Must-haves: The project fails without these Nice-to-haves: Would be great, but not essential Future considerations: Not for this phase, but keep in mind
This helps developers prioritize and suggests where to cut if budget/timeline gets tight.
A Simple Template
PROJECT BRIEF: [Name]
THE PROBLEM
What's broken? What pain does this cause?
[2-3 paragraphs]
USERS
Who will use this? How technical are they? What devices?
[Bullet points]
SUCCESS CRITERIA
How will we know this worked?
[3-5 measurable outcomes]
WHAT WE'VE TRIED
Tools/approaches that didn't work, and why
[Bullet points]
CONSTRAINTS
Budget range:
Timeline:
Technical requirements:
Other limitations:
REQUIREMENTS
Must-haves:
- [List]
Nice-to-haves:
- [List]
QUESTIONS/CONCERNS
Anything you're unsure about or worried about
[List]
What NOT to Include
Don't design the solution
"I need a button here that does X, then a dropdown that shows Y..."
Unless you're a UX designer, leave the interface design to the developers. Describe the outcome you need, not the buttons you imagine.
Don't write technical specs
"Use React with a PostgreSQL database and REST API..."
Unless you have strong technical reasons, let developers recommend the technology. Your job is to describe the problem; their job is to pick the right tools.
Don't pad with buzzwords
"Leveraging cutting-edge AI/ML to synergize workflow optimization..."
Plain language works better. If you can't explain it simply, you might not understand what you actually need.
The One-Page Test
If you can't fit your brief on one page, it's probably too long. Developers don't need a novel—they need enough context to ask smart questions and give useful estimates.
More detail can come later through conversation. The brief is a starting point, not a contract.
What Happens Next
A good brief starts a conversation, not ends one. Expect:
- Clarifying questions: Good developers will probe for details
- Alternative suggestions: "Have you considered..."
- Scope discussion: Breaking the project into phases
- Rough estimate: Ballpark cost and timeline
If a developer gives you a detailed estimate without asking questions, that's a red flag. Real projects require real discovery.
Example: Before and After
Before (Vague)
"We need a CRM system. Something like Salesforce but customized for our business. Should track leads, contacts, deals, and have reporting."
After (Useful)
"We're a 15-person roofing company. Currently tracking leads in a shared spreadsheet, but it's chaos—duplicates, lost follow-ups, no visibility into our pipeline.
We need to track leads from first contact through completed job. Key info: contact details, property address, job type, estimate amount, status, and notes from each interaction.
Our 4 salespeople need mobile access (they're on-site constantly). Office manager needs reporting on pipeline value and close rates.
We tried HubSpot and Jobber—too complex for our needs and too expensive per user.
Budget: $10-20K. Timeline: Want to pilot by Q2. Must integrate with QuickBooks for invoicing."
The second version gives developers everything they need to respond usefully.
Need Help?
Not sure how to describe your project? Sometimes a conversation is easier than writing. Let's talk—we can help you figure out what you actually need before you commit to anything.
Part of our series on making smart software decisions. See also: What Custom Software Costs and Questions to Ask Before Hiring.