How to write a mobile app requirements document that gets you comparable quotes (with a template)

A WordPress developer who quotes for agencies described the problem on r/webdev: quote requests arrive with almost no detail, and a long checklist did not help, because clients would tick things "just in case", inflating the price, or fill it in wrongly. One reply adds assumptions to the estimate. Another was blunter: "Then my quote is equally vague."

That is why two agencies can quote ₹2 lakh and ₹20 lakh for "an appointment booking app with payments". Each one filled the gaps in your message with its own guesses.

Here is how to write a mobile app requirements document that closes those gaps: describe who the app is for, the handful of things each user must be able to do, what is in and out of the first version, which outside services it connects to, and who owns the result. Plain language is enough, and five pages is usually plenty. Below is what we ask founders for before we quote, with a template you can copy.

Why vague briefs produce wild quotes#

"Booking with payments" can mean a single form that takes a ₹500 deposit. It can also mean multiple branches, staff calendars, refunds, packages and a reporting dashboard. Cheap quotes usually assume the first, expensive ones the second, and you end up comparing two different apps.

Vague briefs also cause trouble after you sign. A freelancer on r/freelance lost $2,300 on one project when a 20-hour landing page grew to 43 hours through requests like "Can you add a blog section?" On a fixed-price app, the same drift ends in a surprise invoice or cut corners. Our post on what a website or MVP costs covers the other price drivers; this one is about the scope.

What to put in your app requirements document#

We will use a running example throughout: a hypothetical physiotherapy clinic in Lucknow that wants patients to book and pay for sessions on their phone.

1. The problem and who it is for#

Two or three sentences. What is going wrong today, for whom, and what changes if the app works.

"Patients call to book, and we miss about a third of calls during sessions. Patients forget appointments. We want patients to book and pay online and get reminders, so the front desk spends less time on the phone."

2. The types of users#

For the clinic: patients, physiotherapists and the front-desk manager. Each user type means its own screens and permissions, so a missing one becomes a surprise cost later.

3. Five to ten core user stories#

This is the heart of the document. One sentence each: someone does something, and something happens.

• A patient can see open slots for the next 14 days and book one.
• A patient pays a ₹300 deposit when booking, and the rest at the clinic.
• A patient gets a WhatsApp reminder the evening before.
• A patient can cancel up to 12 hours before and get the deposit back.
• A physiotherapist sees their own schedule for the day on their phone.

The specific numbers are what make two quotes comparable. If a flow needs more than one sentence, it is probably two flows.

4. Must-have now, and later#

The simplest split is two columns, Now and Later. For something more formal, the MoSCoW method sorts features into Must have, Should have, Could have and Won't have this time. The Agile Business Consortium's guidance is strict about what counts as a Must: if a workaround exists, even a painful manual one, it is not a Must. The clinic can handle refunds manually for a few months, so automatic refunds go on the Later list.

5. A screens list and rough sketches#

List the screens you imagine: home, slot picker, payment, confirmation, my bookings, profile. Sketch them on paper and photograph them. Nobody expects design skills.

6. Integrations#

Name every outside service the app talks to. Each one is real work.

• Payments: Razorpay for India, Stripe for international cards, or both.
• Messaging: WhatsApp reminders go through the WhatsApp Business Platform, where business-initiated messages outside a conversation must use message templates that Meta has approved.
• Maps and location, if users need directions or nearby branches.
• Login methods: phone OTP, Google, Apple, email. On iOS, if you offer Google or another social login, Apple's App Store Review Guidelines (section 4.8) require an equivalent privacy-focused option too, and any app that lets people create an account must let them delete it from inside the app.
• Tools you already use, such as a CRM or Google Calendar.

7. The admin panel#

Someone has to run the app. Write down what staff need to do without calling a developer: add a physiotherapist, change prices, see today's bookings, issue a refund, export a monthly report. This section changes quotes a lot.

8. Content and who provides it#

Say who writes the service descriptions, FAQs, terms and privacy policy, and who supplies photos and the logo. If the agency writes them, that is extra scope.

9. Platforms#

iOS, Android, web, or a mix. A mobile-friendly web app can be a cheaper first step, with the app stores later (see taking a web app to the App Store). You do not have to pick a framework yourself, but our comparison of React Native and Flutter helps you follow the conversation.

10. Non-functional basics#

