How to write a software project brief your development partner can act on

Why the brief matters more than the first meeting

The brief is the first real artefact of a software project. A good one lets a development partner understand the problem, ask sharper questions and give you an estimate grounded in reality. A thin one (“we need an app like X, how much?”) produces estimates that vary wildly between vendors, because each one is quietly filling the gaps with its own assumptions.

You do not need technical knowledge to write a useful brief. You need to be clear about the business problem, honest about what you do not yet know, and specific about the constraints you are working within. This guide walks through each section and ends with a template you can copy.

Start with the problem and the goal

Describe the situation before describing the solution. Partners can suggest better approaches when they understand what is going wrong today.

• What is the problem? For example: “Field staff record site visits on paper, and the office re-types them into a spreadsheet two or three days later.”
• Who feels it, and how? Lost time, errors, missed revenue, poor customer experience, compliance risk.
• What does success look like? Express it as a change in the business, not as a feature list: “Visit reports are available to the office the same day, with no re-typing.”
• Why now? A contract renewal, a regulatory date, a seasonal peak or a system being retired all affect priorities.

If you already have a solution in mind, include it, but label it as a proposal so the partner feels free to question it.

Describe the users

Software succeeds or fails with the people who use it. For each group, note:

• who they are (customers, staff, partners, administrators);
• roughly how many there are, now and in a year or two;
• what devices and conditions they work in (desktop in an office, phone on a site with poor signal, a shared tablet at a counter);
• languages they need;
• any accessibility needs.

On accessibility, it is worth saying whether you want to meet a recognised standard. The W3C’s Web Content Accessibility Guidelines (WCAG) 2.2 is a W3C Recommendation and defines three conformance levels: A, AA and AAA. Naming a target level in the brief removes ambiguity later.

Define the scope: must-haves versus nice-to-haves

Most budget and timeline problems start with scope that was never prioritised. List the capabilities you want and sort them honestly:

Writing down what is out of scope is as useful as listing what is in. It prevents the partner estimating for things you never intended to build, and it gives both sides a shared reference when new ideas appear mid-project.

Describe features as things people need to do (“a supervisor approves a report and the customer receives a PDF”), not as screens or technologies. That leaves room for the partner to propose the simplest way to deliver the outcome.

State your constraints

Constraints shape the design as much as features do. Include any that apply:

• Technology already in place: existing hosting, cloud accounts, identity systems, preferred languages or frameworks your internal team can support.
• Platforms: web only, Android, iOS, or a combination; minimum device or browser versions you must support.
• Hosting and data location: for example, a requirement to keep certain data in India or in a particular cloud region.
• Security policies: single sign-on, multi-factor authentication, penetration testing before launch, internal security reviews.
• Ownership: who will own the source code, accounts and infrastructure, and whether your team will take over maintenance later.
• Fixed dates: anything immovable, and why.

List integrations and data

Integrations are where hidden effort tends to live. For each system the new software must talk to, give:

• the system name and who manages it (internal team or vendor);
• what needs to flow, in which direction, and how often;
• whether documentation and test access are available;
• whether it is being replaced or upgraded soon.

Then describe the data:

• what exists today and where (spreadsheets, an old database, paper);
• whether it needs migrating, and how clean it is;
• the types of personal or sensitive data involved;
• how long data must be kept, and who may see it.

Note compliance and regulatory requirements

You do not need to interpret the law in a brief, but you should flag which regimes apply so the partner can plan for them. Examples include sector regulations (health, finance, education), payment-card handling, and data protection law.

In India, the Digital Personal Data Protection Act, 2023 was enacted on 11 August 2023, and the DPDP Rules, 2025 were notified on 14 November 2025 with an eighteen-month period for phased compliance, according to the Press Information Bureau. If your software collects personal data from people in India, say so in the brief, along with any other countries whose users you will serve.

If you are unsure what applies, write that down. It is a legitimate question for the discovery phase and for your own legal adviser.

Define how success will be measured

Pick a few measures you can check after launch, and note the current baseline if you know it:

• time taken for a key task, before and after;
• error or rework rates;
• adoption (how many of the intended users actively use it);
• customer-facing measures such as completed orders or support requests;
• operational measures such as uptime targets or page-load expectations.

Measures make trade-offs easier during the project, because each request can be tested against them.

Be open about budget and timeline

Many businesses hesitate to share a budget, fearing the estimate will simply expand to fill it. In practice a budget range helps both sides. The same goal can often be met at very different levels of polish, automation and scale, and the range tells the partner which of those to propose. Without it, you may receive proposals that are all valid but impossible to compare.

For timeline, separate:

• hard dates (a regulatory deadline, a launch event) from preferred dates;
• the date you need a first usable version from the date you need everything.

Say whether you would rather phase the work, starting with a smaller first release, if the full scope does not fit the range.

Name the decision-makers

Projects slow down when nobody is sure who can approve a design or accept a release. In the brief, list:

• the project owner who has day-to-day authority to make decisions;
• other stakeholders who must be consulted, and on what;
• who signs off budget and scope changes;
• how quickly you can usually turn round feedback and approvals.

Also mention who from your side will be available to answer questions, test early versions and provide content, and roughly how much of their time they can give.

Include what you already have

Attach anything that saves the partner from guessing: process descriptions, sample documents and reports, screenshots of current systems, brand guidelines, existing designs, data samples with personal details removed, and examples of products you like or dislike (with a note on why).

A copyable project brief template

# Project brief: [project name]

## 1. Background and problem
- Current situation:
- Who is affected and how:
- Why now:

## 2. Goals
- Business outcome we want:
- Proposed solution (if any, open to challenge):

## 3. Users
| User group | Approx. number | Devices / conditions | Languages | Accessibility needs |
|------------|----------------|----------------------|-----------|---------------------|
|            |                |                      |           |                     |
- Accessibility target (e.g. WCAG 2.2 level AA):

## 4. Scope
- Must have:
- Should have:
- Nice to have:
- Out of scope for this phase:

## 5. Constraints
- Existing technology / hosting:
- Platforms and minimum versions:
- Data location requirements:
- Security requirements:
- Ownership of code, accounts and infrastructure:
- Fixed dates and reasons:

## 6. Integrations
| System | Owner | Data exchanged | Direction / frequency | Docs and test access? |
|--------|-------|----------------|-----------------------|-----------------------|
|        |       |                |                       |                       |

## 7. Data
- Existing data and where it lives:
- Migration needed? Quality:
- Personal or sensitive data involved:
- Retention and access rules:

## 8. Compliance
- Laws, regulations or standards that may apply:
- Countries whose users we serve:
- Open questions for legal review:

## 9. Success measures
| Measure | Current baseline | Target |
|---------|------------------|--------|
|         |                  |        |

## 10. Budget and timeline
- Budget range:
- Hard deadlines:
- Preferred dates:
- Open to a phased approach? (yes / no)

## 11. People and decisions
- Project owner:
- Stakeholders to consult:
- Approves budget and scope changes:
- Typical turnaround for feedback:
- Our team's availability for testing and content:

## 12. Attachments
- 

## 13. What we don't know yet
- 

The last section is deliberate. Listing your open questions shows the partner where discovery work is needed, and makes it more likely that the estimates you receive will be honest about uncertainty rather than hiding it.

Sources

1. W3C: Web Content Accessibility Guidelines (WCAG) 2.2
2. Press Information Bureau: DPDP Rules, 2025 Notified (backgrounder, 17 November 2025)