How to Brief a Software Agency When You're Not Technical
You don't need to know code to write a great software brief. You need to describe the problem, the people, and the workflow clearly. Here's what to include, with a ready-to-use outline.
Product Strategyproject-briefnon-technical-founderprdoutsourcingproduct-planning3 min read·· Updated
Many founders delay contacting development agencies because they feel they need to "speak tech" first. They don't. The best briefs we receive rarely mention a programming language. They describe a business problem so clearly that the technical decisions almost make themselves.
A clear brief gets you more accurate quotes, fewer surprises, and a better product. Here's what to put in it.
The 10 things every brief should include
1. The problem, in one paragraph
What's broken or missing today, and who feels the pain? "Our dispatchers spend 3 hours a day taking bookings by phone and we lose orders after 7pm" is far more useful than "we need a logistics app."
2. Who will use it
List each type of user (customers, staff, managers, drivers, admins) and what each needs to do. These become the system's roles and permissions.
3. The main workflow, as a story
Walk through the most important journey step by step: "A customer requests a quote, the manager approves it, the customer pays, a technician is assigned…" Numbered steps are perfect. No diagrams required.
4. How it works today
Share screenshots of the spreadsheets, forms, and tools you currently use. They reveal the real data and edge cases faster than any meeting.
5. Must-haves vs nice-to-haves
Split features into "can't launch without" and "later." This one step can cut an estimate dramatically. Our guides to MVP features and what to build first help you draw the line.
6. Platforms
Web, iPhone, Android, or all three? Who uses which? Field staff usually need mobile; office teams usually need web.
7. Connections to other tools
Payments, accounting software, SMS or WhatsApp, maps, calendars, your existing CRM. Each integration affects cost, so list them all.
8. Volume and scale
Roughly how many users, orders, or records per month, today and in a year? Ballpark figures are fine.
9. Budget range and timeline
Sharing a range isn't giving away your negotiating position. It lets an agency propose the best solution within it rather than guessing. Include any hard deadlines, like a trade show or a season.
10. How you'll measure success
"Cut booking time in half," "handle 500 orders a day without extra staff." A clear goal keeps every later decision honest.
What you can leave out
The tech stack. Let the agency recommend it and explain why. (If you're curious, here's how we think about tech stacks.)
Pixel-perfect designs. Rough sketches or apps you like are enough.
Database structure. Describe the information you need to store; the structure is the agency's job.
A copy-ready brief outline
Company and one-line description
The problem and who has it
Users and what each needs to do
Main workflow, step by step
Current tools (with screenshots)
Must-have features / later features
Platforms
Integrations
Expected volume
Budget range and timeline
Success metrics
Apps or sites you like, and why
From brief to PRD
A brief gets the conversation started. A good agency will turn it into a detailed product requirements document (PRD) with you, covering every screen, rule, and edge case, before development starts. That PRD is what makes a fixed quote reliable.
When the brief is ready, use these 12 questions to vet agencies, and understand the pricing models they'll offer.
Have a rough idea but no brief yet? Send us what you have, even a few bullet points. As a custom software development partner, we'll help shape it into a clear scope and estimate. Start the conversation.
