odel.
Start a project

How to write an app brief developers can quote: a free copyable template

· By Oguz Delioglu, founder of ODEL

A good app brief describes who the app is for, the one problem it solves, the few things a user must be able to do in the first version, how it makes money, and what you already have. One or two pages is enough. It does not need technical words; developers can turn a clear description of users and tasks into an estimate, but nobody can price "an app like Uber, but for dogs".

The brief matters because quotes for the same idea can differ wildly. A 2024 r/iOSProgramming thread about a "semi-complicated" app makes the point: a serious estimate needs many clarifying questions. A brief answers most of them up front, so every developer quotes the same thing.

What to put in it

  1. One sentence. "An iPhone app that lets independent hairstylists book and remind clients without a booking platform fee." If you cannot write this sentence yet, see validate an app idea before hiring a developer.
  2. Users. Who uses it, and is there more than one type of user (customer and staff, parent and child, client and admin)? Each user type adds screens.
  3. The problem today. How do people solve it now: paper, spreadsheet, WhatsApp, an existing app? What is wrong with that?
  4. First-version tasks. Write them as user stories: "As a stylist, I can add an appointment while the client is still on the phone." Keep the list short and mark each line must-have or later.
  5. Out of scope. What the first version will not do. This line prevents most disputes.
  6. Platforms. iPhone, Android, web, or all three. If you are not sure, say who your users are and what phones they carry.
  7. Accounts and data. Do users sign in? Does data sync between devices or users? Is there an admin panel?
  8. Money. Free, paid, subscription, one-time purchases, ads, or a business paying you directly.
  9. Integrations. Calendars, payments, maps, a CRM, hardware, an AI model. Name the product if you know it.
  10. Content and languages. Who writes the texts, and in which languages?
  11. Sensitive areas. Health data, children, finance, location in the background. These carry store rules (below).
  12. What you already have. Brand, designs, a prototype, an existing app or code, developer accounts.
  13. Budget range and date. A range and the reason for any date (a trade show, a season). Developers scope to the range instead of guessing.
  14. Success after launch. How you will judge it in the first months: paying users, bookings, time saved.
  15. Ownership. State that the app will be published under your own Apple and Google accounts and the code assigned to you. See who owns your app code and developer accounts.

Store rules to plan for in the brief

These are not optional, and they affect scope:

  • Account deletion. If users can create an account, Apple requires a way to delete it inside the app (guideline 5.1.1(v)) (Apple). Google also requires an in-app path and a web link for deletion requests (Google).
  • Privacy disclosures. Apple's App Privacy details must list all data you and your third-party SDKs collect (Apple); Google's Data safety form covers the same ground (Google). List analytics and ad tools in the brief.
  • Children. Apps in Apple's Kids Category should not include third-party analytics or third-party advertising, with limited exceptions, and need a parental gate before links out or purchases (guideline 1.3, App Review Guidelines, October 2026).
  • Regulated services. Banking, crypto, healthcare, gambling and air travel apps must be submitted by the legal entity that provides the service (Apple).
  • Templates. Apple rejects template-generated apps unless the content provider submits them (guideline 4.2.6). If you plan many similar apps for several clients or locations, say so.

What to leave out

  • Long lists of "nice to have" features without priority.
  • Technology choices you have not thought through. If you care about native or cross-platform, say why; otherwise ask the developer to recommend one. Background: native vs React Native vs Flutter.
  • A finished visual design you will not change. Sketches and screenshots of apps you like are more useful.
  • Secret details you are not ready to share. Ask for an NDA first if needed.

The template

Copy this into a document and fill in each line. Leave a line blank rather than guess.

APP BRIEF

1. One sentence
   [Platform] app that lets [user] [do task] so that [result].

2. Users
   - Primary user:
   - Other users (staff, admin, parent, client):

3. The problem today
   - How people solve it now:
   - What is wrong with that:
   - Existing apps or tools I have tried, and why they fall short:

4. First version: must-have tasks (user stories)
   - As a [user], I can [task].
   - As a [user], I can [task].
   - As a [user], I can [task].

5. Later, not in the first version
   -

6. Platforms
   [ ] iPhone   [ ] iPad   [ ] Android   [ ] Web app   [ ] Not sure
   Who my users are and what phones they use:

7. Accounts and data
   - Do users sign in?            [ ] Yes  [ ] No  [ ] Not sure
   - Does data sync across devices or between users?
   - Is there an admin panel or dashboard?
   - Does it work offline?

8. Money
   [ ] Free   [ ] Paid upfront   [ ] Subscription   [ ] One-time purchases
   [ ] Ads    [ ] A business pays me directly   [ ] Not decided

9. Integrations
   - Payments, calendar, maps, CRM, AI model, hardware, other:

10. Content and languages
    - Who writes texts and provides images:
    - Languages at launch:

11. Sensitive areas
    [ ] Health data   [ ] Children   [ ] Finance   [ ] Background location
    [ ] Camera or microphone   [ ] None

12. What I already have
    - Brand, logo, colours:
    - Designs, sketches, screenshots of apps I like:
    - Prototype or existing app (link):
    - Apple Developer account:  [ ] Yes  [ ] No
    - Google Play account:      [ ] Yes  [ ] No
    - Company with D-U-N-S number: [ ] Yes  [ ] No  [ ] Personal account

13. Budget and timing
    - Budget range:
    - Target date and why:

14. Success after launch
    - What I will measure in the first months:

15. Ownership and after launch
    - App published under my developer accounts:  [ ] Yes
    - Source code assigned to me:                   [ ] Yes
    - Help I want after launch (updates, ASO, subscriptions, analytics):

16. Contact
    - Name, company, email, time zone:

How to use it

  • Send the same brief to every developer you talk to, so quotes are comparable.
  • Ask each one what is unclear. The questions they ask tell you a lot about them. Our list of questions to ask before hiring an app developer covers the other direction.
  • Expect the brief to change after the first call. A written scope from the developer should replace it as the reference document.

Where ODEL fits, and where it does not

ODEL is a one-person studio that builds and publishes its own iPhone and Android apps and the Appalize SaaS. Send us this brief through the project form and you get a discovery call, then a written scope with a fixed quote or a phased plan. Good fits: an MVP, a subscription app or a MicroSaaS.

Not a fit: projects that need a large in-house team, 24/7 on-site support, or certified vendors for regulated systems such as HIPAA business associate agreements or banking cores; an agency serves those better. And if an existing tool already covers your must-have list, buying it is cheaper than any build.