The Wizard of Oz MVP, Explained

A wizard of oz MVP lets you test a finished-feeling product without building the expensive machinery underneath it. To the user, the thing works: they type a request, click a button, and a result comes back that looks like software produced it. Behind the curtain, a person is doing the work by hand. The name comes from the film, where an ordinary man pulls levers behind a screen while everyone believes they are talking to a great and powerful wizard. Done well, this technique lets you learn exactly how people use your product, and whether they will keep using it, before you commit to automating anything. This guide explains what it is, when it beats the alternatives, how to build one, what it costs, and where the ethical line sits.

What a wizard of oz MVP is

A wizard of oz MVP is a product experience that appears fully automated to the user while humans perform the work invisibly. The user interacts with a real interface: a web app, a form, a chat window. What they cannot see is that their request is routed to a person who fulfills it manually, then returns the result through the same interface, dressed up so it looks machine-generated.

Imagine a product that promises to turn any long PDF into a one-page summary in minutes. A wizard of oz version has a real upload page and a real "your summary is ready" screen. Between those two screens, no model runs. A person reads the document and writes the summary, then posts it back. The user believes they used an automated tool, and behaves exactly as they would with the real thing, which is the whole point.

Wizard of oz vs concierge vs landing page

All three are ways to test an idea before building it, but they answer different questions and expose different things to the user. Choosing the wrong one wastes the test.

The three often run in sequence. A landing page MVP tests the pull, a concierge phase teaches you the work, and a wizard of oz phase tests the actual interface and behavior before a single line of the automation exists. Wizard of oz sits closest to the finished product, which is why it is usually the last experiment before a real build.

When it is the right technique

Reach for a wizard of oz MVP when the expensive, risky part of your product is the automation itself, and you want proof that people will use the real experience before you pay to build that engine. It is the ideal test when:

• The core technology would be costly or slow to build, and you are not yet certain it is worth it.
• The value depends on the interface and flow, so you need users behaving naturally, not knowing a human is helping.
• You want to measure real usage, retention, and willingness to pay for the unassisted product.
• You can fulfill each request by hand fast enough that the delay feels believable.

It is the wrong choice when speed is the product and no human could keep up, when the volume would be impossible to serve manually even briefly, or when a wrong human-produced result could genuinely harm someone. In those cases, do not fake it.

How to build a wizard of oz MVP

The craft is in making a thin, real-looking front end while keeping the back end entirely manual. Here is the sequence.

1. Build only the interface the user touches. The input, the "working on it" state, and the result screen. Everything else can be held together with off-the-shelf tools.
2. Route requests to yourself. When a user submits, the request lands in your inbox, a spreadsheet, or a chat channel where a person picks it up.
3. Set an honest expectation of timing. "Your result will be ready in a few minutes" buys the human time without breaking the illusion. Do not promise instant if you cannot deliver instant.
4. Fulfill by hand, then return the result in-product. The user should receive the output through the same interface, formatted so it reads as automated.
5. Instrument everything. Track who submits, what they ask for, whether they come back, and whether they pay. The behavior is the data.
6. Log every manual step. Each thing you do by hand is a candidate for the automation you will eventually build, and a line in your future spec.

Notice how little you build. The front end is deliberately thin, which keeps the experiment cheap and fast. If you find yourself building the real engine "just to be safe," you have left the world of the wizard of oz MVP and started the actual product before proving you should.

What it costs and how long it lasts

A wizard of oz MVP is cheap in software and expensive in human time, which is the trade you want at this stage. The build is a light front end, so it is a small fraction of a full product. The running cost is your hours, or a small team's hours, spent fulfilling requests. That cost is a feature, not a bug: it caps how long you can run the experiment, which forces a decision.

In practice these tests last weeks, not months. You run it until one of two things happens: demand outpaces what humans can fulfill while keeping quality high, or you have gathered enough behavior to know exactly what to automate. Either outcome is a signal to build. If demand never materializes, you have learned that cheaply, without ever building the engine.

The ethics line

Faking automation is fine. Lying about the things that affect people is not. The line is straightforward if you hold to a few rules.

• Protect data honestly. If a human will read what the user submits, your privacy terms must allow it. Never claim data is processed automatically or never seen by a person if that is untrue.
• Do not over-promise the result. Stand behind every output a human produced as if it were the finished product, because to the user it is.
• Avoid high-stakes domains. Do not fake automation where a wrong answer could cause real harm, such as medical, legal, or financial decisions.
• Keep it short and delete the theater afterward. A wizard of oz MVP is a temporary experiment, not a permanent way to run a business.

Turning the curtain into real automation

When the test succeeds, you are in an unusually strong position to build, because you already know precisely what the software must do. You have watched real users behave, you know which steps they value, and you have a record of every manual action to automate. That is a spec grounded in evidence, and it feeds directly into disciplined feature prioritization: automate the steps users actually hit, defer the ones they never reach.

To turn that evidence into a number, run the feature list through the free MVP cost calculator, then compare the routes in how much an MVP costs in 2026. At SquadPrime we build the real, automated version at a fixed price from $4,000, with senior professionals and full code ownership for you. A successful wizard of oz test is the best brief you can hand a build team, because there is almost nothing left to guess.

FAQ

What is a wizard of oz MVP?

A wizard of oz MVP is a product that looks fully automated to the user while people perform the work manually behind the scenes. The customer interacts with a real-feeling front end and cannot tell that a human, not software, is producing the result. It lets you test the real experience before building the expensive automation underneath.

How is a wizard of oz MVP different from a concierge MVP?

The difference is what the user knows. In a concierge MVP the customer knows a person is helping them directly. In a wizard of oz MVP the customer believes they are using finished software and never sees the humans behind the curtain. Concierge tests the value openly; wizard of oz tests the unassisted product experience.

Is a wizard of oz MVP ethical?

It can be, if you are honest about the things that matter. You may simulate the automation, but you must not lie about how personal data is handled, make promises you cannot keep, or expose people to real harm from a wrong result. Keep the test short, protect the data, and stand fully behind every result a human produced.

How long can you run a wizard of oz MVP?

Only as long as humans can keep up with demand and quality, which is usually a matter of weeks, not months. The moment the manual work behind the curtain becomes the bottleneck, or you cannot serve requests fast enough to keep the illusion, it is time to automate the parts you have proven people actually use.

All third-party names and trademarks belong to their respective owners and are used for identification only. Any market figures reflect our experience building MVPs and typical ranges as of September 21, 2026, and may change at any time. Spotted something outdated or inaccurate? Email talk@squadprime.com and we'll correct it promptly.

Related: The Concierge MVP, explained · The Landing Page MVP, explained