How to Write a Software Brief a Developer Can Quote From

By Tate · Last updated October 6, 2026 · 10 minute read

A fill-in template for a two-page brief, covering the eight things a developer needs before they can give you a real price.

On this page

Written for: Anyone about to ask a developer for a quote
Level: Beginner
Format: Guide
Series: Getting software built

A developer can only price what they understand. When a request is vague, the developer has two choices. They can guess high to cover what they do not know, or they can guess low and come back for more money later. You pay for the missing detail either way.

A brief fixes that. It is a short document, two pages at most, that describes the job in your words. You do not need technical vocabulary to write one. You need to answer eight plain questions about your own business.

This guide explains each of the eight, gives you a template to copy, and shows a filled-in example.

What a brief is for

A brief does three jobs.

It lets a developer quote. The price depends on how many things the software has to do, what it has to connect to, and how much is unknown. A brief answers all three.
It lets you compare quotes. If three developers read the same page, their prices describe the same work. Without a brief, each one is pricing a different thing they imagined.
It makes you decide. Writing down what is out of scope is uncomfortable. It is much cheaper to feel that discomfort on paper than in the middle of a build.

A brief is a starting point for a conversation. A good developer will read it and come back with questions, and some of those questions will change it. That is the brief working as intended.

The eight things a developer needs to know

1. Who uses it

Name the people by role and say how many there are. “Two office staff at desks, six technicians on phones in the field” is a complete answer. The number of kinds of user matters more than the headcount, because each kind needs its own screens and its own permissions.

2. The one job

Finish this sentence: “When this exists, [person] will be able to [do what] without [the current pain].” If you need the word “and” more than once, you have more than one job. Pick the first.

3. How it works today

Describe the current process step by step, including the paper, the spreadsheets and the phone calls. This is the most useful section in the whole brief and the one most often skipped. The current process shows a developer the rules your business already follows that nobody has written down.

4. The data

List what information the software handles, where it lives now and roughly how much of it there is. Customer names in a spreadsheet, job photos on phones, prices in someone’s head. Say whether any of it is sensitive, such as payment details, health information or anything about children. Sensitive data changes what has to be built around it.

5. What it connects to

List every other tool the software has to read from or write to: your accounting package, your calendar, your email, a payment processor, a supplier’s website. For each one, say what you pay for and which plan you are on if you know. Whether a tool allows outside software to connect often depends on the plan.

6. What it must do

List the things the first version has to do, as plain sentences that start with a person. “The office can see every open job on one screen.” “A technician can mark a job finished from their phone.” Aim for five to ten. If you have thirty, you are describing version three.

7. What is out

List what the first version will not do, including the things you want later. This section protects your budget more than any other. “No customer login in version one” removes weeks of work with one sentence.

8. Limits

Write down any fixed date and the reason behind it, a budget range if you have one, and anything the software has to fit around, such as an old computer in the workshop or a rule from your industry. You are free to keep your budget private. Sharing a range lets a developer tell you what fits inside it, which is more useful than a quote you can’t afford.

The template

Copy this into any document and replace the bracketed lines. Short answers are fine. “I don’t know” is an acceptable answer and a useful one, because it shows a developer where the open questions are.

SOFTWARE BRIEF
Project name: [a working name, anything]
Written by:   [your name and role]
Date:         [today]

1. WHO USES IT
   [Role]: [how many people], [where they work], [what device]
   [Role]: [how many people], [where they work], [what device]

2. THE ONE JOB
   When this exists, [who] will be able to [do what]
   without [the current pain].

3. HOW IT WORKS TODAY
   Step 1: [what happens first, and who does it]
   Step 2: [...]
   Step 3: [...]
   Where it goes wrong: [the mistake, delay or cost]
   How often that happens: [your honest estimate, or "not sure"]

4. THE DATA
   What information: [customers, orders, photos, prices, ...]
   Where it lives now: [spreadsheet, paper, another program]
   How much: [about how many records, and how fast it grows]
   Sensitive: [payment, health, children, none, not sure]

5. WHAT IT CONNECTS TO
   [Tool name]: [what should go in or come out], [your plan]
   [Tool name]: [what should go in or come out], [your plan]

6. WHAT IT MUST DO (version one)
   - [Person] can [action].
   - [Person] can [action].
   - [Person] can [action].

7. WHAT IS OUT (for now)
   - [Feature you want later]
   - [Feature someone suggested that you do not need]

8. LIMITS
   Date: [a fixed date and why, or "no fixed date"]
   Budget: [a range, or "prefer to discuss"]
   Must fit around: [old hardware, industry rule, existing habit]

