How long should a software brief be?
One page. If it runs longer, the first release is probably too big.
Guide / Planning
One page: the problem, who has it, what it costs today, the systems and data involved, what done looks like, your constraints, and one owner. Leave out features and tech choices. Developers quote accurately from a problem, and guess from a feature list.
01
| Section | Answer this |
|---|---|
| Problem | What goes wrong today, in two sentences. |
| Users | Who does the work, and how many of them. |
| Cost | Hours, errors or revenue lost each month. Rough is fine. |
| Process | The steps today, exceptions included. |
| Systems | Every tool and file involved. Note which have APIs or exports. |
| Data | Where records live, how clean they are, who owns them. |
| Done | What changes when it works. A number if you have one. |
| Constraints | Budget range, deadline, compliance, hosting. |
| Owner | One person who answers questions and decides. |
02
Describe the problem. Let the developer propose the solution, then judge the proposal.
03
04
| Gap | What it costs |
|---|---|
| No owner | Questions wait days. The timeline slips. |
| Unknown data | Estimates pad for the worst case. |
| Missing exceptions | Scope grows mid-build. |
| No success measure | Nobody can say when it's finished. |
05
Send it before the first call. DeltaV uses a free 30-minute scoping call to fill the gaps, then returns a fixed scope and one price. Most builds ship in 2–6 weeks.
Questions
One page. If it runs longer, the first release is probably too big.
No. Describe the work, the tools and the cost. The developer handles the technical side. DeltaV needs one person who knows the workflow.
No. A brief states the problem and constraints. The spec, what gets built and how, comes out of scoping with the developer.