A software development brief explains the business problem, the people affected, and what a useful first release must do. For a UK business commissioning a customer portal, internal tool or bespoke application, it gives suppliers a shared starting point for their questions and proposals.
You do not need to choose a programming language or describe every screen. You do need to explain the workflow, the constraints and how you will judge the result. This guide includes an example and a template you can copy into a document before approaching a development partner.
What should a software development brief include?
Start with these eight things:
- The problem and why it matters now.
- The people who will use the software.
- The current workflow, including exceptions.
- The essential scope of the first release.
- Existing systems, integrations and data.
- Budget boundaries and timing constraints.
- Acceptance criteria and a measure of success.
- Ownership, support and handover expectations.
Keep the main brief short enough for a supplier to read before a conversation. Put sample forms, screenshots and detailed process notes in an appendix. Label unknowns clearly so they can be investigated instead of priced as assumptions.
1. Describe the problem before listing features
“We need a dashboard” leaves important questions unanswered. Who needs it? Which decision does it support? Where does the information come from?
Try a more concrete description: “Our operations team copies job updates from emails into a spreadsheet. Staff cannot reliably tell which jobs are ready to invoice.” This gives a developer something to investigate before proposing screens.
The GOV.UK Service Manual’s discovery guidance starts with understanding the problem, users and constraints before committing to a build. Although written for government services, that starting point is useful when commissioning business software too.
2. Walk through one real workflow
Choose a representative task and describe it from start to finish. For a job-management tool, that might be: request received, job assigned, work completed, completion approved, invoice prepared.
For each step, record who acts, what information they need and what happens next. Include awkward cases: a cancelled job, a missing attachment, an approval sent to the wrong person or an employee working without a reliable connection.
Give suppliers anonymised examples rather than customer records or login credentials. A sample spreadsheet with invented names can reveal columns, statuses and validation rules without exposing live information.
Worth noting while you map the workflow: some of the steps you are documenting may not need building at all. Seven admin tasks you can automate today covers the ones that are usually cheaper to automate than to systematise.
3. Separate the first release from later ideas
Make three lists: essential for launch, useful later, and explicitly outside the project. Prioritise complete workflows. A basic job-approval process that works end to end may be more useful than several polished screens with missing steps between them.
Here is an illustrative scope for a small job-management application. It is an example, not a Codeora client case study:
- First release: staff login, job creation, assignment, completion approval and a CSV export.
- Later: automated reminders, management reporting and a direct accounting integration.
- Outside scope: payroll, route planning and a native mobile app.
Ask suppliers to identify dependencies between these choices. An export may be a reasonable starting point, but only if someone can use it in the existing invoicing process. Our custom software versus off-the-shelf guide can help if you are still deciding whether a bespoke build is appropriate, and from MVP to scale covers how a first release should be sequenced if the software is a product rather than an internal tool.
4. Make integrations and data visible
List each system the application must exchange information with and explain the direction of travel. “Connect to our CRM” is less useful than “Read customer contact details from the CRM, but let only the CRM change them.”
- Which system is the authoritative source for each record?
- Does information need to move immediately, hourly or on request?
- Is there documented API access, and who can authorise it?
- What should happen when an integration is unavailable?
- Does historical data need importing, cleaning or deduplicating?
Also describe access boundaries, backup expectations and data export needs. Include any accessibility, privacy or security requirements your organisation has already established. If a requirement is undecided, assign someone to resolve it during discovery.
5. Turn requirements into acceptance checks
A requirement says what you want; an acceptance check explains how you will recognise that it works. The GOV.UK guide to writing user stories describes user needs and acceptance criteria as tools for making work understandable and testable.
For the example above, replace “Managers can approve jobs” with checks such as:
- A manager can approve a completed job assigned to their team.
- The record shows who approved it and when.
- An unapproved job is excluded from the invoice export.
- A team member cannot approve a job using a manager-only action.
Keep acceptance checks separate from business targets. For example, you might measure weekly time spent preparing invoice data before and after launch. Treat an improvement target as something to validate, not a saving the software has already delivered.
6. Explain budget, deadlines and handover
Provide a realistic spending boundary and say what it covers. Ask suppliers to distinguish discovery, design, development, migration, hosting, third-party subscriptions and ongoing support. Request that UK proposals state their currency and whether VAT is included.
If you have no sense of what a realistic boundary looks like, our guide to what custom software costs in the UK sets out the ranges and what moves them.
Explain why a deadline exists. A contract renewal or seasonal busy period gives a supplier more context than “as soon as possible”. Include the time your own team needs for feedback, data preparation, training and acceptance testing.
Before commissioning work, agree what will be handed over: source code, deployment instructions, account access, documentation, data exports and support arrangements. Ask how defects after launch are handled and how future changes are estimated.
Copyable software development brief template
Copy these prompts into a document and answer them in plain English. “Unknown — investigate during discovery” is a useful answer when it is accurate.
- Project: What are we calling this, and who can make decisions?
- Problem: What goes wrong today? Include one concrete example.
- Users: Who uses the system, on which devices, and in which situations?
- Current process: What happens from the initial request to completion?
- First release: Which complete workflow must work at launch?
- Boundaries: What is deferred or outside scope?
- Systems and data: What connects, what migrates, and who owns each source?
- Requirements: What access, accessibility, security and operational needs must be addressed?
- Acceptance: What observable checks must the first release pass?
- Success: Which baseline and follow-up measure will we compare?
- Commercial constraints: What budget, deadline and internal availability apply?
- Handover: What must our team receive, operate and maintain?
How to compare the proposals you receive
Send the same brief to each supplier. Ask them to return their understanding of the scope, exclusions, assumptions, delivery stages, recurring costs and unresolved questions. Check whether each proposal includes the same migration, testing and support work before comparing headline prices.
A useful proposal should also challenge unclear requirements. If every unknown has quietly become a fixed assumption, resolve those differences before work starts.
For a bespoke application, see Codeora’s custom software development services. When your brief is ready, send us your project outline so we can discuss the workflow, priorities and next steps.