---
slug: how-to-use-draftlytic
title: "How to Use Draftlytic to Plan an App, Step by Step"
excerpt: "How to use Draftlytic end-to-end: turn an idea into a structured spec, refine it for your AI coding tool, and export an implementation plan you can build from."
primaryKeyword: "how to use Draftlytic"
publishedAt: 2026-05-01
readingTimeMin: 8
author: "Robert Boylan"
tags:
  - draftlytic
  - how-to
  - app-planning
  - prd
  - ai-coding-tools
  - implementation-plan
---

You've got the idea. Maybe it's a habit tracker that tries to be funny about it. Maybe it's a small internal tool your team keeps re-asking for in Slack. Either way, the moment you open Cursor, or Lovable, or v0, the page is blank and the AI is waiting for you to be specific.

Most of the friction at this point isn't that you don't know what you want. It's that you haven't said it out loud yet, in the kind of structure an AI tool can actually follow.

That's what Draftlytic is built for. You describe an idea, the app turns it into a structured spec, and you keep refining until the doc actually matches the app in your head. This post walks through how to use Draftlytic end-to-end, feature by feature, so the PRD you walk out with is one Cursor, Lovable, or Claude won't have to guess at.

A PRD, by the way, is just a product requirements document. A plan that says what the app should do before any code gets written. We've got a longer write-up on [what a PRD actually is and why it matters for AI coding tools](/what-is-a-prd) if that's a new word.

## Start with the idea, not the spec

The first screen you'll see is the New Project flow. It asks you for two things: a one-paragraph description of what you want to build, and a name. That's it.

You're not writing a spec yet. You're describing the app the way you'd describe it to a friend who asked. Don't worry about the tech stack, the features, the auth strategy, the platforms. None of that matters here. The only goal is to get the core idea onto the page.

There's also a depth slider with three settings:

- **Brief.** Quick and light. Good for throwaway side projects or when you just want a rough plan to get moving.
- **Standard.** The default. Balanced. About 20 to 30 questions, broad coverage of features, design, and tech. This is where most projects should sit.
- **Detailed.** Pro-tier only. More rounds of questions, more thorough coverage, the kind of depth you want before pasting into Claude for a serious build.

Pick the one that matches what you're actually trying to do. If you're not sure, standard is right almost always. You can see the [credit costs and tiers on the pricing page](/pricing) if you want to compare before committing.

If you're new to Draftlytic, the signup flow also asks whether you're a founder, a vibe-coder, or a developer. That answer reshapes the questions you'll see next, the tabs you'll spend time in, and the language of the final spec. There's a [longer post on how Draftlytic adapts to user type](/blog/developer-vibe-coder-or-founder) if you want the detail.

## Let the questions do the heavy lifting

Right after creation, the guided question flow opens. This is where most of the spec quality comes from. Skip through it and you'll feel the holes later. Take ten minutes here and the rest of the work is small adjustments.

The questions cover the things a real PRD needs to answer:

- **Audience.** Who's using this. What they're trying to get done. What they hate about how they do it now.
- **Features.** What should be in v1, what's "nice to have," what you're explicitly not building. Multi-select where it makes sense, free-text where the answer is yours.
- **Tech stack and platforms.** Web, mobile, desktop. What you already know how to use vs what you'd be open to.
- **Design and tone.** Visual style, copy voice, what the first screen looks like, what UX patterns you want.
- **Business setup.** Whether it's free, paid, has accounts, has admin. Whether anyone other than you ever logs in.

Some questions are picked from a fixed bank. Others are generated for your specific idea. The flow is structured but not rigid: if a question doesn't apply, "skip" is a valid answer. If something matters that isn't being asked, you can fill it in later.

The trick is to answer like the AI is going to read it, because it is. Vague answers ("a clean design") become vague specs. Concrete answers ("dark mode by default, large rounded cards, no gradients, the homepage is the empty state for new users") become specs the model can build from.

## Edit, reorder, and trim until it sounds like the app you want

Once the questions are done, you land on the project page. This is where you actually shape the spec.

The page is split across tabs: Overview, Features, Design, Technology, Architecture, Market, and Business. Each tab is a separate, editable section of the same project. You can hand-edit any field directly. No round trip, no AI cost, just you typing.

Two things on this page are worth getting comfortable with:

The **Features tab** uses drag-and-drop priority columns. Now, Next, Later, Future. Drop a feature into "Now" and it becomes part of v1. Move it to "Future" and it falls out of the immediate plan. There's also a "completed" state, which matters later when you export an implementation plan, because Draftlytic will treat completed features as already-built and won't generate steps that re-do them.

