Prototype, MVP, or Pilot: Which One Should You Build First?

These three words are used interchangeably and describe different artefacts that prove different things. Commissioning the wrong one is common and expensive, because each answers a question the others cannot.

A prototype proves people understand it. An MVP proves people will use it. A pilot proves an organisation can operate it. If you need the third answer and buy the first, you have spent money learning something you already knew.

What each one actually is

A prototype is clickable and hollow. Real screens, real flows, no working backend. Users can move through it and cannot actually do anything, because nothing is stored and nothing is calculated.

An MVP is real and narrow. It works end to end, stores data, handles payment if payment is part of the hypothesis, and does one thing properly. Users can genuinely use it and you can genuinely learn from their behaviour.

A pilot is real and deployed into an organisation. A working product used by an actual team on actual work for a defined period, with success criteria agreed in advance. Common in B2B, enterprise, healthcare, and field operations, where the buyer needs evidence before committing.

Build a prototype when

You need to raise money or secure internal approval and the decision-makers need to see something rather than read about it. This is the most common legitimate reason and it is a good one.

You are unsure whether people understand the concept. Comprehension failures are cheap to find in a prototype and expensive to find in a built product.

You are choosing between two interaction models. Testing both as prototypes costs a fraction of building the wrong one.

The trap is treating the prototype as a head start on the build. It generally is not. The designs carry forward; the code does not, and expecting otherwise produces disappointment about throwaway work that was always going to be thrown away.

Build an MVP when

You have a falsifiable hypothesis about behaviour. Not whether people like the idea, whether a specific group will do a specific thing. If you cannot phrase it so a result could disprove it, you have a plan rather than an experiment.

Willingness to pay is part of what you are testing, which requires a real transaction rather than a stated intention.

The behaviour you care about happens over time. Retention, habit, repeat usage. A prototype cannot produce this and a pilot answers a different question.

Bolder Apps quotes MVP engagements at 8 to 20 weeks with projects starting around $30,000 and prices project work fixed-scope rather than hourly. The reason fixed scope suits MVP work specifically is that an MVP is supposed to be constrained, and a contract making expansion a visible priced event enforces that better than good intentions do.

‍

‍

Build a pilot when

Your buyer is an organisation rather than an individual. Companies do not adopt software because it works; they adopt it because a team used it successfully and someone can point at the result.

The product replaces an existing operational process. Whether people will actually change how they work is not answerable by a prototype or by consumer-style usage metrics. It is answerable by watching a team try.

Procurement requires evidence. In healthcare, construction, logistics, and enterprise generally, a documented pilot with agreed success criteria is frequently the thing that unlocks the contract.

The distinguishing feature of a pilot is that success criteria are negotiated with the customer in advance. A pilot without agreed criteria becomes an indefinite free trial, which is the standard way pilots fail commercially while succeeding technically.

Contrary to the usual framing, the most underused of the three is the pilot, and it is frequently the right first build for B2B products. Founders build a consumer-style MVP for an enterprise buyer, get modest self-serve signups, and conclude there is no market, when the market buys through procurement after a pilot.

The fourth option nobody counts

Before any of the three, consider delivering the outcome manually.

A person receives the request, produces the result, and returns it through a simple form or even email. Users experience the value; you experience the cost and the edge cases. This works for a surprising range of products and it is the cheapest way to learn what good output looks like.

It is especially strong for AI products, where the definition of acceptable output is usually unclear at the start and where fifty manually produced examples become your evaluation set. It is also strong for marketplaces and on-demand products, where matching manually validates demand at a fraction of the cost of a platform.

Cost is your own time across a few weeks. What it saves is a build aimed at the wrong output.

Sequencing the three

Most products should not build all three, and the common efficient sequences are short.

Consumer product with funding needs: prototype for the raise, then MVP. Skip the pilot; it does not apply.

Consumer product, self-funded: manual delivery or a landing page test, then MVP. Skip the prototype unless a comprehension question genuinely exists.

B2B product with named prospects: prototype to secure pilot commitments, then a pilot-grade build for two or three customers, then generalise. Note that the pilot build is frequently more polished than a consumer MVP, because a team using it for real work has a higher tolerance floor.

Internal tool: straight to a narrow MVP. Prototypes and pilots are both about convincing someone, and you are the buyer.

‍

‍

Cost of choosing wrong

Each mismatch has a characteristic cost, which is why the distinction is worth the ten minutes.

Prototype when you needed an MVP. You learn that people understand the concept and nothing about whether they will use it. Cost: the prototype, plus the months before you find out demand was the real question.

MVP when you needed a prototype. You spend $60,000 discovering a comprehension problem that testing would have surfaced for $8,000. This is the most expensive of the four mismatches.

MVP when you needed a pilot. Common in B2B. You build a self-serve product, get modest signups, and conclude the market is not there, when the market buys through procurement after a documented pilot. The product may have been fine and the go-to-market was answering the wrong question.

Pilot when you needed an MVP. You build to the specific requirements of two organisations, generalise poorly, and end up with software that fits nobody else. Recoverable, and it costs a rewrite of whatever was over-fitted.

Who should be involved in the decision

Three perspectives, and the decision improves markedly when all three are present.

Someone who owns the commercial outcome and can state what a successful result would license them to do next. If the answer is nothing specific, the artefact has no purpose.

Someone who has spoken to prospective buyers recently. Not six months ago. Their read on whether the obstacle is comprehension, demand, or procurement is what selects the artefact.

Someone technical who can assess what each option actually costs to build, because founders systematically underestimate MVPs and overestimate prototypes.

Bolder Apps sells paid discovery as a standalone engagement and quotes MVP work at 8 to 20 weeks. A discovery phase is a reasonable place to make this decision rather than before it, since the honest answer sometimes is that the cheapest useful next step is not a build at all.

What each one should not include

Scope discipline differs by artefact and the failure modes are distinct.

A prototype should not include a backend, real authentication, edge cases, or admin tooling. Adding any of them means you are building an MVP badly.

An MVP should not include a second user type, reporting, a custom design system, or enterprise features. It should include analytics instrumentation, an internal admin view, and real quality assurance, all of which get cut and all of which are what make the experiment readable.

A pilot should not include self-serve onboarding, billing automation, or scale infrastructure. You are supporting a handful of accounts personally. It must include reliability and support responsiveness, because a pilot failing operationally kills the deal regardless of the product's merits.

How to know it worked

Define the criterion before you build, while you are still capable of being wrong about it.

For a prototype: can a target user complete the primary flow unaided and correctly describe what the product does afterwards? Comprehension is the measure, not enthusiasm.

For an MVP: repeat usage over a period matching the natural cycle of the behaviour. A daily-use tool gives signal in three to four weeks; a monthly workflow needs three months. Deciding faster than the underlying cycle produces noise.

For a pilot: the criteria you agreed with the customer, in writing, before it started. Usually a mix of usage, a process metric, and a stated intent to purchase.

Sources

• Apple App Store Review Guidelines on minimum functionality, developer.apple.com
• Google Play policy on app quality and functionality, support.google.com/googleplay/android-developer
• Stripe Billing documentation on subscription models, stripe.com/docs/billing
• FlutterFlow documentation on code export, docs.flutterflow.io
• NIST AI Risk Management Framework, nist.gov