FROM THE BENCH · GUIDE NO. 29 · 2026-05-05

How to write a dev brief in 30 minutes.

A good brief is not a 40-page spec. It is five answered questions that give a developer enough context to price, plan, and push back accurately. Here is the 30-minute version.

Why most briefs fail.

Founders spend weeks on feature lists and wireframes and skip the three things developers actually need: who uses this, what success looks like in measurable terms, and what is explicitly out of scope. Without those three answers, every quote you receive will be padded with risk buffer and every timeline will be optimistic.

A brief that answers the five questions below will get you more accurate quotes, faster turnaround from agencies, and fewer scope disputes mid-project. Write it in 30 minutes. Refine it over 48 hours. Ship it.

The five questions. Answer each one.

01

What are you building and why does it need to exist?

One paragraph. What problem does it solve? For whom? Why now? Avoid feature lists here — explain the underlying need.

EXAMPLE

We are building a B2B SaaS tool that helps operations managers at logistics companies track driver compliance in real time. Current solutions require manual CSV exports and take 3–4 hours per week. We want to automate that to under 10 minutes.

02

Who is the primary user and what do they need to do?

Describe one specific user type. What is their goal? What do they currently do instead? How technical are they?

EXAMPLE

Primary user: operations manager, 35–55 years old, not technical, uses Excel daily. They need to see compliance status across their fleet without leaving a single dashboard.

03

What does done look like?

Define the minimum set of features that constitutes a launchable product. Use user stories: 'A user can [action].' List no more than 8–10.

EXAMPLE

A manager can log in. A manager can see all drivers and their compliance status on one screen. A manager can export a compliance report as PDF. A manager can set alert thresholds for compliance percentage.

04

What is explicitly out of scope?

List everything you are NOT building in v1. This is as important as what you are building. It prevents scope creep and helps developers price accurately.

EXAMPLE

Not in scope: mobile app, driver-facing features, payroll integration, custom reporting, multi-tenant white-labelling, offline mode.

05

What are your constraints?

Budget range (even approximate), timeline expectations, existing tech stack or integrations required, compliance requirements, team availability for reviews.

EXAMPLE

Budget: $40k–$60k. Timeline: launch within 4 months. Must integrate with our existing Salesforce instance. No HIPAA requirements. I am available for weekly reviews but not daily.

What to include beyond the five questions.

INSPIRATION

Links to 2–3 products you admire the UX of. This calibrates aesthetic expectations more accurately than any description.

INTEGRATIONS

Every external service the product must connect to. Stripe, Salesforce, Zapier, a specific API. Each integration adds scope.

USERS AT LAUNCH

Realistic user volume for month 1–3. This affects infrastructure decisions and pricing significantly.

DECISION PROCESS

Who signs off on deliverables? Who is the primary point of contact? Developers price in communication overhead.

SKIP THE WRITING

Answer five questions in our tool and get a structured brief you can send directly to agencies.

USE BRIEF IN 5
← ALL GUIDES