FREE TOOL · RUNS IN YOUR BROWSER

Product requirements document (PRD) template

A one-page PRD for an app: problem, users, goals, user stories, screens, data, monetization, metrics and a launch checklist. Copy it, download it, or see it filled in.

File

Show

A one-page PRD for an app: problem, users, goals, user stories with acceptance criteria, screens, data, monetization, metrics, risks and a launch checklist.

# PRD: [App name]

- Owner: [your name]
- Status: Draft
- Last updated: [date]

## 1. Problem

<!-- What hurts today, for whom, and how they deal with it now. One paragraph. If you can't name the person, the problem isn't clear yet. -->

[Who] struggles with [what] because [why]. Today they [current workaround], which [why it falls short].

## 2. Users

<!-- The first user, as specific as you can make them. Not "everyone". -->

- Primary user: [who, in one sentence]
- What they're trying to get done: [the job]
- Where they'll find the app: [App Store search, a community, word of mouth]

## 3. Goals and non-goals

<!-- Non-goals are what keeps the first release small. Write them down, or your coding agent will build them. -->

Goals for the first release:

- [Goal 1]
- [Goal 2]

Non-goals (not in this release):

- [Something people will ask for that waits]
- [Something tempting that isn't the point]

## 4. Core features

<!-- Three to five user stories. Each one gets acceptance criteria: how you'll know it works. Must = the release doesn't ship without it. -->

| Priority | User story | Acceptance criteria |
|---|---|---|
| Must | As a [user], I want to [action] so that [outcome]. | [What has to be true when it works] |
| Must | As a [user], I want to [action] so that [outcome]. | [What has to be true when it works] |
| Should | As a [user], I want to [action] so that [outcome]. | [What has to be true when it works] |

## 5. Screens

<!-- Every screen in the first release, and what it's for. If a screen isn't here, it isn't in the release. -->

| Screen | What it's for | Key elements |
|---|---|---|
| Onboarding | [First impression, permissions] | [ ] |
| Sign in | [Account creation and sign-in] | [Email, Apple, Google] |
| Home | [The main job] | [ ] |
| Settings | [Account, subscription, delete account] | [ ] |

## 6. Data

<!-- What you store, where, and who can see it. This is what the stores' privacy questions will ask about. -->

| Data | Stored where | Who can see it |
|---|---|---|
| Account (email, name) | [Server] | The user |
| [Your main data] | [Device / server] | [ ] |

- Account deletion: users can delete their account inside the app.
- Personal data shared with third parties: [none / which services, why]

## 7. Monetization

<!-- Free, one-time purchase or subscription. And the line between free and paid. -->

- Model: [free / one-time / subscription]
- Price: [price, and trial if any]
- Free includes: [ ]
- Paid unlocks: [ ]

## 8. Success metrics

<!-- One number that says the app works for people. Pick it before launch, not after. -->

- Main metric: [e.g. % of new users who do the core action twice in their first week]
- Target for the first 30 days: [ ]
- Also watched: [activation, retention, conversion to paid]

## 9. Risks and open questions

<!-- What could kill it, and what you still don't know. Answer these before you build, not during. -->

- Risk: [ ]
- Open question: [ ]

## 10. Launch checklist

- [ ] Apple Developer Program ($99 a year) and Google Play account ($25 once)
- [ ] Privacy policy and support URL
- [ ] Account deletion inside the app, if users can create an account
- [ ] Store listing: name, subtitle, description, screenshots
- [ ] Testers: TestFlight on iOS; on Google Play, a new personal account needs a closed test with at least 12 testers for 14 days
- [ ] Analytics and crash reporting working in the release build
- [ ] Review notes for Apple, with a test account if the app needs sign-in

Don't want to fill it in by hand? Answer six questions and the PRD generator writes the PRD, PRODUCT.md and AGENTS.md for you.

Open the PRD generator

Runs in your browser. Nothing is sent anywhere.

Your PRD is the plan. NativeExpress is the head start.

Sign-in, payments, a database and AI features already run in the template, so your PRD's user stories are what's left to build. Start from it, plan it on a call, or have us build it with you.

DO IT YOURSELF, FASTER

The NativeExpress template

A running iOS and Android app with sign-in, payments, a database and AI built in. One payment, full source, lifetime updates.

Get the template~~$299~~$229

GET UNSTUCK

Consulting call, $149

A working session on architecture, setup or your launch plan. You bring the problem, you leave with the decision made.

HAVE IT BUILT

Done for you

We build and launch the app with you, on your stores, under your brand. Start with a short call so we can scope it.

Book a 30-min intro call

What a PRD is

A product requirements document, or PRD, says what you're building, who it's for and what counts as done. It doesn't say which database to use or how the code is structured. It says what the product has to do, and why, so everyone working on it makes the same decisions without asking each other every time. Atlassian's guide to requirements lists the classic parts: purpose, user stories, assumptions, what's out of scope and open questions. This template keeps those and adds what an app specifically needs: screens, data, monetization and the store launch.

What to put in each section

Problem and users

Name one person and one problem. "Busy people who want to be more productive" isn't a user. "A first-time plant owner who keeps overwatering" is. If you can't write the problem in one paragraph, the idea isn't ready for a PRD yet.

Goals and non-goals

Non-goals are the most useful part of the whole document. Every feature you don't write down as "not now" is a feature someone will start building, and with a coding agent that someone works fast.

Core features as user stories

Write each feature as "As a [user], I want to [action] so that [outcome]", and give it acceptance criteria: what has to be true when it works. Three to five Must stories is a first release. Twelve is a roadmap.

Screens and data

List every screen in the release. If it isn't on the list, it isn't in the release. For data, write down what you store, where and who can see it. The App Store and Google Play both ask about this in their privacy questions, so you'll need the answers anyway.

Monetization and success metrics

Decide the model (free, one-time or subscription) and the line between free and paid before you build. It changes the screens. Then pick one number that says the app works for people, before launch, so you can't move the goalposts afterwards.

Launch checklist

The part most PRD templates skip, and where first apps get stuck. Both stores want a privacy policy. If people can create an account, Apple requires that they can delete it inside the app. And a new personal Google Play account has to run a closed test with at least 12 testers for 14 days before it can publish, so find your testers early.

Using the template with an AI coding agent

These days I let Claude write most of my code, and a coding agent is only as good as what it knows about your app. It starts every session from zero. Put PRD.md in the root of your project and point your agent's instructions file at it: CLAUDE.md for Claude Code, AGENTS.md for Codex, Cursor and most others. Then the agent reads your non-goals before it builds a feature you didn't ask for.

The PRODUCT.md variant above is the same decisions written as tables an agent can parse: platforms, features, integrations, monetization and design inputs. It's the file our PRD generator writes, and the first file the NativeExpress setup skill reads.

Where PRDs go wrong

Too long. Nobody reads ten pages, and an agent loads every word into every session. One page per release is plenty.
No non-goals. Then scope grows quietly until the release never ships.
Stories without acceptance criteria. "Users can sign in" isn't done until you've said with what, and what happens when it fails.
Never updated. When a decision changes, change the PRD first, then the code.

FAQ

What is a PRD?

A product requirements document (PRD) describes what a product has to do, who it's for and how you'll know it works. It covers the problem, the users, the goals and non-goals, the features as user stories, and the success metrics. It doesn't describe how the code is built.

What should a PRD include?

For an app: the problem, the target user, goals and non-goals, three to five core user stories with acceptance criteria, the list of screens, what data you store and who can see it, how the app makes money, one main success metric, risks and open questions, and a launch checklist for the App Store and Google Play.

What is the difference between a PRD and a spec?

A PRD says what the product has to do and why. A technical spec says how it will be built: the architecture, the data model, the APIs. The PRD comes first and the spec answers it. For a small app built with a coding agent, the agent often works out the spec from a good PRD.

How long should a PRD be?

For a first release of an app, about one page. If it runs much longer, the release is probably too big. Split it into a first release and later ones, and keep the later ideas under non-goals.

Is this PRD template free?

Yes. Copy it or download it as a Markdown file, with no sign-up. It runs entirely in your browser. If you'd rather answer a few questions than fill it in by hand, the PRD generator writes it for you.