The 30-minute MVP — scoping discipline for vibe-coded apps

The reason vibe-coded MVPs stall is not the AI. It is the scope.

A clean 30-minute MVP is not magic — it is a discipline. Here is the shape that tends to work.

One job, one screen, one path

A 30-minute MVP does one thing for one person along one happy path.

• One job. "Convert a screenshot into a Tailwind component." Not "be a design system."
• One screen. A single page. No nav, no settings, no account.
• One path. Input goes in, output comes out, the user copies or saves it. No branches, no edge cases, no admin views.

If your first sketch has more than this, you are not building an MVP — you are building a product. Cut until the sentence above describes it cleanly.

Pick a stack you will not argue with

The 30 minutes start the moment you open your tool. Anything you have to decide costs minutes. Pick defaults and stop choosing:

• A framework you have shipped with before
• A hosting provider you already have an account on
• A styling system that matches the framework default
• Zero authentication unless the MVP literally cannot work without it

If you are deciding "Should we use Postgres or SQLite for this?" you are already over budget. Use whatever is built in.

Write the prompt before you write the code

The strongest 30-minute MVPs start with a 30-second prompt:

Build a page that takes a [thing] as input, calls [external service] with it, and shows the [result] in a card. Use [framework] and [styling]. No auth. One file if possible.

That prompt does three useful things. It commits you to scope. It commits you to a stack. And it gives the model a clear target so it does not invent features you did not ask for.

What you skip on purpose

A real MVP knowingly leaves the following out:

• Auth. Add later if needed. Many useful things do not need accounts.
• A database. Use in-memory state or local storage. You can add Postgres in version two.
• Error states that are not blocking. Show one toast. Move on.
• Empty states, success states, loading polish. Plain text is fine for the first version.
• Anyone else's needs. No team mode, no sharing, no exports.

You will add some of these later. You do not need them to validate the idea.

When 30 minutes is the wrong target

Some apps cannot be MVP'd in half an hour. Anything with real users on day one, anything that touches money or health, anything where security failure is unacceptable — those deserve real scope.

For everything else, the 30-minute MVP is the format. It is short enough that you will actually finish it, opinionated enough that you will not over-build, and concrete enough that real users can give you feedback the same evening.

If you are about to point the result at real users, run the ship checklist before you publish. The MVP did its job; now make sure it does not blow up when people use it.