Mobile App Requirements Document: One-Page Template

Mobile app requirements document: the short answer

When you're building your own app, a good mobile app requirements document fits on one page. It answers ten questions: who it's for, what problem it solves, what the main feature is, how the app makes money, what happens without an account, what data has to survive, which platform, what's out of the first version, how you'll know it works, and what your constraints are. The template to copy is below. You can also download the template and its validation checklist (.md), no sign-up needed.

The 40-page templates you find online are written for a different purpose: a client ordering an app from a contractor who needs a contractual document. You're both the one who decides and the one who builds, often with AI's help. Your requirements doc does two things: it settles decisions before you code, and it gives Claude, ChatGPT or Cursor clear context so they build the right app.

I publish my own iOS apps. Solys, an alarm clock with mini-games, and TradaZen, a trading simulator, are on the App Store. Nolera and Clic were rejected by Apple, then fixed. This is the method I use for each of them, and it's the one I'm sharing here.

Why one page is enough to scope your own app

A long document makes you feel like you've made progress. In practice, it's written once, rarely reread, and the project drifts away from it within the first few weeks. One page, on the other hand, takes two minutes to reread before every work session.

The space limit has another useful effect: it forces you to decide. If an answer runs past two sentences, the decision often hasn't been made. Better to find that out on a sheet of paper than in your code three weeks later.

Finally, one page is the right size for AI. You can paste the whole thing into a conversation, or put it in your project's context file. A short document is easier to review and cuts down on contradictory instructions. It doesn't guarantee the AI will follow them: check its suggestions against this frame.

What should a mobile app requirements document include?

Answer each of these questions in one or two sentences.

1. Who uses the app, and in what situation? Not "18 to 35 year olds." Instead, a specific person at a specific moment in their day.
2. What problem does the app solve, in one sentence? If you need "and also," you're describing two apps.
3. What is THE main feature of the first version? Just one. The others can wait for the numbers. The iOS app MVP page explains how to choose.
4. How does the app make money? Subscription, one-time purchase or free. This answer changes the app from the very first screen. If you're unsure, read subscription or one-time purchase for an iOS app.
5. What can people do without creating an account? Deciding early what's available without signing up saves you from redoing the whole onboarding flow.
6. What data has to survive a phone change? This is the question that decides whether you need a backend like Supabase, or whether everything can stay on the device.
7. iOS only, or iOS and Android? My advice when you're starting out: iOS first. I explain why in iOS and Android apps at the same time.
8. What is explicitly OUT of the first version? The most useful section of the document. It shuts down debates before they start, with yourself and with the AI.
9. How will you know it works? One single signal, measurable in the weeks after launch: free trials started, subscribers, users who come back.
10. What are your real constraints? The time you can put in each week, your hardware, and your Apple Developer account, which costs $99 per year. No Mac? That's not a blocker, as I explain in publishing an iOS app without a Mac.

The requirements template to copy

Copy this template into a note or a text file at the root of your project, then replace each line.

• Working name of the app: …
• Who it's for: a person who … at the moment when …
• Problem solved, in one sentence: …
• Main feature of version 1: …
• What the user sees when opening the app for the first time: …
• Business model: subscription / one-time purchase / free, and what's paid: …
• Without an account, you can: …
• Data to keep between two phones: none / …
• Platform: iOS first (Android later if the numbers justify it)
• Out of version 1: …, …, …
• Success signal: …
• Stack: React Native, Expo, Supabase if accounts are needed, RevenueCat for subscriptions
• Constraints: … hours per week, Apple Developer account open or not, Mac or not
• Apps whose experience I like, and why: …

Add three to five screenshots of apps you like, with a word on what you like about them. That says more than a brand style guide, for you and for the AI.

A requirements document isn't a wish list. It's a list of decisions made.

Example: the page filled in for a fictional app

To show the level of detail you're aiming for, here's the template filled in for an app made up for this example: a study timer.

• Who it's for: a student who studies alone in the evening and loses focus after ten minutes.
• Problem: they can't get through a work session without picking up their phone.
• Main feature: start a timed session and see their streak of days kept.
• First screen: a single button to start a session.
• Business model: subscription for detailed stats, basic session free.
• Without an account: everything, except backup between two phones.
• Out of version 1: group mode, leaderboard with friends, widgets, Android version.
• Success signal: users who come back several days in a row.

Notice what's deliberately missing: no list of twenty screens, no required colors, no architecture. Those choices will come as you build, and the page helps you check that they keep serving the main feature.

How to use your requirements document to guide AI

This is where your page pays off the most. An AI coding without context guesses, and it often guesses a different app than yours.

Put the page in the project's permanent context. Claude Code reads a CLAUDE.md file at the root, and Cursor has its own rules files. Paste your requirements doc there, along with your stack. Every request then starts from the same base.

Quote the "out of version 1" section when the AI overdoes it. Assistants are happy to suggest extra features: a dark mode, sharing, a notification. Your exclusion list gives you a ready-made answer: not now.

Ask for a plan that respects the page. Before a big piece of work, write: "here's my requirements doc, propose a plan for the main feature, don't write code yet." You'll spot right away if the plan drifts from what you decided.

Have it review the page, not just the code. Ask: "which questions in this requirements doc are vague or contradictory?" It's an underrated use of AI, and it saves you weeks of work in the wrong direction.

To go further on this, I've covered the pitfalls and checks in building an iOS app with AI.

Turning decisions into acceptance criteria

