How to write a software project brief: template and filled-in example

A software project brief is a one-page document describing the business problem, the goal, the users, and the limits of the project precisely enough that several studios price the same job. You do not need to understand technology to write one: you describe the problem and the numbers you already have, not the solution. Every section below comes with a filled-in example — an electrical supplies wholesaler whose orders arrive by email. Swap the names and send it.

What a brief must contain for the offers to be comparable

A brief needs eleven sections: company context, the problem, a measurable goal, users and their path, MUST/SHOULD scope, exclusions, systems to integrate with, constraints, budget, the deadline and its reason, and the decision-maker. Each answers a question that will be asked anyway — the only variable is whether it comes before the quote or two weeks after signing, when changing scope costs real money.

If you would rather not start from a blank page, walk through the same eleven fields with us first.

Filled-in example: context, problem, goal, and users

The first four sections have one job: to show that the problem is countable.

• Company context. “Electrical supplies wholesaler, 18 employees, one warehouse location, 40 regular B2B customers (installers and smaller wholesalers), around 3,000 items in the catalogue.”
• The problem. “Orders arrive by email and by phone in any format. Two people in customer service retype them into the inventory system, roughly 3 hours a day in total. Mistyped item codes end in returns, and the customer cannot see stock levels or the status of their own order.”
• Measurable goal. “Within six months of launch, 80% of orders from regular customers should be created in the portal without customer service, and retyping time should drop below 30 minutes a day.”
• Users and their path. “Three roles: B2B customer (logs in, sees their own prices and stock, places an order, tracks status), customer service agent (approves unusual orders, handles exceptions), administrator (creates accounts, sets credit limits).”

Describe features with the user story template — “As a [role] I want [feature] so that [benefit]” — because one such sentence carries more than a bullet reading “individual price lists”.

Filled-in example: scope, exclusions, integrations, and constraints

These four sections decide the price, because they hold the unknowns a studio would otherwise cover with a buffer. Set priorities with MoSCoW (Must, Should, Could, Won’t have); a brief needs the first two plus a list of exclusions.

• MUST. “Customer login with an individual price list, a cart showing current stock, order history, an email notification when the status changes, an admin panel for creating accounts.”
• SHOULD. “Credit limits with a block when exceeded, templates for recurring orders, CSV export of order history.”
• Out of scope. “Mobile app, retail sales, online payments, language versions other than our own, migration of orders older than 24 months.”
• Systems to integrate with. “Our inventory and sales system, named with its exact version — the order has to be created in it automatically. We do not know whether our version exposes an API; please state how you intend to check and what the fallback is.”
• Constraints. “Customer contact data falls under the GDPR, so the portal has to run on a server in the European Union. The company uses Microsoft 365 and we want sign-in kept there.”

The exclusions are the most profitable paragraph in the brief: they move four decisions from delivery back to pricing. How deep to cut the first release is covered in the guide on what belongs in an MVP scope, the data exchange in the one on how system integration works.

Should you state your budget in the request for proposal

Yes — give a range, not a single figure. Without one, every studio guesses the scale for itself: one prices a portal on an existing e-commerce engine, another a solution written from scratch with its own integration layer. You get quotes for three different projects and compare assumptions rather than prices.

A range works as a scope constraint: a studio that knows it answers with “this amount covers the MUST list and two items from SHOULD, the rest goes into phase two”. Without it you lose weeks on projects you cannot fund.

What protects you from padding is not hiding the budget but the structure of the request: a per-module breakdown, the stated assumptions, and one control question — what drops out of scope if the budget is 30% lower. The answer shows whether the studio understands your priorities or simply matched the number to your range. What such an estimate is made of is broken down in the guide on mobile app development cost.

What you do not need to know to write a brief

You do not need the technology, the architecture, or the names of frameworks — a brief describes the problem, not the solution. Dictating a stack without a reason narrows the field and can raise the price, because the studio adapts to a decision nothing justifies.

Nor do you need to know how long delivery takes or in what order the work happens; that belongs in the offer. The sequence is covered in the guide on how to build a mobile app, the calendar side in how long it takes to build an app. One sentence is enough: “we have no preference on technology, please recommend one and justify it.”

You do not need a complete list of features either — only the problem in numbers, a goal, and what you definitely do not want. The workshop fills in the rest.

How to set the response format and the evaluation criteria

Impose the structure of the offer in the brief, or you will get three documents in three layouts that cannot be lined up side by side. Name the sections you expect, add the billing model (fixed price or time and materials), and give the selection criteria with weights, so the studio knows what you actually value.

Three offers in one format tell you more than five in five layouts. Send the answers to questions to every studio in identical wording — otherwise you compare offers built on different information. Wrapping the brief in that procedural half — weights, deadlines, a question window and a required response format — is what turns it into a software RFP.

NDA and code ownership: settle this before you send the brief

In the first email asking about availability and a ballpark cost, do not disclose confidential information: pricing structure, client lists, personal data, or code — the problem and the scale are enough. A confidentiality agreement is signed before you hand over sensitive material, at the latest before the discovery workshop where the studio collects the detail it needs for a serious offer.

Settle who owns the code at the brief stage, not after delivery. Paying the invoice does not transfer economic copyright. You need a contract, and when you hire a Polish studio, Polish law governs its form: under art. 53 of the Polish Act of 4 February 1994 on Copyright and Related Rights, the transfer must be in writing or it is void. The same act limits it to the fields of exploitation expressly listed in the contract (art. 41(2)), so the fields you omit stay with the author — a blanket clause about “all fields” does not replace naming them.

Ask who physically writes the code. Art. 74(3) of the same Polish act gives the employer the economic rights to a program created by an employee performing their employment duties, unless the contract says otherwise — but it covers employment relationships only. Code written by contractors and subcontractors on business-to-business terms needs a separate written transfer across the whole chain. So state in the brief that you expect the fields of exploitation listed by name, plus handover of the source code, the specification, and the user and developer documentation. Getting a named team written into the contract as an annex is one of the seven questions in the guide on how to choose a software house. This description is information, not legal advice.