--- slug: export-implementation-plan title: "Turn Your App Spec into a Step-by-Step Build Plan" excerpt: "Draftlytic now exports an implementation plan: a phased build order generated from your spec, ready to drop into Cursor, Lovable, or any AI coding tool." primaryKeyword: "app implementation plan" publishedAt: 2026-04-23 readingTimeMin: 6 author: "Robert Boylan" tags: - implementation-plan - app-planning - ai-coding-tools - indie-dev - prd --- You've got the spec. It says what the app does, who it's for, what the tech stack is. The features are listed and prioritised. You didn't skip the planning. But you open Cursor (or Lovable, or Claude) and the first thing it needs answered isn't "what should the app do?" It's "what do I build first?" And for that, a requirements document isn't quite the right shape. A spec tells the model _what_. An implementation plan tells it _when, in what order, and why that order makes sense_. Those are different documents. Collapsing them into one makes both worse. The new implementation plan export in Draftlytic does the second one. You fill in the spec, click Export, choose "Implementation plan document," and get back a phased build order in markdown. This post walks through what goes into it, when the additive mode kicks in, and what to do with the file once you have it. ## What an implementation plan actually is An implementation plan is a build order. Here's what to set up first, here's the second phase, here's what you only add once the earlier pieces are working. Not the design, not the requirements. The sequence. This matters more with AI coding tools than it ever did when developers hand-wrote every line. When you drop a whole feature list into Lovable or Cursor and say "build this," the model makes its own call about sequence. Sometimes that's fine. Often it picks a poor starting point: wiring auth before you have any idea what's being authenticated, or building the design system before there's a data model to put data in. A clear implementation plan makes the sequence explicit. Phase 1 is the core data model. Phase 2 is auth. Phase 3 is the first user-facing feature. Now the model knows where it is and what it's working toward. When you get to Phase 3, you're not explaining Phase 1 all over again. Draftlytic generates this from what you've already specified. It reads your features, tech stack, data model, platforms, and constraints, and outputs a phased plan that reflects what you actually decided -- not a generic "build auth first" template. For more on what makes a good spec to begin with, see [what a PRD actually is and why it matters](/what-is-a-prd). ## Where to find it It's in the Export dropdown on any project page, under "Implementation plan document." You'll need a paid plan -- free accounts see the option with an upgrade prompt. The modal gives you two choices: - **Standard export (40 credits).** Generates a plan based on the current version's outstanding features, plus everything Draftlytic knows about your project: tech stack, data model, platforms, external services, audience, current milestone, and the design and business fields. - **Include full project context (50 credits).** Adds the fuller set of details to the model's context -- all the personas, design choices, business setup, admin requirements. Useful for complex projects where those decisions affect the build order in non-obvious ways. Both options download a `.md` file you can drop straight into Cursor, Claude, Lovable, or wherever you're working. ## The additive mode: planning around what you've already built Here's the bit that might not be obvious from the feature name: if your project has completed features, the implementation plan doesn't pretend you're starting from scratch. Draftlytic reads your completed features, notes them as "already built," and generates a plan that only covers what's left. Every step in that plan is written as an incremental change on top of what exists -- not a from-scratch build. In practice, the output looks quite different from what you'd get on a brand-new project. Instead of "Phase 1: Set up the core data model," you get "Extend the existing user table to support X" and "Add Y to the API endpoint already in place." No scaffolding steps that conflict with working code. No instructions that would overwrite something that already runs. This is useful if you're mid-project and want a clean plan for the next version, or if you've shipped an MVP and need a path for v2. Mark the features that are done, set the version selector to the next batch, and the plan you get is scoped to what's actually left to build. One exception: toggling "Include full project context" always runs in greenfield mode. The assumption there is that you want the full picture, not the incremental view. ## What the plan looks like The output is plain markdown. Here's the rough shape: - A short summary of the project and what this plan covers: which version, how many features, whether it's additive or greenfield - Three to five phases, each with a clear label ("Foundation," "Core features," "Secondary features," "Stretch goals") - Under each phase: specific steps, each tied to a feature or technical dependency - For each step: a brief note on what to build, why it goes here, and what the next step depends on it It's written to drop into a chat. You don't reformat or strip anything out. Paste it into Cursor with something like "Follow this plan and start with Phase 1," and the model has what it needs to start in the right place and keep moving without drifting. The full-context version adds a preamble with design decisions and business context, which sometimes matters for models to understand why certain choices were made. ## Getting the most out of it **Mark completed features before exporting.** If you've shipped part of the app, go through your feature list and mark anything finished as "completed." The plan skips those and focuses on what's left. If you don't, you'll get a from-scratch plan that starts where you already are. **Check the version selector.** The plan is scoped to one version. Make sure the selector in the modal points at the features you're about to build, not everything you've ever planned. **Read it before you paste it.** The plan is a document the AI generated from your spec. It's usually right, but a five-minute read is worth it. If a phase doesn't make sense to you, it probably won't make sense to the model either -- adjust the underlying spec and regenerate. **Use it alongside the PRD.** The implementation plan and the [PRD export](/blog/Also) are two different things that work well together. The PRD tells your coding tool what to build. The plan tells it in what order. If you're dropping both into a session, paste the PRD first as background context, then the plan as the thing you're working through. ## The takeaway A requirements document answers "what." An implementation plan answers "in what order, and what's next." Getting both right is the difference between a coding session that knows where it's going and one that makes confident progress in the wrong direction. The implementation plan export is in the Export dropdown on any project you've built in Draftlytic. If you haven't structured your idea as a spec yet, [start with the project builder](/signup) -- the plan is only as good as the spec it's built from.