---
slug: developer-vibe-coder-or-founder
title: "Developer, Vibe-Coder, or Founder: How Draftlytic Adapts"
excerpt: "Draftlytic asks one question at signup: are you a founder, vibe-coder, or developer? That answer reshapes the questions, tabs, and exported spec."
primaryKeyword: "Draftlytic user types"
publishedAt: 2026-04-17
readingTimeMin: 7
author: "Robert Boylan"
tags:
  - draftlytic
  - user-types
  - founder
  - vibe-coder
  - developer
  - app-planning
---

Two people sign up for Draftlytic within a minute of each other. They type the exact same idea: "a simple app to track my plants and remind me when to water them." They land on the same flow. Then the tool asks them a single question before anything else happens.

Are you a founder, a vibe-coder, or a developer?

**From that point on, the two people see different products.** Different questions. Different section order in their plan. Different tone in the AI's answers. Same idea, three flavours of spec.

Draftlytic asks that question because "what counts as a good plan" depends heavily on who's reading it. A spec meant to hand off to a dev agency doesn't look like a spec meant to paste into Cursor. Someone who writes TypeScript every day needs different scaffolding than a founder who wants a one-pager they can share with a cofounder. This post walks through what actually changes between the three Draftlytic user types, and why.

## Three modes, one underlying idea

Before we get into what each mode does differently, here's what they share: every Draftlytic project ends in a single document (a PRD, or product requirements doc) that you can hand to a human team, paste into an AI coding tool, or keep for yourself as the source of truth. The tool you build with is your call. The shape of the spec is the part Draftlytic handles.

What changes between modes is the _emphasis_. If you're a founder, your plan leads with the market and the business model. If you're a vibe-coder, it leads with the features and the look. If you're a developer, it leads with the architecture and the stack. The underlying sections are the same. The order, the questions, and the voice are not.

You pick your mode once, at signup. You can change it later from your profile if the hat you're wearing changes. The three user types exist because Draftlytic's audience really is that split; trying to serve all three with one generic flow ends with nobody getting a spec that fits them.

## Founder: the plan is a hand-off document

A founder, in Draftlytic's definition, has the vision but not (necessarily) the code. Maybe you're a first-time founder with an idea and a small budget to hire a dev agency. Maybe you're a solo operator who plans to use a no-code builder like [Lovable](https://lovable.dev) or Bolt.new and wants a proper brief first. Maybe you're pitching the idea to a technical cofounder and need something they'll take seriously.

In all three cases the plan's main job is to be _legible to someone else_, and that changes everything about what goes in it.

So the founder flow does this:

- **Market and business come first.** The top tabs in your project aren't Architecture or Technology. They're Market (who this is for, what the competition looks like) and Business (how it makes money, at what price). When a dev agency reads your spec, that's what they want to see first to scope the work.
- **The questions are business-framed.** Draftlytic's AI phrases options and follow-ups for a business-focused audience. "Who's the user?" gets fleshed out with personas; "what's the revenue model?" gets framed around monthly recurring revenue, freemium, marketplace commission, rather than stack jargon.
- **Technology and architecture still appear, but later.**They're not hidden. They're just further down the document, because they're not the part you're using to align a cofounder or scope an agency.

The exported PRD mirrors the same order. Overview, then Market, then Business, then Features, then Design, then Technology, then Architecture. A founder handing the spec to a developer is saying, in effect: here's why we're building this, here's who it's for, here's what it needs to do. Please figure out how.

## Vibe-coder: the plan is a prompt

A vibe-coder is the person building apps by describing them to tools like Cursor, Claude Code, Lovable, or v0. Not all the code is hand-written. The AI writes most of it; you steer, correct, test, and keep going. If that's you, the plan's main job isn't hand-off. It's _context_: the thing you paste at the start of a coding session so the AI doesn't drift at prompt four.

We've written before about [why vibe coding still needs a plan, and what a mini-PRD looks like](/blog/vibe-coding-why-planning-matters). The short version: the AI only knows what you tell it, and the quality of the code tracks the quality of the brief.

So the vibe-coder flow does this:

- **Features and design are the headline.** Your tabs run Overview, Features, Design, Technology, Architecture, Market, Business. The business stuff isn't gone; it's just at the end, because you're not using this document to raise money. You're using it to tell Claude what to build.
- **The AI's voice is tool-aware.** When Draftlytic generates questions and options, it phrases them in the language of AI coding tools. Stack questions mention Vite, Supabase, Tailwind by name. Design questions talk about components, states, and mood, not brand palettes.
- **The export is structured for pasting.** The PRD comes out in a shape that fits neatly into a single big message to Cursor or Lovable: idea at the top, features in ranked order, design and stack right after, architecture and non-goals at the bottom. Exactly the structure [Anthropic's own Claude Code docs](https://docs.anthropic.com/en/docs/claude-code/overview) suggest for giving the model useful context.

Vibe-coder is also the default mode when a user's type is unknown, because it sits in the middle of the spectrum. If you're not sure which hat fits, it's a safe landing spot.

## Developer: the plan is a scoping doc

A developer, in Draftlytic's sense, writes code professionally and wants structured planning with the technical depth you'd expect from an actual engineering process. If you've ever written a one-pager before a sprint, or sketched a service diagram before starting a feature, that's the instinct this mode leans into.

So the developer flow does this:

- **Architecture moves to the top.** Right after Overview, you see Architecture and Technology before anything else. Your brain wants to resolve those questions before it cares about marketing copy. The tool gets out of the way and lets you do that.
- **Questions get implementation-focused.** The AI phrases options with the language of real constraints: hosting regions, SSR vs SPA, auth providers, background jobs, storage model, third-party APIs. Not hand-wavy "does it need a login?" style. Real choices, presented with enough nuance that you can pick the one that matches your setup.
- **The export reads like an internal design doc.** The PRD leads with Architecture, then Platform & Stack, then Features, then Design, then Market and Business. It's the same spec, but the sections a peer reviewer would reach for first are the ones that actually appear first.

A developer isn't necessarily building alone, and isn't necessarily vibe-coding. This mode is for when you want a plan that slots into an existing engineering culture. Pull request template friendly. Handover-friendly. Future-you-in-six-months friendly.

## What stays the same, no matter who you are

A few things don't move:

- **The sections themselves.** Every project has Overview, Features, Design, Technology, Architecture, Market, Business. Modes reorder them; modes don't remove them. If you're a vibe-coder and you want to fill in the Business tab anyway, you can. Nothing is locked.
- **The core workflow.** You describe your idea, answer a handful of follow-up questions, get a structured project, edit any section by talking to the AI, and export to a PRD when you're ready. That arc is identical across all three modes.
- **The output format.** Every export is a single markdown document that reads cleanly in a text editor, pastes cleanly into a chat, and renders cleanly on GitHub. No mode produces a weird proprietary artifact.

In other words, Draftlytic isn't three different products stapled together. It's one planning tool that quietly rearranges itself around the person using it.

## The takeaway

Most planning tools assume one kind of reader and serve that reader well. Everyone else ends up mentally translating. Founders skim past architecture sections they don't follow. Developers skim past marketing sections they don't care about. Vibe-coders skim past both.

The three Draftlytic user types exist so you don't have to skim. You pick the hat you're wearing, and the plan shows up in the shape that fits. If the hat changes next project, you change it from your profile and the next plan reshapes too. Either way, you end up with a spec that reads the way your brain already works, and goes straight into whichever tool you build in.