A main feature needs an observable result. For the fictional timer in this example, "the timer works" is too vague. Write instead: "I start a session, the remaining time is displayed, I can stop it and find the last completed session after reopening the app." Decide separately whether the timer should keep running with the screen locked: that choice can change the technical work.

For each feature, add three lines: action, expected result, proof. The proof can be an automated test for a calculation or an on-device check for a user flow. Also note what hasn't been tested. This small checklist keeps you from confusing a finished screen with a feature that's ready to use.

Here's a filled-in checklist for our fictional timer. These are criteria to check, not tests that have already passed:

Scoping decision	What to test	Expected result
The basic session is available without an account	Install the app and start a session without signing up	No sign-up form blocks the start
An abandoned session doesn't count toward the streak	Stop a session before it ends, then open the history	No completed session is added
History stays on the device	Finish a session, close then reopen the app	The session appears only once with the right duration
The basic timer works without a network	Turn on airplane mode and finish a session	The timer and local saving remain usable
Detailed stats are paid	Open the stats without a subscription	The offer is shown; the basic session stays available

Topics that are still vague become decisions to make. For example: what happens if the user locks the screen or changes the phone's time during a session? Don't let the agent choose silently. Write down the behavior you want, then add the case to the checklist. To run this acceptance testing on a real install, use the guide testing your iPhone app with TestFlight.

Deciding what to cut when the first version overflows

Go through each feature and ask one question: "Without it, can the user still get the promised result?" For our timer, a leaderboard with friends can wait. Finding a completed session is necessary if you promise a streak of days. A subscription screen becomes necessary only if you actually sell the stats in this version.

Write down the decision and its reason in the log of the downloadable template. You can revisit that choice after testing without losing the why behind the initial scope. The tutorial building an app with Claude Code then shows how to turn this scoping into small, verifiable requests.

For a real-world example, TradaZen changed scope after launch. Scoping is there to ship a measurable first version, then decide on the next one with real feedback.

The feature catalog trap

The natural reflex is to list everything the app "will need to do": the map, the chat, notifications, referrals, offline mode. That catalog is the most reliable sign of a project that never ships, for a simple reason: every feature added before launch delays the moment real users tell you what matters.

A good first version does one thing, and does it well. Watch out for the opposite extreme, though: Apple requires an app to go beyond a repackaged website, under rule 4.2 of the App Review Guidelines. One main feature, yes; an empty shell, no: that's the reason behind guideline 4.2.

What a mobile app requirements document shouldn't include

• A full brand style guide. A few reference screenshots are enough to start.
• A day-by-day schedule. You don't have the information to stick to it yet. A weekly goal is enough.
• A detailed technical architecture. Pick a proven stack, then let the details get decided as you build.
• "For later" features mixed in with the rest. They all go in the out-of-version-1 section.

When should you update your requirements document?

Reread it at the start of every work week. Update it only when a decision changes for a real reason: a test on your iPhone showing a screen doesn't work, tester feedback, an Apple constraint discovered along the way. If you change it every day, it's no longer scoping anything.

Once the first version is published, the page becomes the base for the next one: what was out of version 1 moves up, sorted by what the numbers tell you. The overview of the whole journey, from idea to launch, is on the building an iPhone app page.

Going from the page to a published app

If you've answered the ten questions, you've already done the work many projects skip. Next comes building the main feature, testing it on your iPhone, hooking up subscriptions and preparing your submission for Apple.

That's the path of the iOS Kit, in four steps to follow at your own pace: the first one helps you choose an app that can make money, its audience and its price, and your requirements doc is the starting point.

Not sure your idea is ready to fit on one page? The free diagnostic tells you what's blocking your project today and which step to tackle first. The home page then shows how to build a mobile app from this scoping, with Claude Code.

I'm not promising you income or approval: Apple does the approving, and the market decides the rest. Even without the kit, this template is enough to get started.

Frequently asked questions

How do you write a requirements document for a mobile app?

Keep your requirements doc to one page: ten questions, one or two sentences per answer. They cover the audience, the problem, the main feature, the business model, what happens without an account, the data that has to survive, the platform, what's out of the first version, the success signal and the constraints. If an answer runs past two sentences, the decision often hasn't been made.

What software should you use to write an app requirements document?

A simple note or a text file at the root of your project: copy the template into it, then replace each line. You can also download the template and its validation checklist (.md), no sign-up needed. To guide an AI, then put it in your project's context file.

Do you need a 40-page requirements document for an app?

No, not when you're building your own app: one page is enough. The 40-page templates you find online are written for a client ordering an app from a contractor who needs a contractual document. You decide and you build: your page settles decisions before you code and gives the AI context.

How do you give your requirements document to an AI that codes?

Put the page in the project's permanent context: Claude Code reads a CLAUDE.md file at the root, and Cursor has its own rules files. Quote the "out of version 1" section when the AI overdoes it. Before a big piece of work, ask for a plan that respects the page, without coding right away.

How do you check that a feature matches the requirements document?

For each feature, add three lines: the action, the expected result and the proof. The proof can be an automated test for a calculation, or an on-device check for a user flow. Also note what hasn't been tested, so you don't confuse a finished screen with a feature that's ready to use.

What shouldn't you put in an app requirements document?

Four things to avoid: a full brand style guide, a day-by-day schedule, a detailed technical architecture, and "for later" features mixed in with the rest. A few reference screenshots are enough to start, and a weekly goal is enough for scheduling. Features for later all go in the out-of-version-1 section.