1. The app in one sentence
What to write: Describe what the app does and for whom, in one sentence.
- What would you say if someone asked what the app is for?
- Which word would a user type into an app store or search engine to find it?
Spacewalk guides · Free template
App requirements document template
Published by Spacewalk
An app requirements document tells a developer what to build before anyone writes code: who the app is for, the main task it handles, what the first release must include, and who will own the accounts and source code afterwards. This free template covers those points in 11 sections. It works for mobile apps on iPhone and Android and for web apps. It is a client-side brief, shorter than a product requirements document (PRD) or a formal software specification.
The template is for founders, small-business owners and product owners who are about to brief a developer or studio. Fill in what you know, mark the rest as an open question, and send it with your enquiry. Below the template, we have filled in every section for Countstead, our own inventory app, so you can see the level of detail that helps.
On this page
- The template's 11 sections, from a one-sentence description of the app to ownership and handoff.
- A worked example with every section filled in for Countstead 1.8, a shipped iPhone and iPad app.
- The same template as a Word document (.docx) and as plain-text Markdown (.md).
Download the template
Version 1 · 28 October 2026
The template is free and needs no sign-up or email address. Both files contain the same 11 sections as this page. We checked the Word file in Apple Pages on 28 October 2026; it has not been tested in Microsoft Word or Google Docs yet.
The app requirements template
Copy each heading into your own document, or download one of the files above. A sentence or two per section is enough to start a useful conversation. Sections 1 to 4 describe the product, sections 5 to 8 how it runs and what it connects to, and sections 9 to 11 ownership, limits and open questions.
2. Who will use it
What to write: The people who will use the app, and the situation they are in when they open it.
- Are they customers, staff, or both?
- Where are they and what are they doing when they use it?
- What do they use today instead: a spreadsheet, paper, another app?
3. The main task
What to write: The one job the app must do well, and how you will know it does.
- What does a user need to finish in a single visit?
- What should be different for them after the first week of use?
4. First release
What to write: The features the first release (often called the minimum viable product, or MVP) cannot launch without, in order of importance. Keep later ideas on a separate list.
- Which features would you remove last?
- Which ideas can wait until people are using the app?
- Is anything deliberately out of scope?
5. Platforms and devices
What to write: Where the app needs to run on launch day.
- iPhone, iPad, Android phones and tablets, a web browser, or a mix?
- Does it need the camera, location, notifications or other device features?
6. Data, accounts and connection
What to write: Where information is stored, whether people sign in, and what happens without an internet connection.
- Does each person's data stay on their device, or is it shared through a server?
- Do users need an account? Which sign-in methods?
- Which tasks must still work offline, and how should changes sync later?
7. Payments and integrations
What to write: Anything the app must connect to, and how it will make money.
- Subscriptions, one-off purchases, ads, or free?
- Existing systems: a website, database, payment provider, accounting or stock system?
- File import or export: spreadsheets, PDFs, CSV?
8. AI features
What to write: If the app uses an AI model, a few examples of the input and the answer you would consider useful. Write "None" if it does not.
- What will the user give the model: text, a photo, a document?
- What should a good answer look like?
- What happens when the answer is wrong or incomplete?
9. Ownership and handoff
What to write: Who will own each account and asset after launch, and who supports the app.
- Who holds the Apple Developer and Google Play developer accounts? Apple allows only one Account Holder per developer account.
- Who owns the source code, domain, server and app store listings?
- Who writes the privacy policy and the App Store privacy details? Apple asks for the practices of third-party code in the app as well.
- Who fixes bugs and updates the app after launch?
10. Constraints
What to write: Dates, budget, rules and anything else that limits the project.
- Is there a launch date, and what depends on it?
- A budget range, if you have one.
- Regulations or security requirements in your industry. For mobile app security, the OWASP Mobile Application Security Verification Standard (MASVS) is a common reference.
11. Open questions and attachments
What to write: What you have not decided yet, and anything that shows the idea.
- Decisions you want help with.
- Sketches, screenshots, a current spreadsheet, or apps you like and why.
Worked example: Countstead 1.8
Countstead is an inventory app for small businesses on iPhone and iPad. It is our own app, not client work. We filled in the template as if we were briefing a developer to build the app as it ships today in version 1.8.
| Section | Countstead |
|---|---|
| 1. The app in one sentence | An inventory app for small businesses on iPhone and iPad: record what comes in and goes out, count what is on the shelf, scan barcodes and see what is running low, even with no internet connection. |
| 2. Who will use it | Shops, market stalls, makers, resellers, cafés and kitchens, salons and repair workshops. They keep physical stock, have outgrown a spreadsheet, and don't want an ERP or warehouse system. |
| 3. The main task | Record stock movements and counts where the stock is, then see what is running low. |
| 4. First release | Must have: items with a photo, SKU, barcode, unit and unit cost; stock in, stock out, counts, corrections and transfers, each kept in the item's history; barcode and QR scanning; a low-stock level per item and location with a Low Stock view. Paid plan (Countstead Pro): unlimited items, more than one location, sync across devices, alerts, reorder suggestions. Out of scope: looking up products in an online catalog. |
| 5. Platforms and devices | iPhone first, adapting to iPad. No Android or web app. Uses the camera for barcode and QR scanning. |
| 6. Data, accounts and connection | Items, counts, locations and history stay on the device and work without a connection. No account is needed to start. Sync across devices is optional, part of Countstead Pro, and set up separately with Sign in with Apple. |
| 7. Payments and integrations | Free for up to 30 active items at one location; Countstead Pro is an optional subscription. Import up to 10,000 rows from a CSV file or Excel workbook, and export everything as CSV. Barcodes are matched against the user's own items; nothing is looked up online. |
| 8. AI features | None. |
| 9. Ownership and handoff | Our own product, so the Apple Developer account, source code, countstead.com domain and App Store listing all stay with us. The privacy policy is published at countstead.com/privacy/. |
| 10. Constraints | Local use must work with no connection and no account. The app is available in English, German, French, Spanish, Italian, Portuguese, Japanese, Korean and Indonesian. Budget and launch date are left out because this is our own product; a client brief should include them. |
| 11. Open questions and attachments | For a client brief, this is where screenshots of the current spreadsheet, the list of stock locations and any barcode labels already in use would go. |
How to fill it in well
- Write the main task (section 3) first. Once it is clear, it is easier to decide what belongs in the first release.
- Keep the first release separate from later ideas. A short must-have list is easier to estimate and to test with real users.
- Write "unknown" instead of guessing. An open question tells the developer where you need advice.
- Show real examples. A current spreadsheet, a paper form or a screenshot explains a workflow faster than a description.
- Leave out confidential data. Describe customer records, passwords and private documents rather than attaching them.
Using it for a web app or an AI feature
The same 11 sections work as a web app requirements template. In section 5, list the browsers and screen sizes you need to support. In section 7, name the systems that own each record, such as an existing database or booking service. For more on planning a web project, see web application development.
If the app includes an AI feature, section 8 matters most. A few real inputs and the answers you would accept are a better starting point than the name of a model. Our AI integration services page explains how we plan and evaluate these features.
For iPhone and Android projects, our mobile app development page covers native and cross-platform choices, offline behavior and release preparation.
Questions about app requirements documents (FAQ)
What is an app requirements document?
An app requirements document describes what an app must do before development starts: its users, main task, first-release features, platforms, data, integrations, ownership and constraints. A developer uses it to estimate the work, ask the right questions and agree on the scope of the first release.
What makes a good app requirements template?
A good template asks about the users, the main task, the first release, platforms, data and offline use, payments and integrations, AI features, ownership of accounts and code, and constraints. It should be editable without signing up, and a filled-in example shows how much detail each section needs.
Is this the same as a PRD or a software requirements specification?
It covers less. A product requirements document (PRD) is usually written by a product team for an engineering team, and a software requirements specification goes into formal detail; ISO/IEC/IEEE 29148 is the international standard that describes what one contains. This template is a client-side brief, sometimes called an app specification: enough for a developer to understand the project and start a scoping conversation. If a team will build and test against every requirement line by line, treat the brief as the starting point for that fuller document.
How detailed should each section be?
A few sentences or a short list per section is enough to start. Add detail where a decision affects cost or schedule, such as offline behavior, sign-in, payments and integrations. Mark everything you are unsure about as an open question rather than guessing.
Can I use this template for a web app?
Yes. All 11 sections apply. Replace device questions with the browsers and screen sizes you need, and list the existing systems the web app must connect to. Leave section 8 as "None" if there is no AI feature.
What should I leave out of the document?
Leave out passwords, customer records and confidential files. Describe what the data contains and who can access it instead. You can share the details later, once you have agreed how they will be handled.
Send us your brief
When all 11 sections are filled in or marked as open questions, email the brief to hello@spacewa.lk with your target platforms and any date you are working towards. Spacewalk builds web applications, mobile apps and AI features, and is based in Colombo, Sri Lanka, and available worldwide.