How to write a software project brief: template and mistakes

A website or software project brief is a short document that explains to a vendor what your company needs and why. It does not need to be technical. It needs to answer a few questions clearly: what problem the project solves, for whom, what is essential, which systems it must talk to, when it needs to be ready and who makes the decisions.

A good brief covers nine points: business goal, audience, current problem, essential and nice-to-have features, integrations, references, constraints, target deadline and decision maker. With that, a vendor can estimate effort, point out risks and suggest approaches. Without it, every proposal interprets the request differently, and comparing them becomes impossible.

One or two well-written pages are usually enough. The goal is not to specify every screen. It is to give enough context for the first conversation to be productive.

Why the brief changes the outcome of the project

The brief is the starting point for the budget, the schedule and the architecture decisions. When it is vague, the vendor has to guess. Some guess low, and the project grows through change orders. Others guess high, and the proposal looks too expensive.

It is also the document that aligns your own company. Writing a brief forces the departments involved to agree on the goal before any money is spent. It is common to discover at this stage that sales and operations expect different things from the same system.

Finally, it serves as a reference during the project. When someone asks "was this in the plan?", the brief and the proposal have the answer.

What a good brief includes

Business goal

Start with the expected result, not the solution. "We want a scheduling system" is a solution. "We want to reduce the time the front desk spends confirming appointments by phone" is a goal. A goal lets the vendor suggest alternatives, including simpler ones.

If you can, say how success will show up: fewer phone calls, more quote requests through the website, closing the month without side spreadsheets.

Audience

Who will use the website or software? End customers, internal staff, partners, all of them? Describe the profile: do they mostly use phones or computers, how comfortable are they with technology, do they work at the office or in the field? A system for field technicians with a poor signal has very different requirements from a dashboard used at a desk.

Current problem

Explain how things work today and what bothers you. Shared spreadsheets, rework, duplicated information, a website that brings in no leads, an old system nobody can change. Concrete examples help more than adjectives: "orders arrive over WhatsApp, get typed into a spreadsheet and then retyped into the ERP" says much more than "the process is inefficient".

Essential and nice-to-have features

Split them into two lists. Essential features are the ones without which the project does not meet its goal. Nice-to-haves are improvements that can come later. This split is one of the most useful tools for adjusting scope and budget, and it is the basis of an MVP, the lean first version of a product.

Describe features by what the user needs to do, not by the screen: "customers need to see their order status without calling us" instead of "an order status screen".

Integrations

List the systems the project needs to exchange data with: ERP, CRM, payment platform, WhatsApp, invoicing system (in Brazil, the one that issues the nota fiscal, the mandatory electronic invoice), spreadsheets. Give the name of each system and, if you know, whether it offers an API, the interface that lets two pieces of software talk to each other. The effort behind an integration varies a lot from one system to another, as the article on system integration with APIs explains.

References

Point to websites or systems you like and explain why: how the menu is organized, how easy sign-up is, the tone of the copy. References without an explanation can be misread. It is also worth saying what you do not want.

Constraints

Anything that limits the options: maximum budget or investment range, technologies your company already uses, security requirements, the need to host in a specific environment, industry rules. If the system will handle personal data, that is a relevant constraint too. In Brazil, it falls under the LGPD (Lei Geral de Proteção de Dados, Law No. 13,709/2018), the country's data protection law, similar in spirit to Europe's GDPR. Elsewhere, check the rules that apply in your country.

Sharing a budget range does not weaken your negotiating position. It lets the vendor propose what fits within it, instead of a solution you will never buy.

Target deadline

Say when it needs to go live and why. "Before the March campaign launch" is different from "as soon as possible". If there is a fixed date, the scope may need to shrink to fit it. If the deadline is flexible, say so as well.

Who decides

Identify who approves the scope, who signs off on deliveries and who answers day-to-day questions. Projects without a clear owner stall while waiting for approvals, or receive conflicting requests from different people.

A brief template you can copy

Copy the list below and fill in each item with a few sentences. If you cannot answer one, write "don't know". That is useful information too.

1. Company and context: what the company does, team size, where it operates.
2. Business goal: what result the project should produce and how success will show up.
3. Audience: who will use it, on which device, in what situation.
4. Current problem: how the process works today and what is not working.
5. Essential features: what the system or website must do from the first version.
6. Nice-to-have features: what would be good to have but can wait.
7. Integrations: systems that need to exchange data with the project, and whether they offer an API.
8. Content and data: who produces text and images, and whether data must be migrated from another system.
9. References: examples you like or dislike, and why.
10. Constraints: investment range, technology, security, personal data, industry rules.
11. Target deadline: the target date and what happens if it is missed.
12. Owners: who decides, who signs off on deliveries, who answers questions.
13. After launch: who will maintain it, whether there will be an internal team, what support you expect.

Common mistakes when writing a brief

• Describing the solution instead of the problem. Asking for "an app" when the need could be met by a web system or an automation. The article on custom software vs. off-the-shelf helps you weigh that choice.
• Marking everything as essential. If every feature is a priority, none is. The result is a project that costs more and takes longer than necessary.
• Leaving out integrations. Finding out halfway through that the system must talk to the ERP changes both the timeline and the cost.
• Forgetting content and data migration. Text, photos and legacy data have to come from somewhere, and organizing them takes work.
• Hiding the investment range. Proposals arrive at incompatible scales and everyone's time is wasted.
• Not defining who decides. Several people giving opinions with no one holding the final word delays every stage.
• Going into too much detail too early. Specifying every button before validating the goal locks the project in and makes better proposals harder.

What happens after the brief

With the brief in hand, the vendor should come back with questions. That is a good sign: it shows the document was read and that there is real interest in understanding the problem. Next come the scope proposal, the estimate of time and investment and, on larger projects, a discovery phase to detail workflows and rules before development starts.

For websites, the brief is also what makes it possible to compare quotes, the topic of the article on how much a website costs. PERVOX's solutions show the kinds of projects that start from this type of document.

Frequently asked questions

Do I need to know technical terms to write a brief?

No. The brief describes the business, the problem and what people need to do. Translating that into technical requirements is the vendor's job. If you know the names of the systems your company uses, that already helps a lot.

How long should a brief be?

One or two pages cover most cases. Covering the items in the template matters more than length, even if the answers are short. Additional details come up in later conversations.

Should I send the same brief to several vendors?

Yes. That is how you get comparable proposals. If one vendor asks a question that changes the understanding of the project, share the answer with the others.

What if I don't know exactly what I want yet?

Write what you know: the problem, the audience and the expected result. List the open questions. A discovery conversation exists precisely to turn a vague need into a concrete scope.

If your company has a project in mind, a simple brief is enough to get started. Get in touch and send whatever you have, even if it is incomplete, and we can talk about next steps. PERVOX works remotely and can run the project in English.