A software project brief gives everyone a shared description of the work and what success means. You do not need to design the technical architecture before writing one. Start with the intended user, their task, the boundaries of the first release and the decisions that remain open.
The template below works for a website or mobile app proposal. If you are still deciding which features belong in the first release, read the MVP scope guide first. This brief communicates the scope you want a team to assess.
Describe behaviour before listing screens
A screen list does not always explain what the user can do. Instead of “profile page”, state which information can change, what needs validation and who is allowed to access it. Include the current workflow if you are replacing an existing process.
Separate the need from a proposed solution. “Customers should be able to see their quotation status” is a need. “Build a custom mobile app” is one possible response. Keeping them distinct gives a supplier room to recommend an appropriate approach.
A project brief template you can copy
Copy these fields into a document. When an answer is unknown, write “decision needed” and name the person who can resolve it.
- Project and goal: Whose problem are we solving? How is it handled today?
- Users: Who is the main user? Are there administrators or other permission levels?
- Main journey: Where does the user start and what steps lead to a completed task?
- First release: Which capabilities are necessary to finish that journey?
- Exclusions: What are we explicitly leaving out of this release?
- Platforms and languages: Web, iOS or Android? Who supplies each language's content?
- Data and integrations: What is stored and which systems must connect? Is test access ready?
- Content and design: Who provides copy, images, brand files and existing designs?
- Timing and budget: Why does the target date matter? Which constraints are fixed?
- Acceptance and handover: Which scenarios must pass? Which accounts and files must be delivered?
- Maintenance and decisions: Who supports the live product and who approves consolidated feedback?
- Open questions: What must be investigated before a reliable proposal is possible?
Each answer can start with a sentence or two. The value is in making assumptions visible, rather than producing a large document before the first conversation.
A short worked example
This example describes an imaginary service business; it is not a Nucax client reference.
Goal: Reduce enquiries getting lost in email and let office staff track requests in one place.
Main journey: A visitor selects a service and leaves a short description and contact details. An authorised employee reviews the request and changes its status to new, contacted or closed.
First release: Enquiry form, staff sign-in, request list and status updates. Excluded: Online payment, separate customer accounts and accounting integration.
Acceptance example: A valid submission creates one request. Missing required information produces a clear error. An unauthorised person cannot open the request list. A failed submission preserves the visitor's text.
Open question: Does the first release need email notifications, or is checking the staff dashboard sufficient? Until resolved, proposals should identify the assumption separately.
Make acceptance criteria observable
Translate “fast and modern” into behaviour that can be checked. Completing a form on a phone, preserving input after an error and displaying an updated status are concrete scenarios.
Our Nurena case study includes the decision to save a local draft before analysis. It illustrates why a brief should describe the behaviour protecting the user's work alongside the visible interface.
Some qualities need more investigation before setting a target. Record the intended device, network and workload when discussing performance so everyone knows the conditions under which it will be assessed.
Compare proposals against the same brief
Compare included work, exclusions, dependencies and evidence of completion. A total price alone hides differences: content entry, store submission, analytics setup or maintenance may be included in one proposal and absent from another.
If you share a reference website, explain which qualities matter, such as navigation, legibility or the enquiry flow. Asking for an exact copy leaves both the functional scope and the need for an original design unclear.
Request explicit answers to open questions. Where a supplier cannot estimate an integration without access, agree on a small investigation and its deliverable before relying on a fixed implementation figure.
Common questions
Do I need technical vocabulary?
No. Describe the current process and intended outcome. Ask the team to explain its technology choices. Unknown integrations can be investigated as a defined first step.
Should I share a budget?
A range or ceiling helps a team evaluate a suitable scope. If the scope is uncertain, discuss what discovery will produce and how the implementation proposal will follow.
Can the brief change later?
Yes. Record each change's effect on cost, timing and acceptance. Our product design service turns requirements into flows; you can send your initial summary through the project enquiry form.