UK Software Project Brief Template

Custom software fails on ambiguity far more often than on technical difficulty. Two people agree on a feature, both picture something different, and nobody finds out until it is built. The cost of that discovery rises every week it stays hidden.

This template forces the awkward questions to the front. It is the brief we use before scoping any custom build, and it is designed to be filled in by the person who understands the business process, not by a developer.

Describe the process, not the software

The most useful thing you can write is how the job is done today, including the spreadsheet, the WhatsApp group and the paper diary. A developer can design a system around a process they understand. They cannot design one around a feature list with no context, and feature lists written by non-specialists tend to describe a familiar interface rather than the actual need.

The sections people underestimate

User roles. Who can see what, and who can approve what. Permissions look trivial and are frequently the most fiddly part of the build. Get them written down early.

Integrations. Every external system the software must talk to. Each one carries its own authentication, rate limits and failure modes, and each is genuine work regardless of how simple the connection sounds.

Data. What exists now, where it lives, and whether it has to be migrated. Legacy data migration is routinely underestimated because the old data is rarely as clean as anyone remembers.

Acceptance criteria. How you will decide it is finished. Without this, projects do not end, they just gradually stop.

The scoping template

Fill this in BEFORE talking to any UK developer. Sharper briefs get sharper quotes.

1. The problem

  • What problem is this software solving? (1 sentence):
  • Who has this problem? (specific user role):
  • What does that person currently do without your software?
  • What’s the cost (in £, time, or risk) of the current workaround?

2. User roles

  • List each type of user (e.g. admin, customer, staff):
  • For each, list the 3-5 things they need to do in the software:

3. Core features (MVP)

  • List must-have features for v1 (be ruthlessly minimal):
  • For each, mark whether it’s server-side, client-side, or both:

4. Nice-to-have features (v2+)

  • Features you want eventually but don’t need at launch:

5. Integrations

  • Third-party systems to connect to (Stripe, Xero, HubSpot, etc.):
  • Direction: read-only / write / bidirectional sync
  • Frequency: real-time webhook / hourly / daily

6. Non-functional requirements

  • Expected users in year 1: ___ in year 3: ___
  • UK data residency required? Yes/No
  • Specific compliance (PCI, GDPR, SOC 2)?
  • Mobile support: native iOS / native Android / responsive web

7. Constraints

  • Launch deadline:
  • Budget range:
  • Existing technology you must work with:

8. Success criteria

  • How will you know if v1 succeeded? (specific, measurable):
  • What does failure look like?

Scope it smaller than you want to

The most reliable predictor of a custom build succeeding is whether the first version was kept deliberately small. Identify the single process causing the most pain, build only that, put it in front of real users, then extend. Everything you learn from a working version is worth more than everything you assumed in the brief.

Budget for the period after launch as well. Software needs hosting, updates, security patches and a route for users to report problems. A build quote with no support arrangement is not a complete quote.

Common questions

Should I build custom or use off-the-shelf? Off-the-shelf, wherever it fits. Custom software earns its cost when your process is genuinely unusual, when licence fees per seat have outgrown a build, or when the integration between tools is the actual problem. Filling in this brief usually makes the answer obvious.

How do I know if a quote is reasonable? Compare what is included rather than the totals: discovery, testing, deployment, documentation, handover and support. A cheaper quote missing testing and handover is not cheaper.

Who owns the code? Ask explicitly and get it in writing before work starts. It should be you. This is the software equivalent of owning your logo source files, and it is just as easy to lose by not asking.

What if requirements change mid-build? They will. What matters is having an agreed way to handle it, so changes are priced and scheduled rather than absorbed silently until the timeline slips. Our custom software service sets that out in the proposal, or send us the brief and we will tell you honestly whether a build is the right answer.