A concierge MVP is a version of your product where you deliver the service to a few customers by hand, openly, before you build any software. The customer knows a person is doing the work. That's the point. You aren't testing a screen or a feature. You're testing whether people want the outcome badly enough to take it from a human, and you learn what the job actually involves while you do it. As of October 2026, after 15 years of building products, I treat it as the cheapest honest test there is for a service-shaped idea. It answers one question well and a second question not at all.
What is a concierge MVP?
A concierge MVP is a test where you deliver the service to a few customers by hand, openly, before you build any software. The customer knows a person is doing the work. You learn whether people want the outcome and what the job really involves, with the smallest possible build.
The idea sits in the Lean Startup lineage. Eric Ries describes it in The Lean Startup. I'm working from my own reading of it, not quoting it.
Think of a hotel concierge. They don't have an app that books your dinner. They make a phone call. If enough guests ask for dinner reservations, someone eventually builds the app.
That's the whole method. You're the app.
What is the difference between a concierge MVP and Wizard of Oz?
The difference is who knows. In a concierge MVP the customer knows a person is doing the work. In a Wizard of Oz test the product looks automated and a person hides behind it. Concierge tests whether people want the outcome. Wizard of Oz tests whether they will use the automated experience.
The Wizard of Oz name comes from human-computer interaction research, where a hidden person plays the part of a system that doesn't exist yet. I haven't verified the original source, so I won't give you a date or a name for it.
Here's how I keep the two apart. The table below is my own framing, not a standard.
| Concierge MVP | Wizard of Oz | |
|---|---|---|
| Does the customer know a human is involved? | Yes | No |
| What it proves | People want the outcome | People will use the automated experience |
| What it can't prove | That software can match the human | That the outcome is worth wanting, if the front end is doing the selling |
| How it misleads | A warm, attentive human flatters the product | A convincing front end hides how fragile the back end is |
| Cost to run | Your time | Your time plus a believable interface |
| Best fit | You aren't sure the problem is real | You're sure the problem is real and unsure about the interaction |
Read the "how it misleads" row twice. That's where most of the damage happens.
What does a concierge MVP prove?
It proves demand for the outcome. If people give up time or money to receive the result from a person, the result is worth something. You also get a written record of the real steps, the edge cases, and the questions customers ask, which no spec meeting produces.
I'd call this observation, not inference. If a customer pays you to do the thing by hand, you watched them want it.
The second gain is quieter. Doing the work yourself shows you which steps are the job and which are ceremony. The steps you skip on the third customer are usually not the ones to automate.
What can a concierge MVP not tell you?
It cannot tell you whether the automated version will hold up. A person adapts, apologizes, and fixes mistakes on the spot, and software will not. It also cannot tell you whether the work scales, because one person serving ten customers hides the cost of serving ten thousand.
This is the trap. A good concierge test makes customers happy, and happy customers feel like evidence for the product. They are evidence for you.
My inference, and it is only that: the more a customer's praise mentions the person ("thanks for being so responsive"), the less it tells you about the software. Praise for the outcome transfers. Praise for the human doesn't.
If your idea depends on the software being good at something hard, a concierge test can't settle that. You need a proof of concept for it. I wrote a proof of concept template that names the one question and the stop condition before you start.
How do you run a concierge MVP in a week?
Pick one outcome, three to five customers, and a written pass line before the first session. Do the work by hand, in the open. Log every step and every surprise. At the end, compare what happened to the pass line you wrote first, not the one you'd like now.
Here is the plan I'd copy. It's a template, not a case study.
CONCIERGE MVP PLAN
Question: Will people want <outcome> enough to <give time or money>?
Customers: 3 to 5, recruited by hand
Promise: <the outcome, in one sentence, and that a person delivers it>
Pass line (written BEFORE we start):
At least 3 of 5 ask for a second delivery.
At least 2 of 5 agree to pay, or to pay more, for the next one.
Log, every delivery:
- Steps I took, in order
- Steps that took longer than expected
- Questions the customer asked
- Anything I did that the customer never noticed
Stop when:
The pass line is met or missed, OR
Manual work per customer is growing faster than what I learn.
What this test cannot tell us:
Whether software can do the steps as well as I did.
The pass line is the part people skip. Write it first. Without it, any outcome looks like a win.
The last line matters too. Writing down what the test can't tell you is how you keep from treating it as more than it is. It's the same discipline as the proof of concept: one question, one stop condition.
When does a concierge MVP mislead you?
It misleads when your attention is the product. If customers like it because you're quick, kind, and available, you've measured your service, not your idea. It also misleads when you pick friendly customers, or when you quietly fix every failure before they notice.
Three habits keep it honest. Recruit at least some customers you don't know. Ask what they'd do if you vanished tomorrow. And log the failures you hid, because those are the first requirements for the software.
I don't have a clean number for how many customers is enough. Three to five is a starting point from my own practice, not a rule. If the answers are all the same by the third, you can probably stop. If they all differ, you have a different problem than demand.
When should you stop running a concierge MVP?
Stop when you can write down the repeatable steps and the next customer would not teach you anything new. Stop earlier if the manual work grows faster than the learning. A concierge test is meant to answer one question, and once it has, continuing means you are running a small services business.
That last point isn't an insult. Some of these tests turn into a good small business, and that's a fine outcome. It's a different decision from building software, and you should make it on purpose.
When you do build, build the step that cost you the most time by hand first. Then run a Wizard of Oz test on the interaction before you finish the back end. The two methods work best in that order: concierge for the outcome, Wizard of Oz for the experience, and a proof of concept for the part that might not be possible.
If you want the wider picture of how a concierge test fits among other first versions, start with what an MVP in software development actually is. And if the real problem is that people say they want something and then don't use it, I wrote about that gap in the say-do gap.