How do you write a project brief so that a software house quotes what you actually need? Describe the problem, not the solution. A good brief answers a handful of questions: what isn't working today and how you will know the project succeeded, who will use the system and what they do step by step, which features are essential in the first version, what data comes in and goes out, what the system has to connect to, which legal requirements apply to you, how much you can spend, by when, and who makes the decisions. It doesn't need a single word about technology.
You write a brief once, and every vendor you send it to works from it. Its quality decides whether you get quotes for the same project, or several quotes for several different projects that can't be compared.
- A brief describes the problem, the users and the constraints. The vendor chooses the technology, unless you have a specific reason to impose it, and you write that reason down.
- Describe features as situations: who does what, and how you'll know it works. Every vendor will price the words "admin panel" differently.
- Set priorities. If everything is essential, each company decides for itself what to leave out, and each one leaves out something different.
- Describe integrations by system name and API documentation. That's where surprises usually hide.
- Give a budget range and the reason behind the deadline. Send the same brief to every company, and share the answers to one company's questions with the others.
Brief, specification and request for proposal: how they differ
These three documents are often confused, yet each has a different author and a different purpose.
| Document | Who usually writes it | What it contains |
|---|---|---|
| Brief | The client | Problem, goal, users, processes, priorities, constraints, budget and deadline |
| Functional specification | The vendor or an analyst, together with the client | Detailed description of features, screens, rules and acceptance criteria |
| Request for proposal | The client, sometimes following formal requirements | The brief plus terms: submission deadline, selection criteria, draft contract |
The most common mistake is trying to write a specification instead of a brief. A client without a technical background starts describing database tables and button colours, and skips what they know best: how the work is done today, where the problems are and what the exceptions to the rule look like. A specification grows out of a brief, often in a paid analysis phase, not in place of it. How that phase fits into the way the whole project is billed is covered in our article on fixed price or time and materials.
If your project is co-financed from European Union funds, or you are ordering as a public body, choosing a vendor may be subject to separate rules: in Poland, the competitiveness principle or the Public Procurement Law. The procedure, thresholds and where to publish the request, for example Baza Konkurencyjności, Poland's official portal for procurement notices in EU-funded projects, follow from your grant agreement and the regulations that apply to you. Check them before you send the brief to the first company, because choosing a vendor outside the required procedure can mean the expense is not recognised as eligible.
How to write a project brief: a structure to copy
The structure below works for a website, an online store, an admin panel and an app. For a small website some points take a single sentence; for a system with integrations, several pages. Don't delete empty points: write "not applicable" or "don't know". Both answers tell the vendor something.
What the company does, who it works for, what words you use day to day and what works differently in your industry than everywhere else.
What isn't working today, how much time or money it costs and how you will know, six months from now, that the project succeeded.
Who will use the system, how many people are in each role and what each role can see and change.
What happens step by step, from start to finish, including exceptions and disputed cases.
A list of features described as situations, split into essential, important, nice to have and deliberately postponed.
What data the system stores, how much of it there is, where it lives today and whether it has to be migrated.
Which systems the project has to connect to, which way the data flows, how often and whether documentation exists.
Who supplies the copy, photos, translations, logo and legal documents, and by when.
Devices, browsers, language versions, expected traffic, accessibility, security, backups.
Personal data, digital accessibility, invoicing, terms and conditions, and the industry regulations that apply to you.
Budget range, deadline and the reason for it, any imposed technology or hosting, with a justification.
Who will maintain the system, what the development plans are and whether an in-house team is meant to take over the code one day.
Who makes decisions, who answers questions, how quickly and when they are unavailable.
The order is not accidental. A vendor who reads the context and the problem first will understand the feature list differently than one who starts with it. The points where briefs most often fall short are covered in more detail below.
Goal and measure of success: start with what isn't working today
"We need a new website" is not a goal, it's an idea for a solution. A goal starts with a problem: "enquiries come mainly through referrals and hardly ever from the website", "three people copy orders from emails into a spreadsheet", "customers phone to ask about their order status because they can't see it anywhere". A description like this lets the vendor propose a solution you may not have thought of, or tell you that the problem lies somewhere else.
The other half of the goal is the measure of success. Write down how you will know, six months from now, that the project worked: the number of enquiries from the form, the time from order to dispatch, the number of manual re-entries per week, the number of calls asking about status. If you can, give the current value. The measure doesn't have to be precise, but it has to exist, because without it every feature looks equally important.
It also helps to add what happens if the project doesn't go ahead. "Nothing much, we'll keep working the way we do today" is an honest signal that the project can wait or that a smaller scope will do.
Users and processes: describe the work, exceptions included
For each role, write down three things: who they are, how many of them there are and what they do in the system. "Wholesale customer, around 200 companies, places orders and checks their status" tells the vendor more than "external users". The number of people affects performance and the cost of third-party services; the list of actions shapes permissions.
Describe the process the way you would explain it to a new team member. Step by step: who does what, and what triggers the next step. The most important part of that description is the exceptions, because that's where most of the development work hides:
- What happens when a customer changes an order after paying for it?
- What if an item runs out of stock after the order has been accepted?
- Who can cancel an order, and at what stage?
- How do you handle a customer with individual prices or payment terms?
Every exception that only surfaces during the project is a change in scope and extra time. Every exception written into the brief is a line in the quote. If you don't know what the exceptions are, ask the people who do the work every day. They know them better than anyone in management.
Features described as situations, not buzzwords
A buzzword in a brief sounds specific, but every vendor reads it differently. "Admin panel", "booking system" and "payment integration" can mean two days of work or two months. A feature is well described when it's clear who performs it, what they do and how you'll know it works.
A convenient format is a short user story with criteria:
As a warehouse worker I want to see a list of orders that are paid but not yet shipped, sorted oldest first, so that I can pack them in order.
It works when:
- the list shows no amounts or payment details,
- after entering a tracking number, the order's status changes to "shipped" and the customer receives an email with the number,
- an order without a tracking number cannot be set to "shipped".
Three lines of criteria replace an hour of discussion at acceptance. The vendor knows what to price, and you know what to check. The criteria don't have to be complete. It's enough that they describe what matters to you; the vendor will ask about the rest.
If there are many features, you don't have to write every one up this way. Write up the ones that are essential in the first version or unusual for your industry. Standard features, such as password reset or a contact form, can stay as one sentence.
Priorities: what is essential in the first version
A feature list without priorities is a common reason why quotes for the same brief differ so much. One company prices everything, another only what it considers most important, a third proposes its own split. Each of them is right, because the brief allowed it.
A simple way to set priorities is four categories:
| Category | What it means | Test |
|---|---|---|
| Essential | You can't launch the system without it | Would you go live without this feature? If not, it's essential |
| Important | The system works without it, but with clear gaps | Can it be handled manually for the first month? |
| Nice to have | Conveniences that improve comfort | Will anyone notice it's missing in the first week? |
| Deliberately postponed | Ideas for later versions | Should the vendor know about them so the architecture doesn't block them? |
The last category is underrated. If you're planning a mobile app or a second language version in a year's time, say so, even if you don't want it quoted now. The vendor will design the system so that adding the feature doesn't require a rebuild.
If everything ends up as "essential", run the test differently: imagine the budget is half the size. The features you'd drop first are not essential. Priorities are useful later, too. In a fixed-budget, variable-scope model, they decide what gets cut when something takes longer than expected.
Data and integrations: the most common source of surprises
Describe your data with numbers and examples. How many products, customers and orders per month, and how fast those numbers grow. Where the data lives today: in a spreadsheet, an old system, accounting software, people's heads. Whether it has to be migrated and what state it's in. The best description of the state of your data is a sample: a few dozen rows from a real file, with the format and the mess intact, but with personal data anonymised.
Integrations need even more precision, because each one depends on a system the vendor doesn't know until they see it. "Integration with accounting" is not a description. For each integration, give:
| Information | Example | Why the vendor needs it |
|---|---|---|
| System name and version or plan | A specific invoicing program, cloud version | Different versions have different capabilities |
| Direction of data flow | The panel sends orders, the program returns the invoice number | Two-way exchange means more work |
| Frequency | Real time or once a day | Real-time exchange requires error handling and retries |
| API documentation | A link to the documentation, or a note that there is none | Missing documentation is the biggest unknown |
| Access | Who sets up a test account and who is in contact with the provider | Without access, work can't start |
If the system is to issue or download invoices, state plainly which program issues them. From 1 February 2026, the obligation to issue invoices through KSeF, Poland's National e-Invoicing System, applied to taxpayers whose sales in 2024 exceeded PLN 200 million, and from 1 April 2026 to most of the rest. The smallest taxpayers may issue invoices outside KSeF until the end of 2026, as long as their monthly invoiced sales do not exceed PLN 10,000 gross. The current schedule is published by Poland's Ministry of Finance at ksef.podatki.gov.pl. For the brief, this means one thing: the vendor has to know whether invoices are created in a program that supports KSeF, or whether the system being built has to handle the KSeF integration itself.
Non-functional and legal requirements
Non-functional requirements describe not what the system does but how it has to work. They affect the architecture, so the vendor needs to know them before quoting, not after launch:
- Devices and browsers. Will the system be used mainly on phones, on office computers, or on tablets in a warehouse?
- Language versions. How many languages, whether from launch, and who prepares the translations.
- Traffic. How many people use it at the same time, and whether there are peaks, such as a campaign or a season.
- Security. What data the system stores, whether two-factor login is needed, how often backups should be made.
- Digital accessibility. Whether the system has to meet accessibility requirements, and which WCAG level the vendor should work to. The current W3C recommendation is WCAG 2.2.
On accessibility, check whether the law applies to you. Since 28 June 2025, Poland has had in force the Act on ensuring compliance with accessibility requirements for certain products and services by economic operators, which implements the European Accessibility Act. Among other things, it covers e-commerce services provided to consumers, which in practice means online stores. It does not apply to services provided by microenterprises (Article 4(1)), which, simply put, are companies with fewer than 10 employees and an annual turnover or balance sheet total not exceeding the equivalent of EUR 2 million. If the Act covers you, write that in the brief, because accessibility is designed in from the start, not added after acceptance.
For personal data, write down what data the system will process, who the controller is and whether you have requirements on where it is stored. If the vendor will have access to it, for example during an import or while maintaining the server, you will need a data processing agreement in line with Article 28 GDPR. Also say who prepares the terms and conditions and the privacy policy. Usually the client's lawyer does that, and the vendor implements the mechanisms those documents describe, such as consents and how they are recorded.
Budget and deadline: give a range and a reason
Many clients don't state a budget, hoping vendors will propose lower prices. In practice they get offers that can't be compared, because each company guessed the scale of the project. One quoted a simple version, another an extensive one, a third something in between. A budget range doesn't give away your negotiating position. It tells the vendor which version to propose.
Give a range and say what it covers: just the build, or also content, licences and the first year of maintenance. If the budget is fixed, say so. The vendor will then propose a smaller scope for the first version instead of quoting everything and leaving you with an all-or-nothing choice.
With the deadline, the reason matters most. "By 30 October" says less than "by 30 October, because that's when the trade fair starts and we want to show the system to customers". From the second version, the vendor knows that if problems arise, it's better to deliver a smaller scope on time than the full scope late. Also note when you and the decision-makers are unavailable. Two weeks of holiday in the middle of a project means two weeks without sign-offs, which can push the deadline further than any technical difficulty.
Example: an excerpt from an order panel brief
Below is a shortened example for a fictional wholesaler. It shows the level of detail that's enough for a first quote.
Problem. We take wholesale orders by email and phone. Three people copy them into a spreadsheet and then into the invoicing program. Quantity errors happen several times a month. Customers call to ask about status because they can't see it anywhere.
Goal and measure. The customer places the order themselves and sees its status. In six months, we want no order to be re-typed by hand, and clearly fewer status calls than today.
Users. Around 150 wholesale customers, 3 people in the office, 2 people in the warehouse, the owner. The warehouse doesn't see prices.
Process. Order, confirmation by the office, picking, dispatch, invoice. Exceptions: the customer adds items to a confirmed order, an item is out of stock after confirmation, individual prices for some customers.
Essential. Order placement by the customer, statuses with history, a warehouse view without prices, individual price lists, passing the order to the invoicing program.
Important. Email notifications on status change, export to a spreadsheet.
Postponed. A mobile app for sales reps.
Integrations. Invoicing program, cloud version, with a documented API; we'll set up a test account. Today we export product data to a CSV file from the warehouse program.
Budget and deadline. A net amount range (in a real brief, put actual figures here), excluding maintenance. Launch before the autumn season, because that's when order volumes rise. The owner makes the decisions, answers questions within two working days, unavailable for two weeks in October.
This fits on one page, and from it a vendor can ask specific questions and give a price range. The specification with screens and rules comes later.
Common gaps in a brief and what they lead to
Each of the gaps below has the same effect: the vendor fills it with an assumption, and each one does it differently. The quotes drift apart, and the differences in price come from different assumptions, not different quality.
| Gap | What happens in the quote | How to fill it |
|---|---|---|
| Feature list without priorities | Each company quotes a different scope | Four priority categories |
| Buzzwords instead of features | Wide price ranges or a narrow interpretation | Situations with criteria |
| Integration without a system name | A large buffer in the price, or exclusion from scope | Name, version, documentation, access |
| No information about data | Data migration isn't quoted and comes back mid-project | Numbers and a data sample |
| Unclear who supplies content | The deadline slips and extra cost appears | A list of materials with an owner and a date |
| No budget | Offers in different variants, not comparable | A range and what it covers |
| Deadline without a reason | The vendor won't propose a smaller first version | Date and reason |
| No decision-maker | Questions wait, sign-offs are delayed | Name, role, response time |
| Legal requirements left out | Consents, accessibility or invoicing come up after the quote | A list of the regulations that apply to you |
| Brief describes a ready-made solution | The quote covers the solution, not the problem | Describe the problem, and justify anything you impose |
The last row needs a comment. If you have a good reason to impose a technology, for example an in-house team that knows one system, or an existing licence, write it down together with the reason. The vendor will then respect the constraint, or tell you honestly that it isn't the best fit for your situation. If the only reason is that someone recommended a particular tool, describe the problem and let the vendors propose a solution.
Attachments that save weeks of questions
A brief can be short if it has good attachments. Each of the following answers questions that would otherwise come up during the project:
- A data sample. A few dozen rows from a spreadsheet or export, in the real format.
- Screenshots of current tools. The spreadsheet, old system or form you work with today.
- Sample documents. An order, an invoice, a monthly report, a confirmation email.
- Documentation for the systems to integrate. A link to the API documentation or a contact at the provider.
- Brand materials. The logo in vector format, colours and fonts, if they exist.
- Examples you like. With one sentence next to each saying what exactly: the layout, the way search works, a simple form. A bare link says nothing.
- A list of current page URLs. When replacing a website with a new one, so the vendor can plan redirects.
Don't send real customer personal data in the brief. A data sample should keep the format and the mess, but use fictional names, addresses and phone numbers. If the vendor needs real data, for example for an import, hand it over only after a data processing agreement has been signed. If the brief contains trade secrets, ask for a non-disclosure agreement to be signed before you send it.
How to send a brief to several companies so the quotes are comparable
A brief is most valuable when every vendor gets exactly the same thing. With several companies, a simple routine helps:
The same file with a date or version number. If you change something, you send the new version to everyone.
For example, one week for questions and another week for offers, so the answers reach everyone in time.
A question asked by one company, and your answer, are passed on to the others, without saying who asked.
Ask for the scope mapped to your feature list, a list of exclusions, assumptions, the billing model and a schedule.
Half an hour going through the questions shows more than the offer alone.
The number of questions a vendor asks is a good sign. A company that read the brief carefully usually comes back with a few specific questions, for example about exceptions in the process or access to the API. A company that sends back a price without a single question has quoted its own idea of the project, not your brief. How to compare the offers afterwards is covered in how to read a software house quote, and how to vet the vendors themselves in how to choose a software house.
Frequently asked questions
How long should a project brief be?
Long enough to answer the questions in the structure. For a company website, two or three pages are enough. For an admin panel with integrations, several pages plus attachments. Length is not a virtue: twenty pages without priorities are less useful than three pages with a clear split between essential and postponed.
Does the brief have to specify the technology?
No. The vendor chooses the technology based on the requirements. You impose it only when you have a specific reason, and you write that reason down so the vendor can assess it.
Should I include a budget in the brief?
Yes, as a range, with a note on what it covers. Without a budget, every company guesses the scale of the project and you get offers that can't be compared.
What if I don't know exactly what I need?
Describe the problem, the users and the process, and in place of the features write that the list is open. A brief like this is a good starting point for a paid analysis phase that produces a specification. That's more honest than inventing features just to make the list look complete.
Can a software house write the brief for me?
It can help you structure it, but nobody other than you and your team can supply the knowledge about your company, your processes and their exceptions. What works best is a draft written by you and a conversation in which the vendor asks questions and fills the gaps.
Send the brief, even if it isn't finished
A brief doesn't have to be complete to be useful. A version with the problem, users and process filled in is enough to start a conversation and get a first price range. The rest is filled in through questions.
If you'd like us to look at your brief or help you complete it, send it via the contact form. How the rest of the collaboration works, from quote to launch, is described on the How we work page. We've been doing this since 2020, and at the end of every project you receive the rights to the code and documentation that lets another team take the system over.
