The MVP Is Dead. Build a Minimum Credible Product.

Is the MVP dead? The learning method is not. The excuse is. AI has made prototypes dramatically easier to produce, so users, investors, and buyers no longer interpret a rough product as proof that a team moved fast. They increasingly interpret it as proof that the team did not test, prioritise, or finish the one path that matters.

The better target is a minimum credible product: the smallest version that can test the riskiest business assumption without asking the user to forgive avoidable failures. It has fewer features than most MVPs, but the feature it keeps works end to end and earns enough trust for the next decision.

This does not mean polishing every corner or building for imaginary scale. It means the old sentence “it is just an MVP” can no longer carry the weight founders keep putting on it.

What changed about the minimum viable product?

The original MVP was not supposed to mean bad software. Eric Ries describes it as the simplest version that starts the learning process quickly: a way to test core business assumptions with real users before committing serious resources.

That logic still holds. What changed is the credibility threshold around the experiment.

When software was expensive to produce, visible roughness communicated constraint. A basic interface and manual workflow could say: this team spent its scarce engineering time testing the important assumption. Today, a polished interface, generated API, database schema, tests, and deployment can appear in days. The same roughness now sends a different signal: if the cheap, visible layer is unfinished, what happened to the parts users cannot see?

AI changed the social contract around early software:

• Users expect the happy path to feel complete. They have too many alternatives to debug your onboarding out of sympathy.
• Investors expect a demo to survive basic questions. A generated dashboard is no longer evidence of technical progress on its own.
• Enterprise buyers move the credibility floor higher. Permissions, data handling, auditability, integrations, and ownership arrive in the pilot conversation, not after it.
• Founders expect smaller teams to produce more. Whether that expectation is fair or not, it changes what an early product has to communicate.

The cost of producing code fell. The cost of being taken seriously rose.

Prototype vs MVP vs minimum credible product

These are not three levels of polish. They answer three different questions.

The prototype proves possibility. The MVP tries to prove demand. The minimum credible product proves enough value and trust to earn the next commitment.

Is software engineering dead because AI writes code?

No. AI is compressing parts of software production, not eliminating the need to decide what should exist, how it should fail, and what evidence makes it safe to ship.

The productivity evidence is also less theatrical than the timeline. GitHub reported that Copilot users completed one controlled coding task up to 55% faster. In a very different 2025 study, METR found experienced open-source developers working in familiar, mature repositories took longer with the tools available at the time. METR's 2026 follow-up found signs that newer agents were helping, but also explained why clean measurement had become difficult.

Those results are not contradictory. They describe different work. AI is excellent at generating bounded output when the goal, context, and verification are clear. Real product work is full of missing context, competing goals, unspoken constraints, and consequences that do not fit inside a coding benchmark.

Google Cloud's 2025 DORA research reaches the more useful organisational conclusion: AI acts as an amplifier of the system around it. Strong teams can turn faster output into better delivery. Weak product discipline can turn the same output into more instability and more software nobody needed.

"A 100x engineer building the wrong product is not 100x more valuable. They are 100x faster at creating debt."

Engineering was never just typing code. The scarce work is increasingly judgment:

• Which feature should not exist?
• Which edge case destroys trust rather than merely annoys?
• Which shortcut is reversible, and which one forces a rewrite?
• Which user problem is painful enough to pay for now?
• Which metric would distinguish real learning from demo applause?
• Where must a human review AI output before it creates a consequence?

AI can help answer these questions. It cannot own the consequences of getting them wrong.

What is a minimum credible product?

A minimum credible product is the smallest product that solves one painful problem through one complete, trustworthy path and produces evidence for the next business decision. It is minimal in scope, not in care. Its quality bar is set by what would make the experiment's result believable.

We use minimum credible product as a practical operating term, not as an established industry standard. In this article, MCP means minimum credible product, not Model Context Protocol. The acronym collision is unfortunate. The distinction is simple: one is a product strategy concept; the other is a technical protocol for connecting AI systems to tools and data.

A minimum credible product has seven parts:

