Short answer. A useful specification fits in nine pages and contains almost no technology. It says which problem the app solves and for whom, tells five to eight journeys end to end, sorts the features into three columns, version 1, later, never, gives one checkable criterion per feature of version 1, and settles who owns the code and the accounts. It chooses neither the language, nor the architecture, nor the host: that is the vendor’s job, and a specification that imposes them costs more. Sent to three vendors with the same six questions, it brings back quotes within 25 % instead of a one-to-six spread.
This guide is for the founder settled in France who wants to build in Algeria what they saw working in Lyon or Marseille, for the wholesaler who wants an ordering platform for their retailers, for the manager of a clinic, a school, a chain of shops or a transport company who said “we need an app” and was told by the first vendor “send us your specification”. It says what studies on IT projects measure, what a specification contains and does not contain, how to write it in two weeks, how to read three quotes, and how the 2027 calendar is organised so that a pilot runs before summer.
What the figures say
The cost of a badly written need has been measured for a long time. In its 2014 study on requirements management, the Project Management Institute writes that when a project misses its goals, inaccurate requirements management is the primary cause 47 % of the time; that 5.1 % of every dollar spent on projects is wasted for that reason alone, US$51 million for every billion; and that “inaccurate requirements gathering” was named a primary cause of failure by 37 % of organisations in 2014, up from 32 % in 2013. These surveys cover mostly large organisations worldwide; the orders of magnitude carry over, not the decimals.
The size of the project matters as much as the quality of the document. The 2012 study by McKinsey with the University of Oxford on more than 5,400 IT projects above 15 million dollars finds that on average they run 45 % over budget, 7 % over time, and deliver 56 % less value than predicted. At the other end of the scale, the Standish Group, whose method is debated but whose proportions are quoted everywhere, published in 2015 that 61 % of small projects succeed, against 6 % of the very large ones. The lesson for an app specification is direct: a short version 1, delivered and used, is worth more than a complete version promised; the sorting of features, not the list, is what makes the document.
The Algerian context adds its own lines to the specification. 51.63 million 4G and 5G subscriptions in the second quarter of 2026 according to the ARPCE: users are on phones, mostly Android, and the network still fails in the warehouse, the basement or the wilaya road, which makes “offline” a decision to write down and not a detail. Card payment by CIB and Edahabia goes through SATIM and requires a file carried by the company, while cash on delivery remains the norm; Arabic and French share the same screens; and hosting, the domain name and the store accounts must be in the company’s name, because every month we see apps stuck with a developer who no longer answers. None of this is technical; all of it changes the price.
What a specification contains, in six parts
An app specification reads in six parts, from the problem page to the acceptance criteria, and the first is the one most often missing.
The problem fits on one page and answers four questions: who loses what today, how many times a day, with which tools, and what version 1 must change, in numbers. “Retailers order by phone and WhatsApp, 140 orders a day, four people re-key them, 6 % reference errors, V1 must bring re-keying to zero and errors under 1 %” tells a vendor more than forty features. The journeys tell, role by role, what happens from start to finish, including the case where it goes wrong: the retailer orders at 10 pm, the picker sees the order at 6 am, the driver loads it, the payment is refused, the order is changed after approval. Five to eight journeys are enough; the vendor derives the screens from them, not the other way round. The features come next, written in the format born at Connextra in 2001, “as a retailer, I want to repeat last week’s order in one gesture, so that I save ten minutes”, and above all sorted: version 1, later, never. The DSDM method, where MoSCoW sorting comes from, recommends putting no more than 60 % of the effort into must-haves and keeping around 20 % in could-haves, so that there is room to absorb the unexpected without missing the date.
Data and integrations say what already exists and will have to be carried over or connected: the Excel file of customers and prices, the accounting software, the till, SMS sending, WhatsApp, SATIM for cards. It is often the most underestimated line of quotes; we describe in a separate guide how to carry over the data of an old software without stopping the business. Constraints and ownership set the languages, Android first or iOS at the same time, offline and for whom, where the data is hosted, and in whose name the code repository, the Play and App Store accounts, the hosting and the domain are. Acceptance says how we will know it is done, with one criterion per feature; gives a budget range rather than nothing; sets the pilot date; and asks the question of the following year, who maintains it and for how much per month, which we put figures on in the guide on what an app costs every year.
Writing it in two weeks, in six steps
The document is written without a tool and without a vendor, in about ten hours spread over two weeks, in this order.
The problem page is written first and re-read last: if a feature on the list does not serve what is written on that page, it leaves version 1. The journeys are told out loud with the person who does the work today, the picker, the sales rep, the medical secretary; we write down what they do, not what they should do, and we ask them what goes wrong once a week. The list then the sort is the step that decides price and lead time: write everything, thirty or forty lines, then sort into three columns, and version 1 must fit on one page. The rule that helps most: a feature enters version 1 only if a journey from the previous part cannot be completed without it.
Screens in pencil need no talent: six to ten rectangles drawn by hand, one per step of the journeys, each with a screenshot of an app you like for that particular screen, the one for the list, the one for the basket, the one for tracking. That, and not “modern and intuitive interface”, tells the vendor what you expect. The criterion per feature is a sentence that starts with “it is done when” and that a third party can check: “it is done when a retailer who has never seen the app places a ten-line order in under three minutes without help”. The two readers close the writing: a future user and a trusted developer, friend, cousin, former colleague, read the document; every passage they do not understand is rewritten, every question they ask becomes a line.
«The sort, not the list, is what makes a specification.»
A worked example
An example on assumptions, to be redone with your figures: a food wholesaler, three hundred retailers, who wants an ordering platform.
The list. Thirty-eight features at the start, taken from two apps seen in France and a week of ideas: catalogue, order, reorder, promotions, delivery tracking, card payment, points programme, chat, driver rating, dashboard, and the rest. The sort. Fourteen in version 1: those without which the six journeys cannot be completed, catalogue with per-customer prices, order and reorder, approval by the picker, driver’s round, cash on delivery recorded, statement of unpaid amounts, roles and access, Arabic and French, offline for the sales rep’s order entry. Eleven for later, including card via SATIM, targeted promotions and the points programme. Thirteen never, including chat, because WhatsApp exists, and driver rating, because the manager knows them all.
The document. Nine pages: the problem page, six journeys, the sorted list, eight pencil screens with their references, one criterion per feature, constraints and ownership, a budget range and the pilot date. The quotes. The first request, verbal, “an ordering app for our customers”, had brought back three prices in a one-to-six ratio; the same document sent to the same vendors, with the six questions of the next section, brings back three quotes within 25 %, and the remaining difference is explained by what is included, the carry-over of the Excel and the store release. The calendar. Twenty weeks from the first day of writing to the pilot with ten retailers, with a demo every two weeks from the seventh.
Six sentences that make quotes incomparable
Spreads between quotes rarely come from the work; they come from sentences that each vendor reads in their own way.
Every sentence on the left is in good faith. “An app like Yassir” describes an experience, not a scope, and one vendor reads live geolocation into it while another reads an order form. “Online payment” covers four unrelated pieces of work in Algeria, from recording a cash-on-delivery payment to the SATIM file for CIB and Edahabia cards, which we describe in the SATIM integration technical guide; writing which one enters version 1, and who carries the file, changes the quote entirely. “It has to work everywhere” is the most expensive sentence: every “and”, Android and iOS, web and mobile, online and offline, doubles part of the work, and the right column simply consists of choosing, for version 1, one side of each “and”. We detailed these choices in the seven decisions to take before creating an app.
Comparing three quotes, and what to leave to the vendor
Three quotes are compared with six questions asked in the same order of each vendor, in writing, before talking about price.
Scope and what is included make prices comparable: a quote that does not list your fourteen features one by one has priced something else, and a price that does not say whether mock-ups, tests, release on Play and App Store, carry-over of the Excel and training are inside is not a price. Ownership is settled before signing and in writing: code repository, Play and App Store accounts, hosting, domain name, in the company’s name from day one, with access for the vendor and not the other way round; the guide on the app stuck with a developer who vanished tells what happens otherwise. Method is checked by one thing only: a demo every two weeks, on a link you open yourself, of what really works, not of a mock-up. What comes next is often the real difference between quotes: a price per month after delivery, what it covers, the response time when something breaks. Assumptions say what will move the price, the number of users, who provides content, who carries the SATIM file; a quote without assumptions has them anyway, it just has not told you.
Conversely, a specification that imposes the language, the framework, the database or the host costs more, because it takes away from the vendor the choice they master and leaves them responsible for the result. What you decide: the problem, the journeys, the sort, the languages, offline, where the data is, who owns what, the date. What you leave: how it is built. A good vendor will explain their choices in one page and tell you what they imply for later, for instance what cloud services and AI keys cost when paid from Algeria; a vendor who refuses to explain them is an answer in itself. We compare the three kinds of vendor, freelancer, agency and engineering studio, in a dedicated guide.
«A quote without assumptions has them anyway; it just has not told you.»
Seen in France: the functional specification and the five-day sprint
In France, the specification is an institution. It has its standard, NF EN 16271, published in February 2013 under index X50-151, “Value management, functional expression of the need and functional performance specification”, which replaced the French standard of 2007; its principle fits in one sentence, express the need as functions to be fulfilled and not as solutions to be built, and that is exactly what the problem page and the journeys described above do. Public procurement adds the particular technical specifications, and every founder who worked in a French company has seen a tender with written scoring criteria go by. The diaspora therefore arrives with the habit; what changes in Algeria are the lines to write: cash on delivery next to SATIM, Arabic and French on the same screen, Android first, offline, and ownership of the accounts.
The other practice seen in France, which agencies there sell as a scoping workshop, comes from Google Ventures: the design sprint, five days to map the problem on Monday, sketch on Tuesday, decide on Wednesday, prototype on Thursday and test with five customers on Friday, a method Jake Knapp began running at Google in 2010 and formalised at GV from 2012. We keep its essence for the scoping phase of the seventh week: a clickable prototype tested with real users before writing a line of code, because a week of mock-ups costs less than a month of development in the wrong direction. What does not carry over is the idea that five days replace the specification: the sprint tests a solution, the specification says which problem it must solve and what it will not do.
From France: commissioning an app for Algeria without being there
The founder settled in France has an advantage and a risk. The advantage: they have seen the reference app work, they know what a successful journey looks like, and they are often used to writing. The risk: they write the specification of the French app and not of the Algerian one, with card payment in version 1, a mandatory account on the first purchase, iOS on the same footing as Android and the network assumed everywhere. The journeys must be told with the people who will do the work in Sétif or Oran, by phone if necessary, and every “as in France” assumption must be checked: who has a card, who pays cash, who has an iPhone, where the network fails.
The second point is the distance from the vendor. The six questions apply with even more rigour: the accounts in the name of the Algerian company or yours, never the vendor’s; a demo every two weeks on a link, at a fixed time, and not screenshots on WhatsApp; access to the code repository from the first month; a named person who answers. The pilot is run with ten real users on site, and the decision on version 2 is taken on their feedback, not on the family group’s opinion. If the project is a SaaS, the subscription and its collection are a part of the specification in their own right, which we cover in the guide on launching a SaaS in Algeria.
Who you are, where to start
The wholesaler or distributor starts with the journeys of their retailers and drivers, and with the “data” line: the file of per-customer prices is the heart of version 1. The clinic, practice or laboratory starts with the journey of the patient who books and the secretary who receives them, and with the “ownership” line, because health data cannot be hosted just anywhere. The school or training centre starts with the three roles, parent, teacher, administration, and with payment in instalments. The transport or delivery company starts with offline and with what the owner sees in the evening.
The diaspora founder starts with the problem page, written for Algeria and not for France, and with a first journey checked by phone with a future user. The retailer or chain of shops starts with the existing till and with what it must send to the platform. In every case, the first week is the same: one page, five journeys, the list, then the sort. The vendor only comes in afterwards, and must be able to hand you back, before signing, the specification re-read, the three options and their total price; that is what we do, and that is what to ask of each of them.
The 2027 calendar
From the first day of writing to the pilot, twenty-four weeks, of which the first five cost only time and decide everything that follows.
Weeks 0 to 2: the specification. One page of problem, five to eight journeys, the list then the sort, pencil screens, one criterion per feature, the two readers. Weeks 2 to 5: three quotes. The same document sent to three vendors, a one-hour interview with each, the six questions in writing; Ramadan starts around 8 February 2027 and falls in this period, which does not get in the way of a consultation. Weeks 5 to 7: scoping. Workshops with the chosen vendor, clickable prototype tested with five users, specification amended, contract signed with ownership written in.
Weeks 7 to 17: version 1. Fourteen features, a demo every two weeks on a link you open, existing data carried over from the first demo and not at the end. Weeks 17 to 20: acceptance and release. Every criterion checked one by one, by you and by a user; publication on Play then App Store, Apple stating that 90 % of submissions are reviewed in less than 24 hours on average, which does not rule out a rejection and a second submission. Weeks 20 to 24: the pilot. Ten real users, feedback written down, the decision on version 2 taken in June, before summer. Real lead times by type of project are detailed in the guide on how long an app or a platform takes.
What makes a specification fail
- Starting with the feature list. Without a problem page or journeys, the list grows and nobody can sort it; the quote prices forty features of which fourteen are useful.
- Not sorting. Everything is “essential”; the vendor prices everything, the lead time doubles, and version 1 ships after the market has moved.
- Writing adjectives. “Modern”, “intuitive”, “smooth”, “secure”: nothing checkable at acceptance, and the disagreement arrives at delivery.
- Imposing the technology. The language, framework and host chosen by the buyer take the responsibility for the result away from the vendor and push the price up.
- Forgetting existing data. The price Excel, the accounting software, the till: discovered in the third month, they add a month.
- Leaving ownership for later. Accounts in the vendor’s name, the repository on their side; the negotiation starts the day they stop answering.
- Confusing specification and contract. The document says what and why; the contract says at what price, when, who owns what and what happens after. You need both.
Frequently asked questions
The questions we receive from owners and founders whom a vendor asked for “your specification”.
- Do I really need a specification to get a quote?
- To get a price, no; to get a price that means something, yes. Without a document, every vendor prices the project they imagined, and the spreads between quotes measure that imagination, not the work. Nine pages written in two weeks are enough; a serious vendor will hand them back re-read and completed before signing.
- How many pages, and do I need a template?
- Between six and twelve pages for a first version of an app or a platform; beyond that, the document is usually an unsorted list. Templates downloaded online have a flaw: they make you fill in technical sections you do not master and skip the problem page and the journeys. The six parts of this guide are enough of an outline.
- Should I state my budget in the specification?
- A range, yes. A hidden budget does not get a better price; it gets three quotes built on three different assumptions. An honest range lets the vendor propose the version 1 that fits in it and say what moves to version 2, and that is precisely the conversation you want to have before signing, not after.
- Specification or mock-ups: where to start?
- The specification, short, then the mock-ups with the chosen vendor. Mock-ups made before the problem page and the sort draw a complete app nobody has decided to fund, and they freeze screen choices before the journeys are known. Pencil screens with one reference screenshot per screen are enough at the quote stage.
- The vendor offers to write the specification themselves. Is that a good idea?
- They can complete it, not start it. The problem page, the journeys and the sort must come from you, because they decide what you will pay for and what you will not get. A vendor who writes the document from scratch writes, in good faith, the project they know how to build. The order that works: you write the nine pages, they re-read them, complete them for data and constraints, and hand you back the three options and their total price before signing.
- What if I change my mind along the way?
- You will change your mind, and the document is made for that: the “later” column exists to receive what appears during the build without touching version 1. A demo every two weeks serves precisely to decide early; what replaces a version 1 feature pushes another one out, at equal effort, and the vendor prices it in writing. What costs money is not changing your mind, it is doing so without a document to measure the change.