9. WHAT I ALREADY TRIED
   [Product or approach]: [why it did not work]

10. HOW I WILL KNOW IT WORKED
   [One thing you can count or observe three months after launch]

Sections 9 and 10 go beyond the eight. They take two minutes each, and they answer the two questions a careful developer will ask first.

A filled-in example

This example is hypothetical. The business and its numbers are invented to show the level of detail that works.

SOFTWARE BRIEF
Project name: Job board
Written by:   Owner, a heating and cooling company
Date:         October 2026

1. WHO USES IT
   Office staff: 2 people, at desks, Windows computers
   Technicians: 6 people, in trucks, their own phones

2. THE ONE JOB
   When this exists, the office will be able to see where
   every job stands without phoning each technician.

3. HOW IT WORKS TODAY
   Step 1: A customer calls. The office writes the job on a
           whiteboard and in a shared spreadsheet.
   Step 2: The office texts the job to a technician.
   Step 3: The technician texts back when it is finished.
   Step 4: The office updates the spreadsheet and the board.
   Where it goes wrong: finished jobs stay on the board for
           hours, so the office books over them or calls to check.
   How often that happens: several times a day

4. THE DATA
   What information: customer name, address, phone, job notes
   Where it lives now: one shared spreadsheet
   How much: about 30 new jobs a week
   Sensitive: none. No payment details are stored.

5. WHAT IT CONNECTS TO
   Accounting package: finished jobs should appear there
           ready to invoice. Plan: not sure.

6. WHAT IT MUST DO (version one)
   - The office can add a job and assign it to a technician.
   - A technician can see their jobs for the day on a phone.
   - A technician can mark a job started and finished.
   - The office can see every open job on one screen.

7. WHAT IS OUT (for now)
   - Customer login
   - Route planning
   - Taking payment in the field

8. LIMITS
   Date: before the winter rush would be ideal. Not fixed.
   Budget: prefer to discuss
   Must fit around: technicians will not install an app
           that needs a work email address.

9. WHAT I ALREADY TRIED
   A field service product: it did far more than we need
           and the technicians stopped using it.

10. HOW I WILL KNOW IT WORKED
   The office stops calling technicians to ask if a job is done.

Notice what the example leaves out. It names no programming language, no database and no screen layout. It also contains one line a developer will care about a great deal: the technicians will not install anything that needs a work email. That single limit shapes how login has to work, and it would have been expensive to discover after the build started.

Lines that can’t be quoted, and how to fix them

The left column is how requests often arrive. The right column says the same thing in a way that can be priced.

Hard to quote	Easy to quote
”It should be easy to use."	"A technician can mark a job finished in two taps, with gloves on."
"We need reports."	"Each Monday the owner sees the jobs finished last week, by technician."
"It should work with our accounting."	"A finished job creates a draft invoice in our accounting package."
"It needs to be secure."	"Technicians see only their own jobs. Only the owner can delete a job."
"It should use AI."	"It drafts a reply to a customer email and a person approves it before it sends."
"It needs to scale."	"We have 8 users today and expect about 20 within two years."
"Like the big app everyone uses, but for us."	"Customers pick a time slot and get a confirmation by text.”

The pattern is the same in every row. Replace the quality you want with a specific person doing a specific thing.

What to leave out

Technology choices. Unless you have a real constraint, such as an IT department that only supports one platform, leave the tools to the developer.
Screen designs. A rough sketch on paper helps. A finished mockup tends to lock in decisions before anyone has checked whether they can be built.
Every feature you can think of. Put the extras in section 7 so they are recorded and out of the first price.
Your company history. One sentence about what the business does is enough.

Before you send it

The brief is two pages or less.
Section 2 contains one job.
Section 3 describes what happens today, step by step.
Every line in section 6 starts with a person.
Section 7 has at least two things in it.
Anything you are unsure about says “not sure” in place of a guess.
Someone who does the actual work has read it and agreed that it is accurate.

That last check matters. The person who does the job every day knows steps that the owner has forgotten.

What happens after you send it

Expect questions. A developer who replies to a brief with a price and no questions either has a very standard product to sell you or did not read it closely.

If you want the brief pressure-tested before you take it to anyone, bring it to a consulting session. I read it beforehand, we go through it piece by piece, and you leave with a written verdict on whether it can be built and a roadmap of how I would build it. If you want me to quote the build, custom software explains how that works.

If you are still deciding whether to build at all, start with the first guide in this series, How to Get Custom Software Built When You Are Not Technical. When the brief is written, the next step is checking whether the idea is feasible.