Project scope template: the brief we wish we received
Ten headings, one example line each. A project scope template for app and AI projects, to fill in before you talk to an agency or a studio.
5 min read
Most briefs we receive are two lines long, or forty pages long.
The two-line brief hides the decisions. The forty-page one buries them under screens and feature lists. Either way, you get three quotes that cannot be compared, from one month to six, and you pick on price or on feeling. Six months later, the app works and nobody in the field opens it.
Below is the document we would like to receive before a first call. Ten headings, one example line under each, two pages in total. You can write it in an afternoon, for an app or an AI project.
The ten headings: what we build, what we don't build, success criteria, users, data, integrations, constraints, timeline, budget range, owner after launch.
Why the brief decides the price
Every quote you get is a bet on what you meant. When the brief is vague, each studio fills the gaps differently, and you end up comparing three different projects with three different prices.
The gaps come back later. A feature nobody mentioned appears in week four, the planning moves, and the conversation turns to who pays for it.
When a project slips, the cause is rarely the code. It is a decision nobody wrote down.
A good scope does not need to be long. It needs to answer the questions a builder will ask anyway, before the first line of code.
The example lines below follow one imaginary project: a company with 40 field technicians who want a mobile app to log their interventions, with AI writing the report from a voice note.
What you build, what you don't, and how you measure it
1. What we build. One paragraph, in plain words. Describe what changes for someone on a Tuesday morning, not the screens.
Technicians record a voice note after each intervention. The app turns it into a structured report and sends it to the customer the same day.
2. What we don't build. This is the line most briefs skip, and the one that saves the most money. Write down the features you have discussed and set aside for now.
No invoicing, no scheduling, no offline maps in the first version. The planning tool stays as it is.
3. Success criteria. How you will know, three months after launch, that it worked. One or two numbers, with today's value next to them.
Reports reach customers within 24 hours, against 5 days today. Technicians spend less than 5 minutes per report.
For an AI feature, add the error you can live with, and who catches it.
A wrong report costs a phone call, not a lawsuit. The office manager checks every report for the first month, then 1 in 10.
If you cannot write a success criterion, the project is not ready to be built. It may be ready to be audited.
Who uses it, and with what
4. Users. Who opens the product, how often, on which device, and how much patience they have. Name the roles, and roughly how many people per role.
40 technicians on Android phones, often with gloves on. 3 office managers on desktop who check and correct reports.
5. Data. What exists today, where it lives, who owns it, and how clean it is. For an AI project, this heading decides most of the feasibility.
3 years of reports in PDF on a shared drive, written by hand and typed later. Customer list in the CRM. No recordings so far.
Attach 20 real examples to the brief: 20 old reports, 20 emails, 20 tickets. Ten minutes of real data tells a builder more than ten pages of description.
Say where the data is allowed to go. Hosting in Europe, in your own cloud or on your own servers changes the architecture, so it belongs in the brief, not in the contract review.
6. Integrations. Every tool the product reads from or writes to. Add who manages each one, and whether it has an API you have actually seen working.
Read customers from the CRM. Write finished reports back to it. Send emails through the existing provider. The CRM admin is our office manager.
The limits: constraints, timeline, budget
7. Constraints. The rules you cannot change: regulation, security policy, the stack your team already runs, accessibility, languages.
Customer data stays in the EU. The IT team maintains the app after launch, so it uses the stack they already run.
8. Timeline. A date, and the reason for that date. A trade show, a contract renewal or a season tells the builder which corners can be cut and which cannot.
First version used by 5 technicians before March, when the busy season starts. Full rollout by June.
Our first versions usually go live within 3 to 6 weeks of kick-off. That works because the "what we don't build" list is long. A brief that keeps everything in the first version rarely ships that fast.
9. Budget range. Give a range. Without one, you get proposals sized for the studio's comfort, not for your problem.
A low and a high figure for the first version. Running costs budgeted separately, per month.
If you have no idea what range is realistic, that is a fair question for the audit call. A range does not weaken your negotiation. It lets the people building tell you what fits inside it, and what does not.
10. Owner after launch. The person who decides what happens to the product once it runs. Also who fixes it when it breaks on a Saturday, and who pays for the model calls each month.
The operations director owns the product. The IT team takes over maintenance after three months of support from the studio.
Three things to leave out:
- Screen mockups. They decide the design before the problem is clear.
- The technology, unless your team must maintain it (see heading 7).
- A wish list of AI features. "The AI should answer every customer question" is a wish. "It drafts replies to the 5 most frequent questions, and a person sends them" is a scope.
The template, ready to copy
Copy it into a doc and send it to whoever owns the project. The blanks they leave are your first meeting agenda.
PROJECT SCOPE: [project name]
Date: [date] · Written by: [name, role]
1. What we build
[What changes, for whom, in one paragraph]
2. What we don't build
[Features discussed and set aside for now]
3. Success criteria
[1 or 2 numbers, today's value and the target; for AI: acceptable error rate and who checks]
4. Users
[Roles, how many people, device, context of use]
5. Data
[What exists, where it lives, who owns it, how clean it is, where it may be hosted]
6. Integrations
[Tools to read from or write to, owner of each, API checked: yes / no]
7. Constraints
[Regulation, security, existing stack, languages, accessibility]
8. Timeline
[Target date and the reason for it]
9. Budget range
[Low and high, first version and running costs separately]
10. Owner after launch
[One named person, plus who maintains and who pays the running costs]
Leave a heading empty if you do not know. An honest blank is more useful than a guess, and it shows the builder where the first questions are.
If you would rather not write it alone
The free audit ends with a document that answers the first two headings of this template, the hard ones: what is worth building, and what is not. It takes one hour on your business, then a short write-up. If we go ahead, the first step is a written scope: what we build, what we don't, and when it ships.
Send your draft, even half empty, through the contact page. The audit hour then goes on decisions, not discovery. No draft yet: we fill in the first headings together, and the blanks tell us where to start.
