Guide · Starting out

How to write a PRD for an app: the template I ask founders for before I quote

How to write a PRD for an app, with a copyable product requirements document template that works for developers, AI features, and Claude Code or vibe coding.

By Akash Bansal, founding engineerUpdated 5 November 20267 min read

Before I can give a founder a fixed quote, I need one document from them. It isn't a pitch deck and it isn't a list of apps they like. It's a short product requirements document (PRD): who the product is for, what each person can do with it, and what's deliberately left out. This is the template I ask for, and why each section is there.

What is a PRD?

A product requirements document describes what a product must do and why, in plain language, before anyone decides how to build it. Atlassian's guide defines it as the document that sets out a product's purpose, features and behaviour, and recommends keeping it lean and focused on shared understanding rather than exhaustive detail. For an app MVP, that means two to four pages.

It's not a technical spec. The PRD is yours: the problem, the users, the rules of your business. The engineer turns it into a design doc: the data model, the architecture, the services. Mixing the two is how founders end up specifying database tables and forgetting to say what happens when a customer cancels.

Why does a PRD matter before you hire a developer?

Because the cost of an app is mostly decided by what's in version one, and a PRD is where you decide it. It also makes estimates trustworthy. Steve McConnell's Cone of Uncertainty white paper shows that estimates made at the idea stage can be off by 4x either way, and that the range narrows to roughly 0.67x–1.5x once requirements are complete. The PRD is how you get from the wide end of that cone to the narrow end.

In practice, a PRD does three jobs at once:

1. It makes quotes comparable. Send the same PRD to every builder, and differences in price become differences in approach, not in what they imagined.
2. It becomes part of the contract. A good statement of work points to the PRD as the scope; my plain-English SOW template does exactly that.
3. It's the test. The acceptance criteria in the PRD are how you decide a milestone is done.

How do you write a PRD for an app, step by step?

Start from the problem and the people, then describe what each person can do in plain verbs, then cut. Don't start from screens or features you saw in another app.

1. Write the problem in two sentences. Who has it, and what they do about it today. If today's workaround is "a spreadsheet and WhatsApp", say so; it tells the builder what you're competing with.
2. List the types of user. Customer, provider, admin. Each extra type of user is the most expensive single choice in an app, so be sure each one needs its own login in version one.
3. For each user, write what they can do. As verbs: "book a class", "cancel up to 12 hours before", "see today's bookings". These are your user stories without the jargon.
4. Write the rules. The business logic only you know: cancellation windows, pricing, who sees what, what happens on a refund. This is where most of the real complexity hides.
5. Write what's out. A list of things you've decided not to build yet. It's the most valuable section, and the one founders skip.
6. Write how you'll know it works. One acceptance check per core action, and one measurable launch goal.
7. List the open questions. Things you don't know yet. A builder would rather see "not sure whether we need refunds in v1" than discover it in week five.

Then do a deletion pass. For every item, ask whether the first ten customers would leave without it. If not, move it to "later". If you never move anything back, you probably didn't cut enough. Use the app cost calculator while you do this; watching the range shrink is motivating.

A PRD template you can copy

Replace everything in [brackets]. Keep each section short; a missing answer is fine if it's listed under open questions.

1. Summary

Product: [name]. One line: [who it's for] can [do what] without [today's pain]. Version: [v1, date]. Owner: [your name].

2. Problem

[Two to four sentences. Who has the problem, how often, what they do about it today, and what that costs them.]

3. Evidence

[What tells you people want this: waitlist size, pilot customers, letters of intent, a manual version people already use. If there's none yet, say so.]

4. Users

5. What each user can do (v1)

[Member] can:

1. [sign up with email or Google]
2. [see this week's classes and book one]
3. [pay by card at booking]
4. [cancel up to [12] hours before and get a refund]

[Admin] can:

1. [create and edit classes]
2. [see bookings per class]
3. [issue a refund]

6. Business rules

• [Cancellation: full refund up to [12] hours before; none after.]
• [Capacity: a class closes when [20] people have booked.]
• [Who sees what: members never see other members' details.]

7. Platforms and integrations

Platforms: [web / iOS / Android]. Integrations: [payments: Stripe or Razorpay; email; calendar; anything you already use that must connect].

8. Out of scope for v1

• [Memberships and class packs]
• [A second studio location]
• [Chat between members and teachers]

9. Acceptance criteria

1. [A new member can sign up, book and pay for a class on their phone in under two minutes.]
2. [A cancellation 13 hours before a class refunds automatically; one 11 hours before doesn't.]
3. [The admin sees a new booking within a minute of it being made.]

10. Launch goal

[One number you'll check after launch: e.g. "50 paid bookings in the first month".]

11. Constraints

[Budget range, launch date and why, regulated data (health, finance, children), languages, anything legal.]

12. Open questions

• [Do we need refunds in v1, or can the owner handle them manually?]
• [Is a web app enough for launch, or do members expect a store app?]

How do you write a PRD for an AI feature?

Use the same template and add three sections, because AI features fail differently: they're usually almost right, and "almost" is the problem.

1. Examples. Ten to twenty real inputs with the output you'd accept for each. For a résumé screener: real résumés (anonymised) and the score you'd give. These become the test set the builder measures against.
2. Never and unsure. What the feature must never do (invent a price, give medical advice), and what it should do when it isn't confident: say so, or hand off to a human.
3. Volume. How many times a day it will run. AI is priced per call, so volume decides running cost and sometimes the choice of model.

This is how I approach AI products myself. On Brahmo, which grades long-form exam answers, the scoring runs against a weighted rubric and a human expert can override any grade. The rubric and the override are product requirements, not implementation details: they decide what "a correct grade" means and who has the last word. The Duolingo-style exam prep app story shows those requirements shaping a whole product. More on that pattern in multi-LLM scoring.

How do you write a PRD for Claude Code or vibe coding?

The same document, saved in the repository as a file the tool reads, with acceptance criteria phrased as checks the tool can run. Anthropic's Claude Code best practices suggest exactly this: when you haven't worked out what you want, ask Claude to interview you until it could write the spec, write it to a SPEC.md file, then start a fresh session that builds from it and reviews the result against it.

Three adjustments help with any AI coding tool:

• Keep the out-of-scope list prominent. AI tools are eager. Without a written "not in v1", they'll add features you didn't ask for, and each one is code you now maintain.
• Write rules as testable statements. "A cancellation 11 hours before a class is refused" can become a test. "Cancellations should be fair" can't.
• Add the non-functional basics. Who can see whose data, what must be logged, where secrets live. AI-generated apps most often go wrong on access control, which is the first thing I check in a vibe-coded app rescue.

What are the most common PRD mistakes?

• Describing another app. "Like Uber, but for X" tells a builder almost nothing about your rules. Write your rules.
• Specifying screens instead of actions. Screens are the builder's job; what users must be able to do is yours.
• No out-of-scope list. Everything not written down is assumed to be in, by someone.
• Too long. A thirty-page PRD for an MVP usually describes version three.
• Never updated. When you agree a change, update the PRD and bump the version. Atlassian calls it a living document; treat it like one.

Once you have a PRD, the rest of the process (choosing a builder, the build itself, launch) is in how to build an MVP step by step. And if you'd like a fixed quote against yours, send it over: that's the first thing I read. Here's how I work.