1. One painful problem. If the scope needs “and” three times, it is probably three products pretending to be one MVP.
2. One specific user. Not small businesses, teams, or knowledge workers. Name the person, situation, and trigger that makes the problem urgent.
3. One reason to return or pay. The product must create a repeatable outcome, not just a five-minute moment of surprise.
4. One complete production path. The core workflow covers input, processing, output, errors, and recovery. A beautiful screen over an unreliable path is still a prototype.
5. A trust floor matched to the stakes. Authentication, permissions, privacy, QA, and human approval belong wherever failure would make the test meaningless or unsafe.
6. Evidence, not vanity telemetry. Instrument the behaviour that answers the business question: completed tasks, repeat use, paid conversion, time saved, approval rate, or another decision-grade measure.
7. An explicit exclusion list. Credible does not mean broad. Write down what will not ship so faster code generation cannot smuggle scope back into the build.

Does a minimum credible product mean overbuilding?

No. Overbuilding adds capabilities before evidence demands them. Credibility removes capabilities until the remaining path can produce a trustworthy signal. A minimum credible product may use manual operations, a hosted model, a simple architecture, and only one integration. It just does not hide unsafe or incomplete work behind the MVP label.

The useful rule is simple: build the safeguards that protect the validity of the experiment. Delay the machinery that only protects an imagined future.

What does a minimum credible AI product look like?

Imagine a B2B assistant that answers questions from company documents.

The prototype uploads one PDF and returns a convincing answer in a clean chat interface. It proves the interaction can work.

The weak AI MVP connects a shared document folder, adds login, and launches. It looks finished, but every user can retrieve every document, answers have no source links, failures are silent, and nobody measures answer quality. Usage data from that product is contaminated: if people leave, you cannot tell whether they rejected the idea or simply did not trust the implementation.

The minimum credible product serves one department and one document source. It respects the source system's permissions, cites the passages behind each answer, refuses or escalates when evidence is missing, logs quality and cost, and gives the user a clear correction path. It does less. The learning is worth more.

The exact credibility floor changes with the risk. A private tool that drafts internal social posts needs a different bar from software that recommends a medical action, moves money, or exposes customer records. Credibility is contextual, not a fixed checklist.

For the technical checks that apply once real users and data are involved, use the vibe-code production-readiness checklist. For AI-specific acceptance criteria, eval sets, and launch gates, use the AI MVP scope template.

How do you scope a minimum credible product?

Start with the decision, not the feature list. A useful scope can answer these six questions in plain language:

1. What is the riskiest assumption? Demand, willingness to pay, repeat use, technical feasibility, trust, or procurement? Pick one primary risk.
2. Whose behaviour can resolve it? Name the smallest reachable user segment with the problem and authority to act.
3. What is the smallest complete loop? Define the moment the user enters, receives the outcome, and knows what to do next.
4. What failure would invalidate the test? If a permissions bug, wrong answer, slow response, or broken handoff would make rejection ambiguous, it belongs inside the credibility floor.
5. What observable event changes the next decision? Ten paid pilots, 40% weekly repeat use, a signed procurement step, or another threshold agreed before launch.
6. What are we refusing to build? Put the feature cemetery beside the scope. AI makes resurrection dangerously cheap.

This order matters. If a team starts by asking what it can generate this week, the result will be a list of output. If it starts with the business risk, it can decide which output deserves to exist.

When should you still use a prototype instead?

Use a prototype when the audience understands it is an experiment and the question does not require real trust. A clickable flow for five customer interviews, a technical spike, a fake-door test, or an internal demo can be rough because nobody is being asked to depend on it.

Do not quietly turn that prototype into production because the demo went well. The moment real money, customer data, operational dependence, or brand trust enters the loop, the artifact has a different job. Our guide to moving from Lovable or Cursor prototype to production maps the engineering work hidden inside that change.

What should founders demand from a development partner?

“We can build it” is table stakes. The harder and more valuable questions are:

• Should this be built at all?
• Which business risk is this version supposed to resolve?
• What is the cheapest honest test before custom software?
• Which part needs production-grade engineering on day one?
• What can remain manual until users prove it matters?
• What evidence will make us stop, continue, or invest more?

Discovery, product leadership, software development, AI integration, and QA are related, but they are not the same job. Treating them as one generic build-me-an-MVP task is how a team gets a fast prototype and a slow business.

A serious partner should narrow the scope before expanding the estimate. They should be able to explain which shortcuts are intentional, which risks are blocked, and what the first release is designed to prove. That is the standard behind our MVP development work: software that ships and sells, not software that merely demos.