From PRD to app: how a product requirements document becomes a working mobile app

In Modaal, the new-project composer takes the whole document: “Type your idea into the composer… You can attach files too: a PRD, a screenshot, a design doc, a Figma link.” Paste the one page as text and attach any sketches. In another tool, the equivalent is the first message plus the project’s instructions file.

Before the agent writes anything, the wizard asks for a template, and the docs are explicit about what that choice does: “The template determines what is created on disk before the agent’s first turn: which targets exist, which platforms they run on, and — most consequentially — which architecture your code is written against.” The templates are Duet (iPhone and Android together, or iPhone now with Android later), Quick prototype, Production app, 2D game, Watch and Empty project. The choice is binding: “MVVM has no migration path in Modaal… going to production means starting a second project.”

What the PRD decides here. The Platform line. RunClub’s PRD says iPhone first — the organiser’s club is on iPhones — with Android a maybe. The docs’ rule for that case: pick a Duet card “when Android is even a maybe.” So: Duet, iPhone now, Android later. A PRD that says “iPhone only, ever” can take Production app. A PRD that says “just to see” takes Quick prototype and accepts that the real build starts again. iOS or Android first has the longer argument; the PRD’s Platform line is where you record the outcome.

The check. Read the template’s one-line description against the PRD’s Platform and “must never break” lines before pressing Create. This is the only step you cannot redo with a comment.

The first turn does three things, per the docs: “It reads your description (and any attachments — images, PDFs, Figma links)”, “writes a structured PRD.md at the project root”, and “plans a workable first iteration and writes it to specs/001-<feature>/spec.md.”

Open PRD.md. It is the agent’s restatement of your page in its own structure. Read it once for what changed: a flow it merged, a constraint it dropped, a feature it added because most apps have one. For RunClub, the things to look for are an “account” or “login” the agent introduced for the organiser role (the PRD says no forced accounts), a “history” screen (v1 leaves it out), and whether “works offline” survived as a constraint rather than a nice-to-have. Edit PRD.md directly or tell the agent what to change; it is a file in your project, not the agent’s private memory.

The check. Every line of the PRD’s “what v1 deliberately leaves out” is absent from PRD.md, and every line of “must never break” is present. If not, fix it now — every later spec is planned from this file.

Open specs/001-<feature>/spec.md. Its sections, from the docs: Overview · User Scenarios · Technical Approach (Architecture, Existing Code to Reuse) · Implementation Steps (phased) · Files to Create/Modify · Risks & Open Questions · Testing Strategy. The first feature should be the first core flow; for RunClub, member check-in.

Read the spec with the PRD beside it, section by section:

• Overview should be the PRD’s job sentence narrowed to this feature: one-tap check-in from the run screen.
• User Scenarios should be one scenario per ending, which is the rule the template page sets. RunClub’s check-in has four endings: checked in; already checked in; no signal, so it is written locally and synced later; run not yet open. If the spec has one scenario — “user checks in” — send it back: the three other endings are where the agent will otherwise guess.
• Technical Approach should match the PRD’s constraints. RunClub’s: “one screen showing the current run; a check-in action that writes locally first, then to the shared list.” “Writes locally first” is the offline constraint becoming architecture. If the approach reads “calls the server, then updates the screen”, the constraint was lost between PRD.md and the spec.
• Implementation Steps are phased, and phases are what you strike. If phase three is “add member profile”, strike it: the PRD leaves accounts out.
• Files to Create/Modify is the blast-radius check. A first feature touching four or five files is normal; one touching twenty is planning something the PRD did not ask for.
• Risks & Open Questions should contain what the PRD flagged. RunClub’s spec lists the offline sync conflict and how a member is identified when clubs share a code. If a risk you wrote in the PRD is missing here, add it as a comment.
• Testing Strategy should be the scenarios again, phrased as what you will tap: check in with Wi-Fi off, reopen the app, confirm the check-in is still there and syncs when the signal returns.

The check. Approve the plan only when each of the seven sections traces to a line of the PRD. Before approval a change is a comment; after it, a code diff.

