AI collapsed the cost of building, but it didn't touch the cost of deciding. The most common way a first project dies isn't broken code. It's a scope so wide the thing never ships. Fifteen years of product wisdom, from Eric Ries's minimum viable product to Marty Cagan's viability test to the cupcake model, exists to prevent exactly that death.

This lesson translates that tradition to the audience-of-one scale of vibe coding, where the builder is also the only customer. It covers how to shrink a first version until it answers a single question, why a hard deadline is the most reliable scoping tool available, and which tempting features, logins and payments chief among them, deserve to wait.

What is an MVP (minimum viable product)?

A minimum viable product (MVP) is the smallest version of a product that can teach its builder something real. Frank Robinson coined the term in 2001 [1], and Eric Ries gave it its canonical definition: "The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort" [2].

The definition hides a twist that most people miss. What gets minimized isn't quality, polish, or ambition; it's the effort spent before real learning arrives. An MVP isn't a small product so much as a fast answer, and the fastest honest answer wins.

For a first vibe-coded project, that framing changes everything. The goal of v1 isn't to impress anyone. It's to find out, as cheaply as possible, whether the idea deserves a v2.

Viable means valuable

"Minimum" gets all the attention, but "viable" carries the weight. Marty Cagan defines an MVP as "the smallest possible product that has three critical characteristics: people choose to use it or buy it; people can figure out how to use it; and we can deliver it when we need it with the resources available" [3]. He sums those up as valuable, usable, and feasible.

That test corrects the most common misreading of the term: minimum doesn't mean low quality. A v1 that nobody chooses to use isn't a lean success; it's just an unfinished product wearing a fashionable label.

For a personal tool the bar is refreshingly concrete. Valuable means the builder reaches for it, usable means the builder isn't confused by it, and feasible means it ships with the time and tools at hand.

The one-question v1

Before any tool opens, a v1 deserves one written question it must answer. For most personal projects the question is some version of "will this actually get used every day?" Everything that helps answer it belongs in scope; everything else waits.

Feature lists are the tempting alternative because features are concrete and fun to enumerate. But a list optimizes for output while the question optimizes for learning, and learning is the entire point of a first version. Cagan goes as far as calling this kind of build an "MVP Test," precisely so nobody confuses an experiment with a product [4].

Vibe coding compresses this idea to its purest form. The builder is both vendor and customer, so the experiment runs on exactly one person, and the answer arrives within days.

Pro Tip! Writing the question at the top of the project notes turns every later "should this go in?" into a fast yes or no.

The cupcake model

The cupcake model

Brandon Schauer of Adaptive Path gave product slicing its most useful metaphor: the wrong move is baking the dry base layer of a wedding cake and promising icing later, and the right move is shipping a cupcake [5]. A cupcake is small but complete, icing included. From there the product can grow into a birthday cake, and eventually the wedding cake, with each version whole at its own scale.

The model settles a fear that stops many builders: scoping small isn't thinking small. The wedding-cake vision survives intact; the cupcake is simply its smallest complete expression. Ethan Mollick's fire-truck game grew the same way, with each playable version adding one sentence of ambition to the last [6].

The practical rule follows directly. If v1 only makes sense as a foundation for v2, it's a base layer, not a cupcake, and every version should be worth using on the day it ships.

One user, one task, one path

The reliable slicing formula for a first version is one user, one task, one happy path. One user means the builder alone. One task means the single job the tool exists to do. One happy path means the one route through that task where nothing goes wrong.

Robin Sloan's family messaging app BoopSnoop shows how much this cuts. It shipped with no login system, no contact management, no threading, and no message history. As Sloan put it, "It already knows exactly who's using it" [7]. The features he didn't build are the lesson: at personal scale, most "required" features aren't.

Building for hypothetical other users feels like ambition, but it quietly makes the viability test unpassable. Valuable, usable, and feasible are easy to confirm for one known person and nearly impossible to confirm for an audience that doesn't exist yet.

The four-day constraint

Ethan Mollick's Wharton experiment turned scoping into a deadline. "Teaching an experimental class for MBAs on 'vibefounding,' the students have four days to come up and launch a company" [8]. By his account, the non-coders in the class built working products, and teams compressed work that once filled a semester into days. It's one class rather than a controlled study, but the mechanism it demonstrates is durable: the timebox forces the scope, and AI makes the forced scope survivable.

The constraint works because "done when it feels ready" never arrives. Without a deadline, polishing feels like progress; with one, every feature has to argue for its place. Andrej Karpathy baked the same limit into vibe coding's founding description when he called it a fit for "throwaway weekend projects" [9]. A weekend is a scope statement.

The takeaway isn't the number 4. It's that the deadline gets chosen before the feature list, so the calendar does the cutting that willpower won't.

Simple, Lovable, Complete (SLC)

Jason Cohen, founder of WP Engine, filed the field's sharpest objection to MVP thinking: "I hate MVPs. So do your customers. Make it SLC instead" [10]. SLC stands for Simple, Lovable, Complete, pronounced "slick." His charge is that the MVP label licenses shipping something broken and calling the damage learning, when customers experience a shipped MVP as the product itself, not as an experiment.

For an audience of one, the fight mostly dissolves. Nobody churns off a tool they built for themselves, and lovable comes cheap when the only person to delight is the builder. What survives is SLC's slicing instruction: a v1 should be complete at its own scale, which is exactly what the cupcake model encodes.

Why scope still matters with AI

When AI can return a working first version in minutes, scoping can look like a legacy habit. Three findings say otherwise. Nielsen Norman Group's evaluation of AI prototyping tools found they "lack the sophistication to weigh design tradeoffs," so whatever a request leaves unspecified gets filled with the tool's assumptions [11]. A small scope is what makes full specification possible for a beginner.

Mollick adds the second limit: "The challenge becomes identifying what 'minimum viable knowledge' is necessary to effectively collaborate with AI on various projects" [12]. A project scoped small stays inside what its builder can guide, troubleshoot, and evaluate. The same essay supplies the third finding: the game that cost about $5 to build cost $8 and 20 minutes to fix when it broke. Only the small scope kept that failure recoverable.

AI didn't remove the value of scoping; it moved it. Building got cheap, but specifying, judging, and debugging stayed with the human, and small scope keeps all three within a non-coder's reach.

Deferring logins and payments

"Just add login real quick" is the classic v1 trap. Real apps have accounts and payments, so adding them feels like graduating to a real product. In practice they're the single biggest multipliers of scope and risk a beginner can take on: suddenly the project holds other people's credentials and money, and every screen sprouts edge cases.

At personal scale they're usually unnecessary. BoopSnoop shipped to Sloan's family with no login system at all, because a tool installed on one household's phones already knows who's using it [13]. A v1 scoped to one user needs no sign-in to know its user and no checkout to prove its worth.

Deferring isn't deleting. Accounts and payments can join a later version once the one question is answered, and a later part of this course covers what it takes to add them responsibly.

Pro Tip! Any feature that begins with "other people could..." belongs on the v2 list, not in the v1 build.