--- slug: mvp-scope-ships-in-a-weekend title: "What to Build First: Picking an MVP Scope That Ships in a Weekend" excerpt: "Most indie apps never ship because the MVP scope was wrong from the start. Here's a concrete framework for shrinking a fuzzy idea into 3 features." primaryKeyword: "MVP scope" publishedAt: 2026-05-02 readingTimeMin: 8 author: "Robert Boylan" tags: - mvp-scope - app-planning - indie-dev - vibe-coding - shipping --- You open a fresh Lovable prompt or a blank Cursor project on Saturday morning with a clear idea in your head. By Sunday evening you haven't shipped anything. Not because you ran out of time, not because the tools let you down. Because somewhere between the idea and the build, the app quietly grew from three features to twelve. You planned a bike and started building a car. That's the MVP scope problem. It kills more vibe-coded apps than bad prompts or buggy AI output ever will. This post gives you a concrete framework for cutting your app down to the version that can actually go live this weekend. Not the version you're proud of in your head. The version someone can use. ## Why "what do I want this app to do" is the wrong question Most people define their app by imagining it finished. They write out a list of everything the ideal version would have, then call it their plan. That list is not your MVP scope. It's a roadmap for something that ships in six months, if at all. The right question is: what is the smallest version of this that a real person could actually use on day one? That question has teeth. It forces you to remove anything that isn't load-bearing for a first session. Auth systems, settings panels, notification preferences, profile pictures, dark mode, social features, export options: none of these are things a first-time user needs in the first sixty seconds. They're things that make you feel like you're building something serious. They're also the reason most indie apps never ship. This sounds obvious. It isn't. Every item on your original list felt necessary when you wrote it down. Trimming requires a sharp line between "needed on day one" and "nice to have eventually." The two piles are more unequal than you'd expect. ## The one-sentence rule for MVP scope Before you open any builder, try to finish this sentence: "My app lets [specific person] [do one thing] without [the friction they have today]." If you need more than one sentence, your scope is too big. If the person is "anyone," your scope is too broad. If the thing you're describing requires three other things to work first, you're describing feature two or three, not feature one. This is not a tagline exercise. It's a scope filter. Run every feature on your list through it: does this help my specific person do that one thing? If the answer is "not directly, but they'd probably want it later," pull it out of v1. A habit tracker: "My app lets someone who wants to build better habits add a new habit and mark it done today." That's the sentence. Streaks, categories, reminders, social accountability, charts, export, account settings, dark mode: later sentences, all of them. A booking tool: "My app lets a freelance designer share a link that lets clients pick a meeting slot without back-and-forth email." Calendar sync is load-bearing. Profile pictures are not. Write the sentence. Then defend it. ## The first-session exercise Once you have your sentence, run this check: what does a brand-new user actually do in the first sixty seconds? Walk it step by step. They land on the page. What do they see? What's the first tap? What happens next? If you can't narrate those sixty seconds without referencing a feature you haven't built yet, you're missing something core. If you can narrate them in four steps, you're probably close. For the habit tracker: user opens app, sees a prompt to add their first habit, types it in, hits save, gets taken to today's view, marks it done. That's the whole session. Everything that happened there is in scope. Everything else isn't. This exercise also reveals what you're tempted to include but shouldn't. Onboarding flows, tutorial overlays, welcome emails: none of these exist in the first sixty seconds. They exist in your imagination of a polished product. Strip them. Ship without them. The people who use a v1 are early adopters who opted in. They need the core thing to work, not a tutorial. ## What to explicitly cut from your v1 Some categories almost always make it into early feature lists and almost never belong in a first weekend build. Cutting them requires real discipline because each one sounds reasonable on its own. **Account systems and auth.** Unless your app is fundamentally multi-user or needs persistent state across devices, skip full auth for v1. Many apps can start with no login at all, a magic link, or local storage. Bolt.new and Lovable will wire up Supabase auth in ten seconds, which makes it tempting to include. Don't, unless the core thing breaks without it. **Settings panels.** If you're building settings, it means you haven't decided what the defaults should be. Settings are a symptom of unfinished thinking. Lock the defaults in v1. Add settings in v2 when users complain about the specific thing they want to change. **Notification and reminder systems.** These feel core for habit or task apps. They're engagement features. If the app isn't useful without reminders, the problem is the core thing, not the missing notifications. **Social and sharing features.** "Users can share their progress" sounds like virality. It's actually three additional features disguised as one. Skip it. **Analytics and admin dashboards.** You don't need a dashboard while you have fewer than ten users. You have a database. Look at it directly. If you find yourself writing "users can also," stop. "Also" is where scope creep lives. ## Why boring v1s ship and ambitious v1s don't There's a particular kind of indie developer who builds incredible-sounding apps that never go live. Their Notion planning doc is twelve pages. Their feature list is detailed and well-considered. They've been "almost ready to launch" for four months. The problem isn't effort. The problem is that their v1 is too interesting to be finishable. Ambitious v1s fail because every feature you add doesn't just add one unit of work. It adds connections between features, which multiply the surface area for bugs. It adds decisions you'll defer until later, and later never comes. It adds integration points where one unfinished piece blocks another. Boring v1s ship because they have no connections to break. Three features that each do one thing: add, check off, view. When one breaks, you fix it. When you demo it, people understand what they're looking at. The people you admire for shipping fast aren't building simpler apps because they lack ambition. They're building simpler apps because they understand what shipping actually requires. [Planning matters even more when you're building quickly](/blog/vibe-coding-why-planning-matters), not less, because speed without direction just gets you lost faster. If your v1 could be described as boring, that's a good sign. Ship the boring version. Make it less boring in v2. ## How to go from fuzzy idea to a 3-feature v1 Here's a process you can run in under thirty minutes. Write your app idea as a brain dump. Don't filter yet. Get everything on screen. Apply the one-sentence rule: my app lets [person] [do one thing] without [friction]. Rewrite until it's one sentence. Run the first-session exercise. Narrate sixty seconds. What's the first screen? First action? First result? Pull the features that are strictly required for that sixty-second session to work. Your v1 list should have between two and four items. Move everything else to a "later" list. Not deleted, just not this weekend. Last check: is there anything on your v1 list that's there because it would be impressive, rather than because your specific user needs it in the first sixty seconds? Pull it. What remains is your build list. Hand it to your tool of choice: Cursor or Claude Code if you want to be in the file system, Lovable, v0, or Bolt.new if you'd rather stay out of the code. A clear, narrow scope gets better output than a sprawling wish list, because the tool can optimize for three connected things much more reliably than it can resolve twelve ambiguous ones. If you want structured help with that narrowing process, that's what [Draftlytic is built to do](/). You describe the idea, answer a few focused questions, and you walk out with a spec instead of a twelve-page Notion doc. The thinking takes ten minutes. The not-thinking takes four months. ## The habit tracker example, done both ways Let's make this concrete. The app: a habit tracker. You want to help people build better daily habits. **The ambitious v1 (doesn't ship):** Add and manage habits with categories, daily reminders, streaks, calendars, social sharing, weekly charts, Apple Health import, CSV export, Google login, and dark mode. Eight to ten features. Every one of them reasonable. Together they take a month to build and two months to debug. It doesn't ship this weekend. **The boring v1 (ships):** Add a habit by typing its name. Mark it done for today. See this week's checkmarks. Three features. An hour to build the first version, an afternoon to polish. A working thing you can send to ten friends by Sunday night. The boring v1 tells you something the ambitious one can't: whether people actually use a habit tracker when you give them one. Once you know that, the ambitious v1 becomes a roadmap instead of a gamble. Scope isn't about vision. It's about what you can verify this weekend. [A good spec for any AI coding tool](/blog/good-lovable-app-spec) starts from the same place: the smallest thing that tells you whether the idea holds up. Ship the boring version. Then make it interesting once you know it's worth your time.