Freelancer, no-code or agency: who should build your app?
10 min read
Key takeaways
- Ten to fifteen pages are enough: beyond that, the document is no longer read, only skimmed.
- Describe user journeys, not screens: the screens are the provider's job.
- Any requirement that cannot be quantified is a requirement that will be interpreted against you.
- The most useful section is the one that lists what is NOT in scope.
- A requirements document without prioritisation produces quotes that cannot be compared with one another.
We receive two types of documents. The first is sixty pages long, contains a list of two hundred and forty numbered features, and does not allow us to price anything. The second is twelve pages long, can be read in twenty minutes, and allows us to produce a reliable quote the next day.
The difference is not the length: it is what is described. Here is the structure we ask for, section by section.
1. The context (1 page)
Who you are, what you sell, and to whom. How the problem is solved today, and why that is no longer enough. What you expect from the project, expressed as a business outcome, not as a feature.
What to write: "Our technicians enter their jobs in the evening on a spreadsheet; 15% of reports arrive more than three days late, which delays invoicing."
What not to write: "We want a modern and intuitive app."
2. The users (1 to 2 pages)
For each type of user: who they are, under what conditions they use the tool, on which device, and what would stop them from adopting it.
This section genuinely changes the technical architecture. "Our technicians often work in basements with no network" is a sentence worth three weeks of development, and it never appears in a list of features.
3. The journeys (3 to 5 pages)
This is the heart of the document, and the section almost nobody writes properly.
For each important journey, tell it as a story: what the user wants, what they do, what can go wrong, and how it ends.
The format that works: "As a technician, I want to close a job on site so that I don't have to re-enter it in the evening. I scan the serial number, tick the operations carried out, take two photos, have the customer sign on the screen, and confirm. If I have no network, the job is saved and will be sent automatically later."
Six lines. They contain scanning, offline mode, signature, deferred synchronisation and photo handling. A list of features would have said none of that.
4. What is not in scope (1/2 page)
The most useful section of the document, and the rarest.
Write explicitly what the project does not cover: "no invoicing in this version", "no tablet version", "no import of history prior to 2024", "no admin interface, the data is managed directly by the technical team".
This half page does more for the reliability of a quote than the forty pages that precede it.
5. The constraints (1 page)
- Technical: existing systems to interface with, data format, corporate authentication, mandated hosting.
- Regulatory: personal data, health data, accessibility, regulated sector. A point to address early, as we explain in our article on GDPR compliance.
- Organisational: who decides, who carries out acceptance testing, what availability, which freeze periods.
- Calendar: real dates with their reason. "Before the trade show on 14 March" is a constraint; "as soon as possible" is not.
6. Non-functional requirements (1/2 page)
Quantified, otherwise they are useless.
| Instead of | Write |
|---|---|
| "The app must be fast" | "A record opens in under one second on a mid-range device on 4G" |
| "The app must handle the load" | "300 simultaneous users at peak, 5,000 accounts in total" |
| "The app must be reliable" | "99.5% availability during business hours, daily backup" |
| "The app must be secure" | "Two-factor authentication, encryption of data at rest, access logging" |
7. Prioritisation (1/2 page)
Rank each journey on three levels: essential at launch, important but postponable, nice to have someday.
Without this section, every provider prices the whole thing and you receive quotes that cannot be compared. With it, you get proposals structured in phases, and you keep control of the budget. It is the same exercise as the one described in our article on MVP scope.
8. The consultation framework (1/2 page)
Indicative budget or acceptable range, decision timetable, selection criteria, expected response format, point of contact.
10–15Pages are enough for a useful requirements document
1/2 pageThe "out of scope" section, the most profitable part of the document
3Priority levels to assign to each journey
The five mistakes that make quotes balloon
Describing screens rather than needs. "A screen with a side menu and three tabs" imposes a solution before the problem has been stated. The provider loses the ability to propose something better, and you pay for your own design.
Putting the word "simple" everywhere. "A simple back office", "a simple synchronisation". This word means nothing to the person pricing, and it systematically hides two to three weeks of work.
Forgetting error cases. What happens if the payment fails, if the user loses the network in the middle of the form, if two people edit the same record? Not covered in the document, they will be handled during the project, through a change order.
Confusing the launch with the target. Describing the dream product three years out gives you a three-year quote. Describe version 1, and mention the target in an appendix.
Not naming a decision-maker. A project without a single point of contact who has two to four hours a week takes 30% longer, whatever the quality of the document.
A good requirements document does not describe the solution. It describes the problem precisely enough for several solutions to be proposed and compared.
The template on one page
If you could only keep one outline:
- Context and quantified business objective
- Users and conditions of use
- Journeys told as stories, error cases included
- Explicit out-of-scope list
- Technical, regulatory, organisational and calendar constraints
- Quantified non-functional requirements
- Prioritisation on three levels
- Consultation framework
Send us your document, even incomplete: we will send back, free of charge, the questions that are missing for it to become priceable. It is useful even if you consult elsewhere afterwards.
