How to write a software project brief: a template to fill in before you ask for quotes

What is a software project brief, and how does it differ from a proposal and a SOW?

A software project brief is the document you write before you ask anyone for a quote. It says what problem you have, for whom, how you will know it is solved, what you already have, what you do not yet know and what you want back in the reply. It is not a feature list and it is not a specification. The proposal and the scope of work (SOW) are what the supplier writes in return, so the brief is the one document in the chain that only you can write well.

This guide covers the first row. How to read what comes back, including a scope-of-work template, is in how to read a software proposal. Whether the work is a custom software project or a mobile app, the brief has the same ten headings; the mobile-only decisions are in their own section below.

The ten headings of a software project brief

Write one or two sentences under each heading. If you can only write five, write 1, 2, 3, 5 and 10: they do most of the work.

1. The problem and who has it. What goes wrong today, for whom, in which situations? "We need an app" is not a problem.
2. Users and the first use case. Who opens it first, at what moment, to do what? Other users can follow.
3. How you will know it worked. One to three observable outcomes, written so that a stranger could check them. Not a list of features.
4. What exists today. The current process, the spreadsheets, the systems, screenshots, earlier code if any.
5. What you know and what you do not. Two lists: decided, and open. Write "we do not know" instead of guessing; a guess hidden in a brief becomes a fixed assumption in a quote.
6. Constraints. Platforms, integrations, the data involved, languages, regulation, accessibility, the security bar and any deadline together with its reason.
7. Accounts and assets you already hold. Domain, cloud, store accounts, brand files, data, and in whose name each one is.
8. Limits of time and money. What is fixed (an event, a funding date) and what can move. If you are willing to state a range, state it; if not, say so.
9. How the decision will be made. Who decides, who answers questions, and the criteria you will compare proposals on.
10. What you want back. The headings you expect in the reply: assumptions, what is out of scope, questions, how a change is handled, whose name each account would be in.

The order is deliberate. Headings 1 to 3 describe the outcome and let a supplier propose a way to reach it; headings 4 to 7 describe the ground; headings 8 to 10 describe how you will choose. A brief that starts with screens and modules gives the supplier nothing to improve.

Weak line, strong line

The table shows how a common line in a brief can be rewritten so that it can actually be quoted. The strong versions are examples to adapt, not text to copy.

How to write "it worked" into the brief

Heading 3 is the hardest and the most useful. Two ideas from the practice of software teams help. The Scrum Guide says a Product Goal "describes a future state of the product which can serve as a target for the Scrum Team to plan against", and it defines the Definition of Done as "a formal description of the state of the Increment when it meets the quality measures" (Scrum Guide, November 2020). You do not need to run Scrum to borrow the idea: one sentence for what you are aiming at, and a short list of conditions that must hold before you call a piece of work finished.

Joel Spolsky, writing about functional specifications, gives reasons that apply equally to a brief: "The most important function of a spec is to design the program", and "When you write a spec, you only have to communicate how the program is supposed to work once" (Spolsky). Writing the brief is the first moment you are forced to decide things; better then than in the middle of the build.

Three examples of observable criteria, written without numbers:

• "A user who forgets the password can regain access without contacting us."
• "A booking made at the same moment by two people for the same slot is confirmed for one of them, and the other is told."
• "Staff can find yesterday's orders from the list without asking the developer for an export."

If a criterion cannot be checked by someone who did not write it, it is not yet a criterion. How the agreed criteria become acceptance clauses is in item 4 of the SOW template in our proposal guide.

If the project is a mobile app: decisions to put in the brief

A mobile app brings decisions that live outside the code and have their own lead time. Put the decision, not a guess, in the brief. The line items that these decisions create are in mobile app development cost; here the question is only what the brief must say.

Beyond the table, the brief should name who handles account setup and identity verification, who prepares the privacy text, who fixes and resubmits after a rejected review and who publishes later versions. Together with the question of whose name the developer account is in, these are the five questions on our mobile app development page. Store rules change; reopen the official pages before you act.

Requirements people forget: accessibility, security, data

These are easy to leave out because they do not look like features. A brief that names a baseline lets a supplier quote against it; a brief that says "accessible" or "secure" does not.

You do not need to know these standards in depth. Writing "we expect WCAG 2.2 level [your choice]" or "please state which security baseline you work to" is enough to start the conversation. Whether a law applies to you, and at what level, is a question for a lawyer.

A software project brief template you can copy

Copy the outline below, fill in the square brackets and send it to every supplier you are talking to, with a line asking them to answer the last heading.

The same template is also available as a printable PDF with room to write each answer, and as an editable Word file with the square brackets highlighted.

