How to Write a Software Project Brief (With a Template)

Most inaccurate quotes come from inaccurate briefs. If you send a developer two sentences, you will get a guess. If you send forty pages, nobody will read them carefully. One or two pages, covering the right things, is what gets you an estimate you can rely on.

This article explains what belongs in a brief and ends with a template you can copy.

What a brief is for

A brief answers three questions for the people who will build your product:

1. What problem are we solving, and for whom?
2. What does the first version need to do?
3. What are the constraints?

It is a starting point for a conversation. It does not need to specify screens, database tables or technology.

What to include

The problem and the users

Describe who will use the product and what they are trying to get done. Be specific. "Clinic receptionists who book around sixty appointments a day by phone" tells a developer far more than "healthcare users".

The three to five things users must be able to do

List the core actions. Write them from the user's side:

• A receptionist can see all free slots for a doctor in one view
• A patient receives a text reminder the day before
• A doctor can block out time off

If your list has more than five items, you are describing the second version as well. Move the rest to a "later" list.

What already exists

Mention anything the new product has to work with: an existing website, a database, accounting software, a payment provider. Integrations are a common source of surprises, so name them early.

Constraints

• Deadline: a real date and the reason for it, such as a trade show or a contract start
• Budget: a range is enough, and it helps the developer propose a realistic scope
• Compliance: data protection rules, industry regulations, accessibility requirements
• Platforms: web, iOS, Android, or a combination

How you will judge success

One or two measurable outcomes. "Receptionists book an appointment in under a minute" gives the team something to design toward.

Who decides

Name the person who approves scope and designs. Projects slow down when nobody is sure who can say yes.

What to leave out

• Technology choices, unless you have a reason. If your team knows a particular stack, say so. Otherwise let the developer recommend one.
• Screen-by-screen descriptions. They take a long time to write and usually change after the first design review.
• Every feature you have ever thought of. Keep a separate list for later.

Should you share your budget?

Yes. Some people worry that a stated budget becomes the price. In practice, withholding it costs you more time. The same product can be built as a six-week first version or a six-month platform, and the developer has to guess which one you want. A range lets them propose the best scope for the money.

Common mistakes

1. Describing the solution and leaving out the problem. "We need an app with a chat feature" hides the reason. If the goal is faster support replies, there may be a simpler answer.
2. No priorities. When everything is required, the estimate covers everything.
3. Forgetting the people who run it. Someone has to manage users, fix data and answer support requests. Say who, and what they need.
4. Leaving out content and data. If existing records need to be imported, mention how many and in what format.

The template

Copy this and fill it in. One or two pages is the right length.

PROJECT BRIEF

1. Summary
   One paragraph: what the product is and who it is for.

2. The problem
   What is difficult or slow today? How is it handled now?

3. Users
   Who will use it? Roughly how many? How technical are they?

4. Must-have features (3 to 5)
   -
   -
   -

5. Later features
   -
   -

6. Existing systems and integrations
   Software, data or services this must connect to.

7. Platforms
   Web / iOS / Android

8. Constraints
   Deadline and the reason for it:
   Budget range:
   Compliance or security requirements:

9. Success measures
   How will we know the first version works?

10. Decision maker and contact
    Who approves scope and designs?

What happens after you send it

A good developer will reply with questions before giving a price. Expect to be asked about edge cases, the systems you need to connect to and which features could wait. The estimate that follows should be broken down by feature, so you can see what each part costs.

We explain how estimates are built in how much it costs to build a custom web app.

If you have a brief ready, send it to us and we will reply with questions and a written estimate. You can also read about our approach to custom web app development.