The verdict in three sentences
A vague requirements document produces quotes that vary threefold for the same need, and the business owner pays the difference in change orders. A 12-section document with MoSCoW-prioritised user stories and measurable acceptance criteria is enough to bring the gap between offers below 30%. Plan 5 to 10 days of internal work to write it, against months of disputes avoided.
The 12 essential sections of an app requirements document
An SMB (distribution, logistics, construction, professional services) does not need an 80-page document. It needs a document that three vendors read the same way. The 12 sections below cover that minimum, in the spirit of a lean product requirements document (PRD).
| Section | Expected content | Common mistake |
|---|---|---|
| 1. Context and goals | Business problem, 3 target KPIs (e.g. order processing time) | Vague goal such as "modernise" |
| 2. Users and roles | Profiles, number of users, permissions per role | Forgetting customer or partner accounts |
| 3. MoSCoW user stories | 30 to 60 stories ranked Must, Should, Could, Won't | Marking everything as Must |
| 4. Key journeys | 3 to 5 step-by-step journeys with low-fidelity wireframes | Letting the vendor guess |
| 5. Data and volumes | Record counts, yearly growth, legacy data migration | Ignoring migration from Excel or the ERP |
| 6. Integrations | ERP, accounting, payments, emailing, third-party APIs | Not providing API documentation |
| 7. Non-functional requirements | Response time under 2 s, 99.5% availability, mobile support | Missing, therefore not priced |
| 8. Security and GDPR | Authentication, logging, retention periods, sub-processors | Referring to "market standard" |
| 9. Hosting | European cloud, backups, staging and production environments | Assuming hosting is included |
| 10. Acceptance criteria | Test scenarios, blocking-bug thresholds, acceptance period | Acceptance "by eye" |
| 11. Ownership and exit | IP assignment, code repository, documentation | Code hosted on the vendor's account |
| 12. Timeline and target budget | Milestones, budget range, date constraints | Hiding the budget, which skews quotes |
Stating a budget range (for example 30,000 to 45,000 EUR excl. VAT) does not weaken your negotiation: it lets vendors propose a fitting solution instead of guessing.
Prioritising with MoSCoW and measuring acceptance
MoSCoW exists to protect the budget. A simple 2026 rule: Musts stay under 60% of the estimated effort, Shoulds 20 to 25%, Coulds the rest. Won'ts are written down explicitly to avoid misunderstandings.
| 2026 order of magnitude (Europe, SMB) | Simple app | Mid-size app | Rich app |
|---|---|---|---|
| Number of user stories | 25 to 40 | 40 to 80 | 80 to 150 |
| Target budget excl. VAT | 20,000 to 35,000 EUR | 35,000 to 60,000 EUR | 60,000 to 80,000 EUR and up |
| Delivery time | 8 to 12 weeks | 3 to 5 months | 5 to 8 months |
| Quote spread with a vague brief | 1 to 2x | 1 to 2.5x | 1 to 3x |
| Quote spread with this template | 10 to 25% | 15 to 30% | 20 to 35% |
| Acceptance period | 1 to 2 weeks | 2 to 3 weeks | 3 to 5 weeks |
Acceptance criteria must be measurable: "0 blocking defects, at most 5 minor defects, order list loads in under 2 s with 10,000 rows". Without such thresholds, acceptance turns into an endless negotiation.
Comparing three quotes on an equal scope
Once the document is sent, build a comparison grid: price per lot, assumptions made, excluded stories, annual maintenance cost, code ownership terms. A quote 40% cheaper that leaves out data migration or acceptance testing is not cheaper. Always ask for an estimate per user story, or at least per functional lot.
Mini case study
Need a professional website?
Kolonell builds websites that attract clients, optimized for the Sénégalese market. Free quote in 2 minutes.
Nadia runs a 25-person industrial supplies distributor in Marseille. Her first round of quotes, based on a two-page brief, came in at 22,000, 41,000 and 68,000 EUR excl. VAT. She spends 7 days writing a 12-section requirements document with 48 user stories, 27 of them Musts. Second round: 38,000, 43,000 and 47,000 EUR, bringing the spread down from 209% to 24%. She picks the 43,000 EUR offer, which includes migrating 12,000 customer records. Illustrative example: by avoiding two change orders estimated at 6,000 EUR each, her 7 days of work pay for themselves many times over.
FAQ
How long does it take to write an app requirements document?
For an SMB, plan 5 to 10 days of work over 3 to 4 weeks, involving 2 to 4 key users. Some vendors offer a paid scoping workshop, often 2,000 to 6,000 EUR, deductible from the project.
Should I state my budget in the requirements?
Yes, a range is enough, for example 30,000 to 45,000 EUR. Without a budget, quotes can differ by a factor of 3, because each vendor imagines a different solution.
What is the MoSCoW method?
It ranks needs as Must, Should, Could and Won't. Keeping Musts to about 60% of the effort protects the budget and makes a useful first release possible in 8 to 12 weeks.
Is a free requirements template enough?
A template gives the structure, not the business content. The 12 sections must be filled with your real figures: number of users, data volumes, integrations and acceptance thresholds.
Which acceptance criteria should I include?
Set a maximum number of defects (for example 0 blocking, 5 minor), response times (under 2 s) and an acceptance period (2 to 3 weeks). These thresholds should gate payment of the final milestone.
Let's scope your project. Send us your requirements or brief: we price the scope lot by lot, with an indicative budget (custom applications from 2,500,000 FCFA, about 3,810 EUR) and a realistic timeline. Detailed quote within 48 h. WhatsApp +221 77 596 93 33.
Mohamed Bah
Fondateur, Kolonell
Passionate about digital and entrepreneurship in Africa, Mohamed has been helping Sénégalese businesses with their digital transformation since 2020. Founder of Kolonell, he believes every SME deserves a professional and accessible online présence.