1. Problem and who has it. "Today [who] has to [what], which causes [consequence]. It happens [how often or in which situations]."
2. Users and the first use case. "The first user is [role]. They open it when [moment] to [task]. Other users: [roles]."
3. How we will know it worked. "We will consider it worked when [observable outcome 1] and [observable outcome 2]."
4. What exists today. "This is done today with [paper, spreadsheet, system]. We can share [documents, screenshots, access]."
5. What we know and what we do not. "Decided: [list]. Open or unknown: [list]. Please tell us which assumptions you are making."
6. Constraints. "Platforms: [web, iOS, Android, other]. Must connect to: [systems]. Languages: [list]. Data and privacy: [what we collect, from whom]. Accessibility: [WCAG 2.2 level or 'not decided']. Security baseline: [your choice or 'please propose']. Regulation we know of: [list or 'not known']."
7. Accounts and assets we already hold. "[Domain, cloud, store accounts, brand files, data], in the name of [whom]."
8. Limits of time and money. "Fixed: [date and the reason]. Flexible: [what can move]. A spending limit we can state: [range or 'not stated']."
9. How we will decide. "[Role] decides; [role] answers your questions, usually within [your response time]. We will compare proposals on [criteria]."
10. What we want in your reply. "Your assumptions; what is out of scope; the questions you still have; how a change would be written and priced; in whose name each account would be opened; what we would hold at the end of the work."

Fill what you can in one sitting and leave the rest as "open". An honest "open" is more useful to a supplier than an invented answer. If the brief runs long, headings 1, 2, 3, 5 and 10 are the ones to protect.

Five common mistakes in a brief

1. Writing the solution before the problem. Screens and modules in the first paragraph leave a supplier nothing to improve. Start with heading 1.
2. Hiding what you do not know. A hidden guess becomes a fixed assumption in a quote, and a change request later. List the unknowns instead.
3. Mixing "must" and "nice to have". Mark each item in heading 3 and heading 6 as must, should or could. A supplier can only propose a sensible first piece of work if it knows which is which.
4. Leaving out what you already own. Accounts, data and brand files that exist today decide what has to be built and what does not; heading 7 is short and often decisive.
5. Several people writing different briefs in one document. If priorities conflict, name who decides in heading 9 before the brief goes out; otherwise the supplier receives the conflict and has to guess.

After you send it: reading the replies

The first thing to look at is the questions that come back. A supplier that asks about heading 5, the things you wrote as open, has read the brief; one that returns a price without a question has not. Look next for whether the proposal restates your outcome in its own words, lists its assumptions, says what is out of scope and answers the last heading. Send the same brief to every supplier so the answers can be set side by side; the red-flag list and the comparison table are in our proposal guide, and the quote comparison template is in mobile app development cost. Questions to put to the supplier itself, whatever the model, are in the outsourcing guide.

How we do it

Here we only repeat what we say on our site. It starts with a conversation: a quote request through the site, or a call. We ask what the product has to do, who it's for, and what a good outcome looks like, until both sides are describing the same thing. Nothing gets built before that picture is shared. Then we write it down: what's being built, in what order, and what it costs; you approve that before work starts. You do not need to prepare, because the first conversation is a real one, and a brief like this one only sharpens it. Every engagement is a paid project that starts with a written quote you approve, and scope, timeline and cost are in your hands in writing before anything is billed. The steps are on our Process page and the approach is on our mobile app development and custom software development pages. If you have a brief, or only an idea, tell us about your project.

Frequently asked questions

How long should a software project brief be?

Short enough to read in one sitting. The ten headings with one or two sentences each are usually enough to start a conversation; attach screenshots or documents for heading 4 rather than describing them. Length is not the measure: whether the outcome and the open questions are clear is.

Do I need technical knowledge to write one?

No. Headings 1 to 4 are about your business, your users and your current process, which only you know. For heading 6 you can write "please propose" next to platforms or security; the supplier's answer will tell you something about how it thinks.

Should I put my budget in the brief?

You do not have to state a number. What helps is saying what is fixed and what can move: a date set by an event, a limit set by funding. If you can give a range, a supplier can scope the work to fit it; if you cannot, write "not stated" and say what the budget depends on. A written proposal with scope, timeline and cost comes afterwards.

Can I send the same brief to several companies?

Yes, and it is a sound way to compare answers, because every reply responds to the same words. Ask each to answer the last heading, and read the replies against each other rather than against your expectations. The proposal guide covers the comparison.

What if I do not know the answers to most of the headings?

Write what you do know and mark the rest "open". If almost everything is open, the first piece of work is not a build but a short, scoped step that settles the questions; our MVP development page describes cutting a scope to one main flow and one thing to learn. A brief with honest open items is still a brief.

Sources

The pages below were opened and read on November 9, 2026. Store rules and standards change over time; reopen the official pages before you act.

• Apple: Program enrollment · App Store Review Guidelines (5.1.1, 4.2)
• Google Play Console Help: Requirements for new personal developer accounts · Google Play Console Help: Choose a developer account type · Data safety · Account deletion requirements
• W3C: Web Content Accessibility Guidelines (WCAG) 2.2, December 12, 2024 · OWASP Application Security Verification Standard 5.0.0, May 30, 2025 · OWASP Mobile Application Security Verification Standard
• The Scrum Guide, November 2020 · Joel Spolsky, Painless Functional Specifications, Part 1: Why Bother?, October 2, 2000

Nothing here is legal advice; ask a lawyer about any law or contract term that applies to you.