Write a software brief vendors can quote.
A software brief tells a development company the problem to solve, who will use the system, which workflows and data it touches, what it connects to, and your constraints. With it, any company can scope and quote. Foxefy, a custom enterprise software development company, starts every project with a discovery call; a brief gives it a head start.
What is a software project brief?
A software project brief is the buyer's short, plain-language document on the problem, the users, the workflows, the data, the integrations and the constraints. A brief says what you need, not how to build it. From a brief, a development company can tell whether the project fits, what to ask next and how to scope the work.
A brief is not a specification. A software requirements specification (SRS) is the detailed document of what the system must do, and it is usually produced during discovery, with the company's help. ISO/IEC/IEEE 29148 describes how such requirements are written and checked.
A request for proposal (RFP) is a brief plus the rules of a vendor selection: a timeline, questions, evaluation criteria and a response format. Write the brief first, and turn it into an RFP only if you run a formal vendor selection.
What should a software brief include?
A useful brief has twelve sections: the business goal, users, current process, repeated workflows, priorities, data, integrations, reports, optional AI steps, constraints, ownership and access, and decision-makers. Each section can be a few lines. The table says what to write in each section and gives a placeholder example, not a real client.
| Section | What to write | Example entry |
|---|---|---|
| 1. Business goal | The problem in one or two sentences and what should change when it is solved. | Orders are retyped between three spreadsheets, so invoices go out late. Orders should be entered once. |
| 2. Users, roles and head counts | Who uses the system, roughly how many people hold each role, and what each role may see or change. | Sales reps, a sales manager, two finance staff and an admin. Reps see only their own accounts. |
| 3. Today's process and tools | How the work runs now and which tools carry it, including spreadsheets and email. | Quotes start in email, move to a spreadsheet, then to the accounting software by hand. |
| 4. The five workflows the team repeats most | Name each workflow, who starts it, the steps and who finishes it. | Quote request, approval, order entry, invoice, follow-up call. |
| 5. Must-haves and nice-to-haves | Rank each item as must, should or could. | Must: one record per customer. Should: an approval step. Could: a mobile view. |
| 6. Data | Which records exist, where they live today and how clean they are. | Customer and order records in two spreadsheets, with duplicates and missing phone numbers. |
| 7. Integrations | What the system must connect to and what moves in each direction. | Accounting software for invoices, email for notifications, the website form for new leads. |
| 8. Reports and decisions | The reports people read and the decisions each one supports. | A weekly pipeline view for the sales manager, a monthly receivables view for finance. |
| 9. AI agents (optional) | Which repetitive steps an AI agent could take, and which stay with people. | Draft follow-up emails for a rep to review. A person approves every send. |
| 10. Constraints | Budget range, deadline, the data protection rules that apply to your users, for example the GDPR or PIPEDA, and hosting. | Budget range agreed with finance. Launch before the next season. Customer data must stay in a named hosting region. |
| 11. Ownership and access | Who holds the code, the accounts and the admin rights during and after the project. | The business owns the accounts. Two named people hold admin access. |
| 12. Decision-makers and success | Who decides, who signs off and how you will judge that it worked. | The operations lead decides. Success means orders are entered once and invoices go out the same day. |
The same headings as a plain list, ready to copy into your own document:
- Business goal
- Users, roles and head counts
- Today's process and tools
- The five workflows the team repeats most
- Must-haves and nice-to-haves
- Data
- Integrations
- Reports and decisions
- AI agents (optional)
- Constraints
- Ownership and access
- Decision-makers and success
The details that most change a quote are the cost drivers.
How detailed should requirements be before you talk to a company?
Before you talk to a company, write software requirements as outcomes, not screens, and rank each item as must, should or could. "Sales reps see every open quote for their accounts in one place" is a requirement a company can price and design. "A blue button on the left" is a design choice that is better settled during discovery.
The ranking is called MoSCoW, and the Agile Business Consortium defines it with a fourth group for what is out of scope this time.
- Must: the system is not usable without it.
- Should: important, and a temporary workaround exists if it waits.
- Could: wanted, and the first thing to drop if the schedule tightens.
Keep the musts few. A brief where every item is a must tells a company nothing about where to start, and it makes every quote larger.
How do you turn a brief into an RFP?
Keep the brief as the first part of the RFP, then add the rules of the selection: when responses are due and when you will decide, the questions every company must answer, how you will score the answers, the format you want back, and your preferred pricing model. A fixed format and scoring rules let you compare responses side by side.
- Selection timeline: the date for questions, the response date, any presentations and the decision date.
- Questions for vendors: how they work, who does the work, how they test, how they handle change and what support follows launch. The questions to ask are a good starting set.
- Evaluation criteria: the points you will score, such as fit with your workflows, process, communication and how clearly they price the work.
- Response format: the same headings for everyone, so you can compare answers line by line.
- Preferred pricing model: say whether you expect a fixed price or time and materials. The fixed price and time and materials guide explains how each handles scope and change.
When the responses arrive, the quote comparison checklist helps you read them on the same terms. After you sign, the kickoff checklist covers logistics such as access and who attends.
What makes a brief hard to quote?
Six gaps make a brief hard to quote: screens listed instead of outcomes, no user numbers by role, unknown data quality, no named decision-maker, an unranked wish list and no constraints. Each gap forces the company to guess, and a guess shows up in the quote as a wider range or a larger allowance for risk.
- Screens instead of outcomes: the company prices a design you may not want.
- No user numbers by role: permissions and licenses cannot be sized.
- Unknown data quality: migration and clean-up cannot be sized.
- No named decision-maker: approvals stall and scope drifts.
- An unranked wish list: everything looks equally urgent, so everything is priced.
- No constraints: budget range, deadline and data rules change the approach, and leaving them out wastes a round of questions.
If you cannot fill a section, write "unknown" and say why. A flagged gap is easier to scope than a missing one, and it gives the discovery call a clear first question.
What happens to your brief on a Foxefy discovery call?
Foxefy starts every project with a discovery call to understand your business, its problems and its goals. Foxefy's team reads the brief you send, asks about its gaps on the call, and uses the answers in the research and the proposal that follow.
After the call, Foxefy researches your problem and sends a proposal with milestones and deliverables. Every project is scoped and quoted after a discovery call. Foxefy works remotely, with discovery, reviews and check-ins over video calls. The full sequence is on How we work.
You do not need a finished software project brief to book a call. A half-page covering the goal, the users and the biggest workflow is enough to begin, and Foxefy's team can fill in the rest with you. For the wider service, see custom software development. Book a discovery call when you are ready.
Frequently asked questions
How long should a software project brief be?
A software project brief should be long enough to cover the twelve sections and no longer, with a few lines in each. A short brief that names the goal, users, workflows, data and constraints is more useful than a long one that describes screens. If a section is unknown, say so.
Should we include a budget in the brief?
Yes, a range is worth including. A budget range lets a development company propose something that fits instead of guessing, and it shows early whether the project is realistic. If you cannot name a range, say what the project is worth to the business and ask for options at different sizes.
Do we need a technical specification before contacting a development company?
No. A brief is enough to start. The detailed specification, or software requirements document, is usually written during discovery, because the right design depends on answers you only get from talking through the workflows and data. Bring the problem, the users and the constraints.
Tell us which work should run itself.
Foxefy maps how your business runs on a discovery call, then proposes the system that fits.
Book a discovery call- info@foxefy.com
- Phone
- +91 6381 901 252