• Expected users: "About 300 patients a month in year one" is enough.
• Languages: English only, or English plus Hindi.
• Data and privacy: what personal data you collect and where it is stored. In India, the Digital Personal Data Protection Rules were notified in November 2025 with an 18-month phase-in. According to SCC Online's summary, the rules on consent notices, security safeguards and breach reporting take effect on 13 May 2027. An app commissioned today will be live by then, so ask for clear consent screens and data deletion from the start. Our guide to a privacy policy for an Indian website covers the notice, and health data deserves a lawyer's review.

11. Budget range and deadline#

Give a range, even a wide one. "₹3 to 6 lakh ($3,500 to $7,000), live by March" lets an agency suggest what fits instead of guessing. Say why the date matters so they know how firm it is.

12. What "done" means, and who owns what#

Define done: live on both stores, core flows working on real phones, staff trained on the admin panel, and a free bug-fix period. Then state that the code repository, app store accounts, domain, hosting and design files are in your company's name. Our checklist for hiring an agency covers ownership questions in more detail.

Send the same brief to everyone, and ask for assumptions back#

Quotes are only comparable if every agency gets the same version, so do not add features on a call with one team and forget the others.

Then borrow the trick from that r/webdev thread and turn it around: ask each agency to list the assumptions behind its number. "Refunds handled manually", "one branch only", "client supplies all text". Assumptions you agree with become requirements. Assumptions you disagree with show exactly where the gap between two quotes comes from.

What not to write#

• A 100-page specification. Nobody reads it closely, including you.
• Technology choices you do not understand. "Must use microservices" because a friend said so adds cost. Describe the outcome and let the team propose how.
• Feature lists copied from a competitor. Their app reflects years of learning from their customers, not yours.

Using AI to draft it#

ChatGPT, Claude and similar tools are good at turning messy notes into structure and spotting edge cases, like two patients booking the same slot. Paste in your notes and the template below, and ask it to question you.

The catch: AI will happily produce 20 confident pages of features you never asked for. Delete what you would not pay for, and make the Now and Later calls yourself.

A copy-paste app requirements document template#

APP REQUIREMENTS: [App name]          Date: [ ]   Contact: [ ]

1. PROBLEM AND AUDIENCE
   What is wrong today, for whom, and what changes if this works.

2. USER TYPES
   - [e.g. Patient]
   - [e.g. Physiotherapist]
   - [e.g. Admin / manager]

3. CORE USER STORIES (5 to 10)
   - A [user] can [do something] and [result].
   - ...

4. SCOPE
   Now (first version):
   - ...
   Later:
   - ...
   Won't do in this version:
   - ...

5. SCREENS
   List of screens + link to sketches (photos or Figma).

6. INTEGRATIONS
   Payments:   [Razorpay / Stripe / none]
   Messaging:  [WhatsApp / SMS / email]
   Login:      [Phone OTP / Google / Apple / email]
   Maps:       [yes / no]
   Other:      [CRM, calendar, accounting]

7. ADMIN PANEL
   What staff must be able to do without a developer.

8. CONTENT
   Who provides text, images, prices, policies, and by when.

9. PLATFORMS
   [iOS / Android / web]

10. NON-FUNCTIONAL
   Expected users (year one):
   Languages:
   Personal data collected and where it is stored:

11. BUDGET AND TIMELINE
   Budget range:
   Target launch date, and why it matters:

12. DONE AND OWNERSHIP
   Definition of done:
   Free bug-fix period:
   Owned by us: code, app store accounts, domain, hosting, designs.

Common questions#

How long should an app requirements document be?#

For a first version, three to eight pages including sketches. If it is longer, you are probably describing the Later list in too much detail.

Is a mobile app requirements document the same as a PRD?#

Close enough. A product requirements document (PRD) at a larger company often adds success metrics, research and technical notes. For a founder hiring a team, the template above covers what an agency needs to quote.

Do I need wireframes or mockups before asking for quotes?#

No. Photos of paper sketches are enough to show which screens exist and roughly what is on them. Polished designs are part of the work you are paying for, so do not spend weeks on them first.

Should I write it before or after talking to agencies?#

Write a first draft before, so every agency quotes the same thing, then expect to revise it after the first two or three calls. Even earlier than that, talk to ten potential customers; it will change your user stories more than any amount of writing. Our guide to validating a startup idea before building shows how.

The short version#

Quotes differ wildly because briefs are vague, and each agency fills the gaps with its own assumptions. Write down the problem, your user types, five to ten specific user stories, a Now, Later and Won't list, rough sketches, integrations, admin needs, platforms, budget, deadline and ownership. Send the same version to everyone, ask for their assumptions back, and make the scope decisions yourself.

Once you have a draft, send it our way and book a call. We will go through your brief with you, point out the gaps an agency would guess at, and tell you what we would cut from version one.