With the Plan toggle off, the agent “writes code, builds the project, debugs, fixes, and iterates with you.” The docs’ rhythm is “Plan on (spec) → Plan off (implement) → Plan on (next feature) → Plan off (implement)” — one feature per cycle.

Run the app in the simulator when the agent reports the build is green, and go through the Testing Strategy list in order, not the happy path only. For RunClub: open the run screen; tap check-in; turn the simulator’s network off (or use a device in airplane mode); tap again; kill and relaunch; turn the network on; watch the organiser’s list.

When something is wrong, describe the screen, not the code. The docs: “Point at the screen and describe the bug: the agent reads screenshots, console logs, and the live view hierarchy…” “The check-in button is still enabled after I tapped it” is a bug report the agent can act on. “Fix the state management” is a guess.

The check. Every scenario in the spec’s Testing Strategy passes on a device, including the offline one. Then commit — the project is a Git repository on your Mac — and move to the next feature.

Toggle Plan on and ask for the second core flow: the organiser sees who has checked in, live. The new spec lands in specs/002-…/spec.md. Two sections matter more now than they did for feature 1.

Existing Code to Reuse. The organiser’s live list reads the same shared check-in list that feature 1 writes. The spec should name the file from feature 1 it reuses; if it plans a second data model for “organiser view”, send it back. This section is what keeps feature twelve consistent with feature two.

Files to Create/Modify. Feature 2 should modify the shared list and add one screen. If it plans to modify the check-in screen from feature 1, ask why; sometimes there is a reason (a role switch), and sometimes the agent is redesigning what already works.

Feature 3 — the organiser creates next week’s run in under a minute — is where the PRD’s “must not do” list earns its place: the spec will offer a form with eight fields; the PRD said under a minute; strike the fields until it is a name, a date and a start time.

The check. After feature 3, all three core flows from the PRD exist and pass their scenarios. That is version 1 as the PRD defined it. Anything else the agent proposed lives in the specs/ folder as a struck phase, not in the app.

With three screens working, the app looks like the agent’s defaults. The docs’ design workflow turns a handful of reference screenshots into a north-star screen, “the exemplar every later screen follows”, and then three files: “design-system.md, DesignTokens.swift, and AGENTS.md.” After that, each new screen is generated against those files. The docs’ rule for the rounds: “Each round, give reactions, not specs.” For RunClub the design constraint is in the PRD’s first line — cold hands, thirty seconds — so the reaction is “the check-in target is too small for a gloved thumb”, and the design system records the tap-target size that resolves it.

The check. Three files exist in the project; the run screen matches the north-star; the check-in target passes the gloved-thumb test on a real phone.

The PRD’s “how we’ll know it worked” line is not decoration; it is the last test. RunClub’s: “the organiser doesn’t bring the paper list on week three.” That test needs the organiser, on a real run, with the real club. On Modaal’s Pro plan, TestFlight and App Store distribution are part of the flow, under your own Apple developer account; the free plan builds one project on one platform with unlimited prompts, and Pro is €9 per user per month billed annually (€15 monthly) — pricing. How to make an iPhone app covers the TestFlight steps.

Week one: the organiser brings the paper list and the app; both are used. Week two: the app, with the paper list in a pocket. Week three: the PRD’s line is either true or false. If false, the reason goes into the PRD as a new constraint — “members forget the club code” — and the next spec is planned from it.

The check. The PRD is edited after week three. If the PRD has not changed after week three, the success line has not been tested.

The sequence is the same with any agent that accepts a plan step. Keep the PRD as a file at the project root and name it in the agent’s instructions file (AGENTS.md, CLAUDE.md or the tool’s equivalent). Before each feature, ask for a plan with the seven sections above and refuse code until it exists. Keep the plans in a specs/ folder so the history of intent is next to the code. Run the scenarios yourself, on a device, before the next plan. What Modaal adds is that the first turn produces PRD.md and specs/001 without being asked, the Plan toggle separates the two modes, and the output is a native Xcode project — and an Android Studio project when the PRD’s Platform line says both — in Git on your Mac. Series context: why product people can ship now and can a product manager build an app without developers.