How to write a mobile app brief that developers can quote

A mobile app brief that developers can quote describes the problem the app solves, who uses it, the three or four flows that make up its core, a feature list split into "at launch" and "later", the platforms, what the app needs on the server side, and the budget and deadline. Apps are quoted badly far more often than websites because a single word in the feature list, such as "chat", "payments" or "offline", can mean a week or a quarter of work.

The template below is built to force those words into specifics. Fill it in before you speak to anyone, and the quotes you get back will be for the same app.

Why are app quotes harder to get right than website quotes?

Three reasons, and the brief addresses each.

Every feature has a backend. A website's contact form sends an email. An app's "sign in" needs accounts, password resets, sessions, and a place to store them. The visible screen is a third of the work; the brief has to describe the invisible two-thirds.

Two platforms, two stores. iOS and Android have different conventions, different review processes and different fees. As of October 2026, Apple's Developer Program costs $99 a year and Google Play charges a one-time $25 registration; the review process on each is documented in Apple's App Store Review Guidelines and Google Play's developer policies. A brief that does not say which platforms, or which store accounts exist, leaves the developer guessing about launch work.

Scope grows while you build. Apps attract ideas. Without a line between launch features and later features, every quote includes a different amount of "later".

Our mobile app development work is nearly always cross-platform in React Native with a backend we build or connect, and the first thing we ask for on a call is a version of what follows.

The mobile app brief template

Copy and fill in every section. Write "not sure" where you do not know, so the developer can see the gap.

MOBILE APP BRIEF

1. The problem
   - What problem does the app solve, in two sentences:
   - How is that problem handled today (spreadsheet, phone calls, a website, a competitor's app):
   - Why an app rather than a mobile website:

2. Users
   - Who uses the app (customers, staff, partners; describe each type):
   - Roughly how many users in year one:
   - What phones they have (iPhone, Android, mix; any old devices):
   - Languages the app must support:
   - Do different user types see different screens?

3. Core flows
   Describe the three to five things a user does most, step by step.
   Example: "A customer opens the app, sees today's slots, picks one,
   pays, and gets a confirmation and a reminder the day before."
   - Flow 1:
   - Flow 2:
   - Flow 3:
   - Flow 4:

4. Features at launch
   Only what the app cannot ship without. For each, one line on what it does.
   - Accounts (email, phone OTP, Google, Apple, none):
   - Notifications (push, SMS, email; what triggers them):
   - Payments (one-off, subscriptions, in-app purchase; which gateway):
   - Maps or location:
   - Camera, photos, documents:
   - Offline use (which screens must work without a connection):
   - Chat or messaging (between whom):
   - Search and filters:
   - Admin screens (who manages users, content, orders):
   - Reports or dashboards:
   - Other:

5. Features for later
   Things you want but can live without at launch. Same format as above.

6. Platforms
   - iOS, Android or both:
   - Minimum OS versions you need to support, if known:
   - Tablet support needed?
   - Do you already have Apple Developer and Google Play accounts?

7. Backend and data
   - Do you have an existing system the app must connect to (CRM, ERP, website, database)? Name it and say whether it has an API.
   - If not, what data does the app store (users, orders, bookings, messages):
   - Who needs to see or edit that data outside the app (staff, accounts team):
   - Any data residency or privacy requirements (country, industry):

8. Design
   - Do you have a brand (logo, colours, fonts)?
   - Three apps you like and why:
   - Any existing designs or wireframes:

9. Launch and after
   - Hard deadline and the reason:
   - Who handles store listings, screenshots and descriptions:
   - Who maintains the app after launch (us, you, not decided):
   - Expected frequency of updates after launch:

10. Budget
   - Budget range for the first release:
   - Monthly budget for hosting, services and maintenance:

11. Decision-making
   - Who reviews designs and builds:
   - Who gives final approval:
   - Can you test builds on your own phones during development?

12. Questions for the developer

Which sections change the quote most?

Core flows. This is the section developers read first. Four clear flows tell a developer roughly how many screens there are, which features are really needed, and where the complexity sits. A feature list without flows is a shopping list; flows are the app.

Accounts and payments. Each option in section 4 has a different cost. Phone OTP login needs an SMS provider and a monthly bill. If you offer Google or other social logins on iOS, Apple's guideline 4.8 also requires an equivalent privacy-focused login option, and Sign in with Apple is the usual way to meet it. Subscriptions sold inside the app go through the stores and share revenue with them; subscriptions for physical goods or services can use a normal gateway. Name the choice and the developer can price it.

Offline. The most underestimated word in app briefs. An app that must work in a warehouse with no signal, then sync when it reconnects, needs a different architecture from one that shows a "no connection" message. If you need offline, say which screens and what happens on conflict.

Backend. If section 7 says "we have a system with an API", the quote covers integration. If it says "we have nothing", the quote should include a backend with admin screens, and you should expect it to be a large share of the total. The mobile app cost calculator separates these so you can see the split.

Admin screens. Every app has a back office, and it is usually forgotten until week eight. Who approves listings, refunds orders, blocks users, edits content? Those screens are often built as a web app alongside the mobile app.

What should you leave out of an app brief?

Everything in section 5 that you are tempted to move to section 4. Launch with the core flows working well. A first release with four flows that work beats one with twelve that half work, and the store reviews reflect it.

Technology choices you cannot justify. "Must be native Swift and Kotlin" doubles the build for most business apps. Say what the app must do; let the developer recommend how.

Competitor feature lists. The competitor had a bigger budget and a different user. Pick the features that serve your core flows.

Monetisation details for year three. Say how the app makes money or saves money now. Plans for ads, premium tiers and a marketplace can wait until there are users.

How do you check the brief is ready?

Give it to a colleague who has not been in the meetings and ask them to sketch the main screens on paper. If they can draw the core flows from section 3, it is ready. If they ask "what happens after you pay?" or "who sees this?", go back and fill those lines.

Then send it to two or three developers and ask each to quote by phase: design, app build, backend, store launch, and a monthly figure for maintenance. The breakdown matters more for apps than for websites because the backend and maintenance lines are where quotes hide their differences. For the overall numbers to compare against, how much a mobile app costs has ranges by feature, and how much a website costs covers the web side if the app needs a companion site.

What happens after the first release?

Budget for it before you sign. As of October 2026, Apple and Google each ship a major OS version every year, and apps that are not updated to match start to break or get flagged in review. A realistic maintenance budget for a small business app is 15 to 25 percent of the build cost per year, covering OS updates, dependency updates, store compliance changes and small fixes. The brief's section 9 asks who handles this; "not decided" is an honest answer, but write it down so every quote includes the same assumption.