October 15, 2026 · Faith Forge Labs Editorial Team
Write a Software Project Brief That Gets Useful Answers
You do not need a technical specification to start a useful conversation. You do need a clear account of the work, the people involved and what a good result would look like.
You can know that a process needs fixing without knowing what software should replace it. Perhaps staff copy the same information between systems, or customers keep calling to ask where an order stands. That is enough to start a conversation. A useful brief turns that frustration into something another person can investigate.
You do not need to pick a framework or draw every screen. Give the team a clear picture of the work and the decisions you have already made. Leave room for questions where the answer is still uncertain.
Describe the work before naming the solution
“We need a dashboard” leaves a lot open. Who uses it? What do they need to notice? What happens after they notice it?
For a hypothetical example, consider a workshop that tracks jobs on a spreadsheet. A more useful starting point would be: “The office needs to see which jobs are waiting for approval, so someone can contact the customer before the work stalls.” That describes a task without assuming a dashboard is the only answer.
Write down the steps people follow today, including the emails, spreadsheets and conversations between them. Use fictional sample information when explaining the workflow to a prospective supplier. Do not send customer records or account credentials with an initial enquiry.
Make the first version small enough to discuss
Separate the work into three groups: essential for the first release, useful later and outside this project. Be specific about what makes something essential. “The office must be able to record an approval” is easier to discuss than “The system must handle everything.”
A useful pattern is to describe the person, the task and the reason it matters. The GOV.UK guidance on user stories explains that approach and how a few observable acceptance outcomes can make completion clearer.
For the workshop example, an initial outcome might be: an authorised staff member can record an approval, see when it was entered and find the job again. Whether customers approve online can remain a separate decision.
Include the constraints that change the answer
- Who will use the system, and who can approve decisions?
- Which existing tools must it connect to?
- What information is sensitive, and who is allowed to see it?
- Is there a real deadline or an event the work depends on?
- Who will maintain the software and help users after launch?
If you have a spending limit, share the limit and ask what can sensibly fit inside it. If you do not, ask which uncertainties need resolving before an estimate would be meaningful. Our guide to custom software development costs explains why scope and delivery assumptions matter.
Leave the unknowns visible
End the brief with unanswered questions. Can the existing system export the necessary information? Does the process differ between teams? Who will check migrated records? These are useful discovery tasks, not reasons to disguise uncertainty with technical language.
Before sending the brief, ask someone who does the work to read it. If they recognise the process and can point to what would improve, you have a solid starting point. You can then discuss the project with a focused brief rather than an oversized feature list.