Planning a project
How to brief a software developer without writing a technical specification
The starting point
Explain the work, show an awkward case and agree what a complete first release must do.
You can start a software project with a description of the work, the people doing it and the point where it becomes difficult. You do not need to choose a database, draw every screen or know which programming language to request.
For an owner or manager commissioning business software, a useful brief gives a developer enough information to investigate options and explain the trade-offs. It also makes clear what remains uncertain, so a proposal does not quietly turn assumptions into commitments.
The aim is a shared account of the problem, a sensible first release and a way to judge whether the result works.
Describe the problem before naming the product
“We need a dashboard” leaves the important questions open. Who will use it? Which decision will it support? Where will its information come from, and what action follows?
A more useful starting point might be: “Our coordinator checks three lists to find jobs awaiting approval. We need one reliable view of the work that needs a decision.” This is a hypothetical example, not a claim about a particular customer.
The GOV.UK Service Manual recommends understanding the problem, users and constraints before committing to a build, and considering alternatives to a new service. That guidance is written for government teams; the underlying questions are also a useful reference when preparing a business brief. 1
Keep the proposed solution open long enough to compare configuration of existing software, a connection between tools and a custom application.
Show one ordinary case and one awkward case
Walk through a typical job from arrival to completion. Identify who enters information, who checks it, where it is stored and how the next person knows to act.
Then show what happens when something changes. A customer cancels. A reviewer returns a record. Two people edit the same job. A staff member leaves with unfinished tasks. Choose exceptions that actually occur in your business rather than trying to predict everything.
Use redacted documents or invented sample records. Do not send a developer an unrestricted customer spreadsheet just to explain the headings. Mark the difference between an essential business rule and a habit that could change.
Where possible, observe the task with the people who perform it. Ask what they do outside the official process and why. A brief based only on a manager’s intended workflow may miss steps staff currently rely on.
Set a boundary around the first release
Choose a complete piece of work that can be tried by its intended users. A list of disconnected features is harder to assess than a journey with a clear beginning and end.
For the fictional approval workflow, a first release might cover submitting a job, returning it for correction, approving it and exporting the approved records. Payroll, customer accounts and scheduling could remain outside that release.
Write down the exclusion as well as the inclusion. If an excluded feature becomes essential during investigation, revisit the scope deliberately. Do not hide it inside a vague promise that the system will be “future-proof”.
Name the person who can make scope decisions and the staff who will review working versions. Agree how new requests will be assessed, priced and accepted.
Use a short brief with concrete answers
This template is original planning guidance. The example answers describe a hypothetical service business and should be replaced with your own details.
Swipe or scroll the table to see all columns →
| Brief heading | Example answer |
|---|---|
| The problem | The coordinator cannot readily identify jobs awaiting approval. |
| People involved | Staff submit records; a coordinator reviews them; an owner checks totals. |
| Current tools | A spreadsheet and shared email inbox; sample fields supplied without customer details. |
| First release | Submit, return, correct and approve a record, then export approved records. |
| Business rules | Only a designated reviewer can approve; a returned record needs an explanation. |
| Known uncertainty | Whether the existing accounting product supports the required export or connection. |
| Acceptance example | A sample job can complete the whole process, and the export agrees with the approved record. |
| Outside this release | Payroll, scheduling and a customer portal. |
Add your budget range, any real deadline and the reason for it. A supplier needs to know whether a date is linked to an expiring contract or is simply a preference. Ask for assumptions and unresolved questions alongside the estimate.
Make data and access decisions early
The Data Protection Commission explains that privacy should be built into a project from an early stage and that collection should be limited to the data needed for each purpose. 2
Translate that into a few practical questions for your brief: which fields are necessary, who can see them, who can amend them and when should they be removed? Flag sensitive information so the project can receive the appropriate assessment. A generic claim of security does not answer those questions.
Also distinguish a missing feature from a missing permission. If only a manager should approve a record, explain the rule and ask the supplier to demonstrate that other accounts cannot bypass it. Use sample accounts and records for that review.
Include failure and handover in the definition of done
A working demonstration should include mistakes and recovery. W3C’s form guidance emphasises clear feedback on submission, including understandable errors and instructions for correcting them. 3 Ask to see what users encounter when a required field is missing or a save cannot complete.
For stored information, ask what recovery arrangements are included. Ireland’s National Cyber Security Centre distinguishes cloud storage from backups used to restore data after an incident. 4 Request a clear explanation of what is backed up, the recovery process and who is responsible for testing it.
Finally, agree account ownership, export arrangements, rights to custom code, documentation and support responsibilities. Ask what remains chargeable after launch and how you would move to another supplier. Compare these commitments alongside the build price.
You do not need every answer before making contact. A clear description of the work and an honest list of unknowns are enough to begin a useful discussion.
Talk to Féinics Engineering about your software brief. Bring the task you want to improve, the tools you currently use and an example of what a better working day would look like.
References
- GOV.UK Service Manual, Agile delivery community. How the discovery phase works. Published 4 August 2016; updated 21 June 2021. Written for government service delivery, used here for its problem-definition principles.
- Data Protection Commission, Ireland. Data protection by Design and by Default. Undated; accessed 13 October 2026.
- W3C Web Accessibility Initiative. User Notification. Updated 3 June 2022.
- National Cyber Security Centre, Ireland, SME CORE. 5. Back-up your information. Undated; accessed 13 October 2026.
All references opened and reviewed on 13 October 2026.