The MVP playbook was written for a world where code was expensive. Every classic tip, fake the backend, do things that do not scale, launch with a landing page, exists because engineering time was the binding constraint. AI tooling has loosened that constraint dramatically, and it changes the playbook more than most founders realise.

The bottleneck moved from building to deciding

With a capable AI coding assistant, a solo developer can stand up an authenticated, database-backed web app with payments in days. Which means the scarce resource is no longer construction, it is clarity. Teams now burn their time arguing about what to build while the building itself takes an afternoon.

The corrective is to time-box decisions harder than code. Write the one-page spec: who the user is, the one job the MVP does, the one metric that proves it works. If a feature debate runs past thirty minutes, build both versions behind a flag and let five users settle it. That sentence was absurd in 2020. It is ordinary now.

Scope by risk, not by feature list

Because features are cheap, the temptation is to ship more of them. Fight it. The MVP question was never "how much can we build?" but "what is the riskiest assumption, and what is the smallest thing that tests it?"

Sort your assumptions:

  • Desire risk: does anyone want this? Test with a concierge version or a waitlist before writing code.
  • Workflow risk: will they change their habits to use it? Test with a rough but real app in ten hands.
  • Feasibility risk: can the AI feature actually perform? Test with a script over fifty real examples before building any UI around it.

That last one is new and widely skipped. Founders build a polished app around a model capability they never benchmarked, then discover the extraction accuracy is 80 percent when the business needs 99. Run the model on real data first. It costs a day and saves a quarter.

Let the AI build wide, but you build the spine

A practical division of labour has emerged for AI-assisted MVPs. Let the tooling generate the breadth: screens, forms, CRUD endpoints, email templates, admin views. Reserve human attention for the spine:

  • The data model. Migrations outlive everything; a sloppy schema taxes you forever.
  • Money paths. Read every line touching payments, credits or refunds.
  • Authentication and permissions. Models write plausible-looking access control with real holes.
  • The one algorithm or prompt chain that is your actual product.

A useful habit: ask the assistant to explain any generated code you are about to trust, then ask it to attack that same code as a critic. The second pass catches a surprising share of the first pass's mistakes.

Cheap to build means cheap to rebuild

Here is the most liberating consequence: the MVP no longer has to become the product. When version one took six months, teams clung to its codebase for years. When it took three weeks, you can afford to treat it as a disposable experiment, keep the schema and the learnings, regenerate the rest properly once the direction is proven.

Say this out loud at the start: "this codebase is a probe, not a foundation." It changes how much perfectionism you permit yourself, and it removes the sunk-cost argument later.

The traps that sink AI-built MVPs

A few failure modes come up repeatedly:

  • Demo-driven delusion: the app works on the happy path shown in the demo and nowhere else. Fix: test with real, messy user data from day three.
  • Invisible costs: an AI feature priced at nothing that spends a rupee per user interaction. Track cost per action from the first week.
  • Nobody understands the code: fine for a probe, fatal for a product. Before scaling, budget a hardening pass where a human owns every module.
  • Compliance afterthoughts: user data in prompts, no deletion path, no terms. Cheap to add early, expensive after launch.

Two weeks, honestly spent

A realistic modern MVP fortnight looks like: two days of decisions and model benchmarking, five days of AI-assisted building with human review on the spine, two days with real users in the room, and the rest fixing what those users broke. Small teams anywhere, including here in Mauritius where engineering talent is capable but scarce, can now run this loop several times a quarter. The winners will not be the teams that build fastest. They will be the teams that learn fastest, and finally, the tools agree with them.