Spec-driven mobile app development with AI: plan first, build second

Three structural reasons, none of them nostalgia for process.

Agents amplify ambiguity. A human developer who hits an unclear requirement asks you. An agent resolves it — instantly, silently, plausibly, and according to no product strategy at all. Every ambiguity in your head becomes a concrete decision in the codebase. A spec is where you make those decisions on purpose, while they still cost words instead of rework.

Review scales at the plan level, not the code level. A product person cannot meaningfully review 3,000 lines of Swift. The same person can absolutely review one page saying what those lines will do — the scenarios covered, the risks flagged, the things deliberately left out. Spec-first moves the review to the altitude where product judgment actually operates.

Consistency is a memory problem, and documents are memory. By feature ten, an unplanned codebase contains nine private interpretations of your product. A PRD at the root and a spec per feature give the agent — every session, every model, every future contributor — the same source of truth to build against. The plan is not bureaucracy; it is the app's long-term memory.

The structure is built into the workflow, not bolted on (the docs walk it end to end).

Day one: the PRD. You describe your product — prose, screenshots, PDFs, Figma links all count as input. A short wizard settles the structural facts (template, platforms, identifiers), and the template decision matters more than it looks: per the docs, it determines "which architecture your code is written against", and that choice is permanent for the project. Then the agent's first turn does three things: reads everything you gave it, writes a structured PRD.md at the project root, and plans a workable first iteration.

Every feature after: a mini-spec. Feature work lands in numbered folders — specs/001-<feature>/spec.md, 002, 003 — so the project accumulates a reviewable history of intent alongside its code. Each spec is a mini-PRD for one feature, written by the agent, approved by you, before implementation starts.

The switch that enforces the discipline: the Plan toggle. With Plan on, the agent produces "a structured implementation plan (a feature spec) without writing code." With Plan off, it "writes code, builds the project, debugs, fixes, and iterates with you." The docs' recommended rhythm is the whole method in one line: "Plan on (spec) → Plan off (implement) → Plan on (next feature) → Plan off (implement)." Plan-first for new projects and complex features; toggle off for the fast loop — builds, debug sessions, one-off fixes — where a spec would be ceremony (modes and prompts).

From the docs, a spec.md for an existing project covers: Overview · User Scenarios · Technical Approach (Architecture, Existing Code to Reuse) · Implementation Steps, phased · Files to Create/Modify · Risks & Open Questions · Testing Strategy.

Read that list with product-manager eyes and it maps onto instruments you already own. User Scenarios are your use cases — the concrete "a user does X and sees Y" that separates a requirement from a vibe. Risks & Open Questions is the section PMs live in: the agent surfaces what it is unsure about before building, which is precisely the conversation you used to have with an engineering lead — except available at midnight. Testing Strategy is acceptance criteria wearing engineering clothes. And Implementation Steps, phased is scope control: you can strike phase three from the plan with one comment, which is infinitely cheaper than deleting shipped code.

Two sections deserve special respect from non-engineers. Existing Code to Reuse is what keeps feature twelve consistent with feature two — the agent explicitly accounts for what is already there instead of reinventing it. And Files to Create/Modify gives you a blast-radius check without reading code: a "small tweak" that plans to touch eighteen files is telling you something, and you get to hear it in the plan rather than the diff.

This section is advice, not documentation — the docs deliberately don't prescribe models, because Modaal is bring-your-own-agent and the choice is yours. But the economics of spec-driven work point one clear direction:

Planning is few words with large consequences — give it your strongest model. A spec is a handful of turns whose output steers everything downstream; a subtle misjudgment in the plan multiplies through every implementation session that follows. This is exactly where a top-tier model earns its price, and because planning turns are few, it barely dents a subscription's limits.

Implementation is many turns with small, checkable consequences — a mid-tier model is usually plenty. The build loop is write-compile-fix: each step is verified by the compiler and by your eyes on the running app, so raw model brilliance matters less than iteration speed. Model families are tiered for exactly this split — in Claude's line-up, for example, the mid-tier Sonnet sells at a fraction of the top tier's API price, and most supported agents let you switch models mid-session.

The practical rhythm: switch your agent to its strongest model, toggle Plan on, get the spec, argue with it until it is right. Then switch down, toggle Plan off, and let the loop run. You are spending intelligence where it compounds and speed where it iterates — the same way you would staff a team.

Here is the quiet career fact inside all of this: spec-driven AI development is the first engineering workflow whose scarce input is product skill. Writing unambiguous requirements, thinking in user scenarios, ranking risks, cutting scope — the things a good PM does before lunch — are precisely what the agent cannot supply and precisely what the workflow consumes.

The failure mode to avoid is bringing only half the discipline: PMs who approve every plan unread are vibe coding with extra steps. The plan review is the job — push back on scenarios that miss an edge case, strike phases that gold-plate, answer the open questions with actual product decisions. Everything you'd do to a junior engineer's design doc, done to the agent's, with the same standards.

Where this connects to the rest of the craft: validate the idea before you spec it (how to test your app idea), bring design direction the agent can execute (designing with AI, from screenshots to design system), and learn the prompting patterns that make native UI come out native (prompting agents for mobile UI). The spec sits in the middle of that chain — downstream of validation, upstream of every line of code.