
By Thomas Cohen, founder of Maestro
Mobile application specification: the eight decisions it must contain
Online specification templates ask for your email and return an empty document. The eight decisions below are what a provider or agent team will ask anyway, and nobody can make them for you.
Type 'cahier des charges application mobile' into a search engine and you find Word templates exchanged for email addresses, all built around the same empty contents list (French search review, September 2026). A useful document settles eight decisions only you can make.
What free templates never ask
A template proposes sections: context, objectives, features, schedule, budget. You fill them in and get a readable document deciding nothing, because no section confronted you with a tradeoff. The provider receiving it must ask the real questions at the first meeting or, worse, answer alone. The eight following decisions take an evening if you accept writing an answer rather than an intention. Each fits in two sentences and becomes expensive if discovered after construction.
One and two: format and offline use
Decision one: a store application with a home-screen icon, or a site users open in a browser. The first opens up the camera, notifications, and in-app payment, committing you to Apple and Google review processes plus updates needing approval. The second updates whenever you want and opens on any device. Many projects choose stores by reflex when their use fits a browser; Maestro only builds web products, and we state that when the question arises. Decision two: what must work without a network. A delivery driver in an underground car park, technician in a cellar, market vendor: if any appears in your story, offline work must be decided now because it changes the application's construction from the ground up.
Three and four: permissions and what happens automatically
Decision three: who may do what. Name roles in your words, the owner, assistant, seasonal worker, then state what each sees, creates, and must never delete. Generators handle this worst because it is invisible on screen. Decision four: what arrives on users' phones without opening the application. An appointment notification the evening before, a deadline reminder, a stock-threshold alert. Write each message's trigger, time, and recipient; the rest follows. An application sending too much gets uninstalled within a week.
Five and six: data and money
Decision five: where data lives and who can export it. Name sensitive information you store, customer details, site photos, health records, state which country it must remain in, and require readable exports of everything in a format opened without the application. Decision six: payment. Collecting inside a store application follows Apple and Google rules and commissions; collecting through a customer link or outside the application changes those rules. Write who pays what, when, and what happens with refunds before anyone draws a button. Overall pricing is separate, in the development cost calculation.
Seven and eight: failures and what follows
Decision seven: what happens when things fail. The network drops during submission, two people edit one record, a user enters an impossible date. Describe expected behaviour in French for three or four such cases: this part distinguishes a product from a demonstration. Decision eight: who responds after launch. There must be an address receiving problems, someone reading them, and an idea of update frequency. A document ending on launch day leaves the project ownerless the next morning.
Write all eight tonight
Open a blank document, write the eight headings, and answer each in two sentences without hunting for exact words. Mark undecided items with a cross: these need discussion with your partner or accountant, and a tool will decide them for you if left blank. Have someone uninvolved in your thinking review the result in ten minutes, as you review a specification without being a specialist. If they ask something you had not considered, the document has already helped. Construction begins with the same exercise using a tool that questions instead of guessing.
Read the complete guide: build an application without coding