Six months ago you shipped. People are using it. You have a waitlist request thread and a Notion doc full of feature ideas, and a paying user who asked about Apple Health sync three separate times.
You open Draftlytic, look at your project, and notice everything is still marked as v1. The features you shipped months ago sit right next to the features you've never touched. Your implementation plan export, if you generate one today, would start from scratch. Phase 1: set up the core data model. Which... you already have. Running in production. With real users on it.
This is the v2 planning problem. And it's where most indie apps quietly stall.
The app didn't fail. The plan for what comes next never got written.
Why v2 specs need to be additive, not greenfield
When you first built your app, starting from zero made sense. The spec covered everything: auth, data model, the first user-facing feature, the navigation, all of it. Your implementation plan said "Phase 1: foundation." That was correct.
A v2 plan isn't like that. The foundation is already there. Your users are sitting on top of it. A plan that starts at scaffolding isn't just wasteful, it's dangerous. Drop a greenfield plan into Cursor or Lovable and ask it to "follow this," and there's a real chance it starts proposing changes to tables that already have data in them, or auth flows that are already live. The model doesn't know your app is running. It only knows what's in the spec.
The spec for v2 needs to tell the AI: here's what already exists, here's what I'm adding, and don't touch the first half.
That's exactly what additive mode in Draftlytic's implementation plan export does. But to get there, you need to organise your project correctly first. That starts with versions.
Marking features as "completed" so the AI stops trying to rebuild them
Draftlytic lets you assign a version to each feature (v1, v2, and so on) and mark features as "completed." This is the two-step that makes v2 planning work cleanly.
Here's the practical flow. Go through your feature list and do two things:
- Mark anything you've already shipped as completed. Not just "deprioritised" or left in v1 as a reminder. Actually mark it done.
- Move your incoming feature requests and v2 ideas onto the list if they're not already there, tagged as v2.
That's it. No separate project, no copy-paste, no fresh start. The same project you used for v1 now has a clean record of what's running and what's next.
Why does this matter for the AI? Because when you export an implementation plan with completed features present, Draftlytic reads that list and treats those features as already built. Every step in the generated plan is written as an incremental change on top of the existing code, not a from-scratch instruction. Instead of "Set up the user table," the plan says "Extend the existing user table to support reminder preferences." Instead of "Implement push notifications," it says "Add notification scheduling on top of the existing session layer."
The model gets context without you having to write a paragraph of caveats every time.
If you're doing a lot of feature housekeeping for the first time and it's reminding you of everything that went into building v1, the post-launch maintenance guide covers that ground if you want to go deeper.
Using version filters in the PRD and implementation plan exports
Once your features are tagged, the version selector in the export modal becomes the main tool for scoping work.
When you click "Export" and choose "Implementation plan document," the modal has a version selector. Set it to v2 and the plan covers only v2 features. The completed v1 features are noted as already built; the v2 features become the phases.
The PRD export works the same way. Set the version filter, get a spec that covers only what's in scope for this round. If your v2 has eight features, you get a document about those eight features, written as additions to an existing app rather than as a full product brief.
This matters for a non-obvious reason: context window size. If you're working in Cursor, Claude, or any tool with a limited context window (how much information the AI can hold in its head at once), a scoped document is more useful than a full one. The AI doesn't need to re-read the v1 auth flow to add Apple Health sync. Giving it only the v2 scope means more of its attention is on the actual task.
You can also run multiple exports for different versions if your roadmap is split across teams or time periods. A v2 plan now, a v3 plan when you get there. Each one scoped, additive, ready to use.
The "Include full project context" toggle: when the 10-credit surcharge is worth it
In the implementation plan export modal there's a toggle: "Include full project context." It costs 50 credits instead of the standard 40.
Here's what it actually does. The standard export generates a plan based on the version's outstanding features plus what Draftlytic knows about your tech stack, data model, platforms, and current milestone. That's usually enough.
The full-context toggle adds the rest of the picture: all your personas, design decisions, business setup, admin requirements. And it does one more thing: it forces the plan into greenfield mode, regardless of whether you have completed features.
That sounds counterintuitive. Why would you want greenfield mode for a v2 plan?
Two situations. First: when the design and business context genuinely affects the build order. If you're adding Apple Health sync to a habit tracker and you've specified that the app targets iOS only and your users are fitness-conscious early adopters, a full-context plan might arrange the phases differently than a purely feature-based plan would. The model understands the "why" behind the sequence.
Second: when you're doing a major architectural expansion, not just adding features. If v2 involves a new product tier, a new user type, or a fundamentally different backend setup, the additive mode's "build on top of what's there" framing might be too conservative. Sometimes you actually want the AI to think from first principles about how the expanded system should be structured, even if parts of it already exist.
For most v2 plans, the standard export is the right call. Your completed features provide the context, your v2 features set the scope, and you get an additive plan without the surcharge. Save the full-context toggle for the bigger architectural moments.
For more on what the implementation plan export produces and how to use the file once you have it, the full walkthrough of the implementation plan feature covers the output format and how to drop it into your AI coding tool.
A worked example: a launched habit tracker adding reminders and Apple Health sync
Suppose you shipped HabitStack six months ago. Core features: habit creation, daily tracking, a streak counter. It works. People use it. Now the two most-requested things are push reminders and Apple Health sync.
Here's how you'd set this up in Draftlytic.
First, mark the shipped features as completed. Habit creation: completed. Daily tracking: completed. Streak counter: completed. You might also have a "profile screen" or "onboarding flow" in there from v1. Mark all of it done.
Next, add the v2 features if they're not already there. "Push reminders" as a v2 feature. "Apple Health sync" as a v2 feature. If you're feeling ambitious, maybe "habit categories" and "weekly summary email" too. Tag them all v2.
Now go to Export, choose "Implementation plan document," set the version to v2. The plan comes back with your completed v1 features noted as the existing foundation, and a phased plan for reminders and Apple Health sync written as extensions to what's already there. Something like:
- Phase 1: Add a notification preferences field to the existing user table. Wire up the push token registration on first launch.
- Phase 2: Build the reminder scheduling logic against the existing habit model. Test against the streak counter to make sure the streak isn't affected by reminder interactions.
- Phase 3: Add the HealthKit read/write permissions flow. Map the existing habit completion data to the HealthKit workout schema.
No "set up the database." No "implement user auth." The plan knows that part is done.
You paste that into Cursor or Bolt.new, tell it to start with Phase 1, and you're not explaining the existing codebase at all. The plan already did that.
What actually happens if you skip the versioning step
You generate a plan without marking anything done. The AI gets a feature list with v1 and v2 mixed together, no signal about what's running, no signal about what's next.
Best case: the plan looks roughly right and you manually skip the scaffolding phases when you're prompting.
More common case: the plan starts at Phase 1 anyway, and when you paste it into your AI tool and say "follow this," the first few steps propose changes to things that are already live. You notice, you correct, you lose twenty minutes. The session becomes about explaining your existing codebase rather than building the new feature.
The version tags and completion statuses aren't busywork. They're the signal the AI needs to write a plan that reflects where you actually are.
The plan that never gets written
The dirty truth about v2 is that it doesn't fail because the features are too hard. It fails because writing "v2 plan" in a to-do list is very different from actually having a plan.
Most founders have the ideas. They have the feature requests, the Notion docs, the waitlist replies. What they don't have is a document that says: here's what's already built, here's what comes next, here's the order, here's why. Without that document, every Cursor or Lovable session starts from scratch and ends with the AI trying to rebuild things that already run.
Draftlytic's version system is built so that document doesn't take an afternoon to write. Mark what's done, add what's next, export the plan. The next phase of your app starts from where the last one ended, not from a blank page.