--- slug: how-draftlytic-picks-questions title: "How Draftlytic Picks the Right Questions for Your App Idea" excerpt: "How Draftlytic chooses the questions it asks you, why some are fixed and some are written for your app, and why answering more of them gives you a sharper spec." primaryKeyword: "Draftlytic questions" publishedAt: 2026-05-01 readingTimeMin: 7 author: "Robert Boylan" tags: - draftlytic - app-planning - prd - guided-questionnaire - ai-coding-tools - indie-dev --- You sit down to describe an app to Cursor or Lovable. You write a paragraph. The AI writes some code. The code is mostly fine, except it assumed you wanted email signup when you meant magic links, and it picked Tailwind even though you wanted Chakra, and it built a single-tenant data model when you'd been picturing teams. You didn't say any of that out loud. You knew it. The AI didn't. This is the gap Draftlytic's question flow is built to close. When you create a project, the app walks you through a guided questionnaire before any spec gets written. Some of the questions are obvious. Some catch the things you'd have left out. By the time you're done, the spec on the other side knows what you would have forgotten to say. This post is about how those questions get picked, why answering more of them helps, and what you're actually choosing between when you pick a depth setting at the start. We won't get into the backend plumbing. The interesting part is what the questions are doing for you. ## Why structured questions beat a blank prompt box The default way to plan an app, if you're doing it at all, is to type a paragraph into an AI tool and hope. The model does what models do: it fills in the gaps with the most statistically average answer it can find. Auth? Email + password. Hosting? Probably Vercel. Design? Probably "modern, clean, minimal." None of those are wrong. None of them are yours. A questionnaire fixes the gap from the other direction. Instead of asking the model to guess, it asks **you** the things a sensible product person would ask before any code got written. Audience. Features. Tech stack. Design. Business model. Things you might not have thought to write down. The reason a guided flow works better than a blank text box isn't because the questionnaire is smarter than you. It's that you don't have to remember the list. Most people skip planning because the cost of remembering everything-you'd-need-to-think-about is annoyingly high. Draftlytic carries that list for you. You just answer. If you want the broader argument for writing things down before you start prompting, the post on [why your AI code drifts the longer you work](/blog/why-ai-code-gets-worse-over-time) goes into it. The short version: the model only knows what you tell it. ## How the questions get shaped to your specific idea The Draftlytic question flow is a mix of two things, and both matter. **A curated bank of questions** that every project sees in some form. These are the ones that almost always need an answer no matter what you're building. Who's it for. What's in v1. What you're explicitly not building. What platforms. What the first thing a user does when they open the app actually is. The curated questions cover the load-bearing parts of any spec, in the order a real product manager would ask them. **A set of questions written for your specific idea.** Once you've described the app and answered a handful of the curated ones, the question flow adapts. If you said you're building a marketplace, you'll get marketplace-shaped questions: who lists, who buys, what gets taken in fees, how disputes work. If you said you're building an internal tool, you won't see those. You'll see questions about who has admin rights, whether anyone outside the team logs in, what's allowed to leave the network. The bank doesn't fire questions that don't apply to you. The system also pays attention to the answers you've already given. If you said the app has no accounts, it won't ask you about social login providers. If you said it's mobile-only, it won't ask about desktop layout. The flow tightens around your project as you go. Beyond that we'll keep the implementation vague on purpose. The point is the **shape**, not the gears: a fixed list of universally-useful questions plus a tailored set picked for the specific app you described, with light deduplication so you're not answering the same thing twice in different words. There's also a wrinkle for who you are. Draftlytic asks once at signup whether you're a founder, a vibe-coder, or a developer, and that quietly reshapes which questions you'll see and how they're worded. A founder gets more questions about audience and business model. A developer gets more about stack and architecture. A vibe-coder gets a flow somewhere in between. The post on [how Draftlytic adapts to the three user types](/blog/developer-vibe-coder-or-founder) has the long version. ## What answering more questions actually buys you Here's the bit it's tempting to skim: the depth of the questionnaire is the single biggest lever on how good your final spec is. Every question you answer is a decision the AI doesn't have to make for you. Skip the question about whether you want light mode, dark mode, or both, and the spec will say "modern, clean design" and your AI coding tool will pick whichever one it feels like. Answer it, and the spec says "dark mode by default with a manual toggle, no system-preference detection," and the tool builds that. The compounding effect is the part that surprises people. The questions aren't independent. The answer to "who is this for" changes how the design questions get framed. The answer to "what platforms" changes how the tech stack questions are interpreted. The answer to "are you taking payments" changes whether the spec needs an admin panel section at all. Skip a question early and three later questions land slightly off-target. A concrete example. Say you're building a habit tracker. The lazy version of the spec, three sentences and a vibe, leaves the AI to invent that the habits are predefined, the data is single-user, the streak resets at midnight in the user's local time, and the design is "playful." Sit through twenty more questions and the spec instead says: users create their own habits, each habit has an optional time-of-day target, streaks reset based on the user's chosen check-in window not midnight, the design tone is dry and slightly funny rather than playful, and the v1 explicitly does not include reminders. Same idea. Wildly different spec. Wildly different code coming out of Cursor or Lovable on the other side. So when the question flow asks you something that feels marginal, answer it anyway. The cost is fifteen seconds. The benefit is one less thing the AI has to guess. ## Brief, Standard, Detailed: how deep do you want to go When you start a new project, there's a depth slider with three settings. They're not just labels for vibes. They control how many questions you'll be asked. - **Brief.** A short flow, a handful of questions, designed for throwaway side projects or the kind of "let me see what this AI builds for fun" moment. The spec on the other side is light. Good enough for a weekend hack, thin for anything you'd ship. - **Standard.** The default, and where most projects should sit. Roughly twenty-something questions covering all the load-bearing sections without being exhausting. Balanced. If you're not sure, this is the right answer. - **Detailed.** A longer, deeper flow. More rounds of questions, more coverage of edge cases and constraints, less filling-in by the AI later. Pro-tier only, costs more credits, takes longer. The setting to use when you're about to paste the spec into Claude for a real build and you want as little ambiguity as possible. The right way to read the slider is: how much do I want the AI to guess later? Brief means "a lot." Detailed means "almost nothing." The credit costs scale with that, and you can compare them on the [pricing page](/pricing) if you're weighing the tradeoff. There's no shame in starting Brief and regenerating Standard later if the project gets serious. There is shame in picking Detailed for a tic-tac-toe clone. ## What happens when you skip a question You can skip any question you want. Skip is a valid answer. The flow doesn't punish you for it, and the spec still gets generated. But here's the honest tradeoff. A skipped question becomes a hole in the spec. The AI will fill that hole when it writes the document, using whatever the most reasonable default looks like for an app like yours. Sometimes the default is fine. Sometimes the default is wrong, and you won't notice until you're four prompts into Cursor and the auth section turned out to assume Google and Apple but not GitHub, which is the one you actually wanted. Skip when the question really doesn't apply. "Are you taking payments" is a clean skip if the app is free forever. Skip when you genuinely have no opinion and the default is fine. Don't skip just because the question feels boring. Boring is where most of the spec quality lives. If you'd rather see the whole flow end-to-end before deciding what to answer and what to skip, [the step-by-step Draftlytic walkthrough](/blog/how-to-use-draftlytic) covers it. ## The takeaway The questionnaire is the part of Draftlytic that does the most invisible work. Every answer is a decision the AI doesn't have to make later, and a sentence in the spec that won't read as "modern and clean" when it should read like the app you actually pictured. You don't have to remember the list of things to think about before you build. The list is the questionnaire. The job is to answer. The next time you sit down to plan an app and feel the urge to skip the questions because you "already know what you want," that's exactly the moment to answer them. What you already know becomes a spec the AI can build from. What you skip becomes a guess. [Start a project](/signup) and let the questions do the heavy lifting. That's what they're there for.