The **AI Edit panel** sits on the right of the project page. Type a natural-language change, the AI rewrites the relevant section in place. Things like "make the auth section explicit about social login" or "add a non-goals section saying we're not building notifications in v1" or "rewrite the audience as small B2B teams, not consumers." Standard edits cost 10 credits, detailed-depth edits cost 15. Cheap enough that you can iterate without thinking about it.

You don't have to use the AI Edit for every change. For typo-level fixes or small tweaks, just hand-edit the field. For anything that touches more than one section, the AI is faster.

## Run the AI Scan when you can't see the gaps anymore

After ten minutes of editing, you'll start losing the ability to see your own spec clearly. The same paragraph reads fine the fourth time even though it's missing the obvious thing. This is what the AI Scan is for.

There's a "Scan with AI" button on every project page. It costs 30 credits, paid tiers only, and runs the whole spec through a model that's been told to read it the way an AI coding tool would. It comes back with a verdict and a list of up to ten specific fixes.

Not vague feedback. Specific lines, like "the auth section names Supabase but doesn't say which providers" or "the upload feature has no error-state guidance, which Lovable will guess at." Each fix has a one-click apply. You can apply them one at a time or batch up to eight at once and let the model sort the rewrite.

The Scan is the single biggest quality lever in the product. Run it when you think you're done, and you'll usually find three to five things that would have made the AI invent something the next time you prompted.

For the longer reasoning on why this matters, see [why your AI code drifts the longer you work](/blog/why-ai-code-gets-worse-over-time). The short version: the model only knows what you tell it, and the Scan finds what you forgot to say.

## Take it to the Workshop to refine for your target tool

The same PRD doesn't land the same way in every AI tool. A spec written for Claude can be long, prose-heavy, and structured. Paste that same spec into Lovable and it gets condensed, half-read, or reinterpreted. Cursor wants short bullets with file names. v0 wants a description of the screen.

The **PRD Workshop** is a separate Draftlytic feature for tuning the spec to whatever tool you're actually going to paste it into. Open it from the user menu or directly from the project export modal. You paste the PRD, pick a target tool (Claude, Cursor, Lovable, v0, Bolt.new, Windsurf, Replit Agent, ChatGPT, Gemini, or "not sure"), and you're in.

It's a chat. You ask for a change, the AI rewrites the PRD in place, the new version replaces the old one, and every turn becomes a revision you can revert to. You can also run the same Scan diagnostic from inside the Workshop and apply fixes from there.

Workshop chat costs scale with PRD size: 10 credits per turn under 5,000 characters, 15 between 5,000 and 15,000, 25 above that. The Send button shows the live cost so you're never guessing. The [full PRD Workshop walkthrough is here](/blog/prd-workshop) if you want the details.

The Workshop is optional. If your spec already feels right and your target tool is Claude or Cursor, you can probably skip straight to export. Use it when you're aiming at a more opinionated tool (Lovable, v0, Bolt) and the spec needs to be reshaped to land there.

## Export the PRD, then the implementation plan

When the spec sounds like the app you want, hit Export. There are two documents you can pull out:

The **PRD markdown** is free to export and download as many times as you want. It's the spec itself, formatted as a `.md` file you can drop straight into Cursor, Claude, Lovable, or whatever you're using. Title, overview, audience, features, tech stack, design, business setup, all in one document.

The **implementation plan** is the second export. It costs 40 credits standard, or 50 with full project context, and it's a phased build order rather than a requirements doc. Phase 1 is the foundation. Phase 2 is core features. Each step ties back to a feature or technical dependency, with a note on why it goes where it goes. There's a [dedicated post on the implementation plan export](/blog/export-implementation-plan) that goes deeper.

The two documents work well together. The PRD tells your AI coding tool what to build. The plan tells it in what order. Paste the PRD first as background context, then the plan as the thing you're working through, and the AI doesn't have to make sequencing calls on its own.

If you want a logo to go with the spec, the **Generate logo** button uses an image model to produce a few options based on your project name and brand fields. It costs 60 credits per round and is capped at 10 rounds per project, so you don't accidentally burn through credits chasing the perfect mark. Optional, but nice to have when you're about to build a landing page.

## The takeaway

A well-designed PRD isn't a long PRD. It's one where the AI doesn't have to fill in the blanks. Audience is specific. Features are prioritised. Tech stack is named. Design has a tone. The things you're not building are written down. The order you'd build them in is explicit.

Draftlytic walks the path to that shape, one feature at a time. The questions surface what matters. The tabs let you shape it. The Scan finds what you forgot. The Workshop tunes it to your target tool. The exports hand you the PRD and the build plan together. By the time you paste it into your AI coding tool, the model isn't guessing what you meant. It's reading the spec you actually wrote.

If you've been describing apps to Cursor in two-paragraph bursts and watching the output drift by prompt four, [start a project](/signup) and try the full flow once. The thinking is the hard part. Draftlytic is the frictionless way to get through it.