Concierge MVP: Deliver Your Product Manually First
A concierge MVP is a test where you personally deliver the outcome your product would eventually automate, by hand, to a small number of real paying customers, before writing the software that does the work for you. Instead of building a scheduling app, you become the scheduler. You email, call, and assemble the result yourself. It is the slowest MVP to run, and often the fastest way to learn what your customers actually need.
Quick Answer: A concierge MVP replaces your product with you. You deliver the same outcome a customer would eventually get from software, but manually, one customer at a time, for real money. It proves people will pay for the outcome, and it shows you which parts of the process are genuinely hard, before you spend months automating the wrong ones.
How a concierge MVP works, step by step
The mechanics are simple on purpose. The value comes from doing this with real customers and real money, not from the sophistication of the process.
- Define the outcome, not the feature list. Write one sentence describing what the customer walks away with — "a weekly meal plan that fits their allergy restrictions," not "an app with a recipe database and a shopping list generator." Everything downstream should serve that sentence.
- Find a small number of people who already have the problem. Five to ten is plenty to start. This is where a structured approach to sourcing and running interviews pays off — the complete guide to customer research covers how to find people worth talking to instead of guessing at who your audience is.
- Charge them real money from the first customer. Even a modest, real fee changes the conversation. A free pilot gets you polite feedback; a paid one gets you a customer who will tell you when the thing you handed them doesn't work.
- Deliver the outcome using whatever tools already exist. A spreadsheet, a shared document, a phone call, a text message. None of it needs to look like a product, because it isn't one yet — you are the product.
- Log every manual step as if you were writing a spec. Each time you do something by hand, note what it was, how long it took, and whether it was easy or painful. That log becomes the actual requirements document for whatever you eventually build.
- Run it for a few cycles, then make a real decision. Keep serving customers manually, build software for the piece that hurt the most to do by hand, or kill the idea because nobody was willing to pay for the outcome in the first place.
This is one stage in a broader sequence, not a standalone trick — see the lean experiment playbook for how a concierge MVP fits alongside interviews, smoke tests, and other experiments earlier and later in the process.
A concierge MVP in practice: meal plans delivered by hand
Concrete details make the pattern easier to copy than a definition alone, so picture one founder running the whole loop end to end.
Say a founder named Priya wants to build software that generates weekly meal plans for families managing multiple food allergies — an outcome that normally requires cross-referencing ingredient lists, substitution rules, and a family's specific restrictions. Rather than building that logic first, she posts in two allergy-parent Facebook groups offering to build five families a personalized weekly meal plan and grocery list for $25, delivered every Friday for a month. Three families reply and pay.
Each week, Priya does the work herself in a spreadsheet: she pulls recipes from a handful of allergy-friendly sites, checks each ingredient against the family's restriction list by hand, swaps anything that conflicts, and formats the plan and shopping list into a shared Google Doc she emails Thursday night. The first week takes her nearly four hours per family. By the third week, she has built herself a personal reference sheet of safe substitutions that cuts that down substantially — and that reference sheet, not a line of code, is the actual product insight: the substitution logic, not the meal plan itself, was the hard part worth automating.
Two of the three families renew for a second month. One drops out, telling her plainly that the grocery list format didn't match how she actually shops. That single piece of blunt feedback, delivered because she'd paid for the service and expected it to fit her life, is worth more than a dozen "I'd definitely use that" comments from people with nothing at stake. By the end of the month, Priya knows three things a landing page could never have told her: families will pay for this, the substitution matching is the part worth building software around first, and the delivery format needs to change before she writes any code for it.
Concierge MVP vs. Wizard of Oz vs. a clickable prototype
These three approaches are easy to blur together because none of them require finished software, but they test different things and the differences matter for what you build next.
| Approach | What the customer experiences | What's actually running behind it | Best used to test | Main limitation |
|---|---|---|---|---|
| Concierge MVP | A person doing the work for them, openly | Nothing automated — you are the entire backend | Whether people will pay for the outcome at all | Doesn't scale past a handful of customers; you are the bottleneck |
| Wizard of Oz MVP | What looks like a working, automated product | A human manually operating the "automated" parts behind the scenes | Whether the workflow and interface hold up once it looks automated | Depends on the customer believing it's automated — a trust risk if they find out otherwise |
| Clickable prototype | A non-functional mockup of screens and flows | Nothing is delivered; no real outcome changes hands | Whether the interface and flow are clear before building anything | Produces opinions about a mockup, not evidence anyone will pay or use it |
The distinction that trips people up most is between a concierge MVP and a Wizard of Oz MVP: in a concierge test, the customer knows a person is doing the work, because the whole point is an honest, if unscalable, service. In a Wizard of Oz test, the customer believes they're using automated software, while a human quietly operates the parts that aren't built yet. Both are legitimate, but they answer different questions — a concierge MVP tells you whether the outcome is worth paying for, while a Wizard of Oz test tells you whether an automated-feeling interface actually works once people believe it's real.
When a concierge MVP is worth running, and where it breaks down
A concierge MVP earns its slowness when the biggest open question is whether anyone wants the outcome badly enough to pay for it, and the biggest risk of skipping it is building automation for a problem nobody actually has.
What it's genuinely good at proving. It gets you a real signal on willingness to pay, because a customer handing over money for a manual, unpolished service is telling you something a survey response can't. It surfaces the actual shape of the work — which steps are tedious but easy, and which ones are the real, hard problem worth solving with software. And it gives you honest unit economics before you've built anything: if delivering the outcome by hand costs you four hours per customer per week, you now know exactly what automation needs to replace.
Where it stops being useful. A concierge MVP tells you almost nothing about whether your product is easy to use once it's actually software — you were the interface, and you adapted around every rough edge a customer would have hit. It doesn't test technical feasibility if your product's whole differentiator is a hard automation or algorithm problem; delivering the outcome by hand proves demand, not that the automation is buildable. And because you're the delivery mechanism, the sample stays small by necessity — three or ten customers, not the hundreds you'd need to spot patterns across a market.
The mistakes that quietly waste the exercise. The most common is running it for free — without real payment, you're back to collecting opinions, just dressed up as a pilot. A close second is over-delivering: doing so much manual hand-holding that customers get an experience no software could ever replicate, which inflates how good the results look. A third is skipping the log in step 5 — without notes on what was actually hard to do by hand, you learn nothing you can hand to an engineer later. And the last is never stopping: a concierge MVP is a test with an expiration date, not a permanent way to run a service, so it needs an explicit decision point, not an indefinite extension.
Key Takeaways
- A concierge MVP replaces the product with you. You deliver the outcome by hand, for real money, before building any software to automate it.
- Real payment is what separates it from a survey. A customer paying for a manual service tells you something a compliment or a signup never can.
- The manual work itself is the requirements document. What's tedious but easy to do by hand can often stay manual longer; what's genuinely hard is what's worth automating first.
- It's different from a Wizard of Oz MVP in one key way. A concierge MVP is openly a person doing the work; a Wizard of Oz test hides the human behind what looks like automation.
- It proves demand, not usability or technical feasibility. You were the interface, so it tells you little about whether the eventual software will be easy to use or buildable.
- Keep the sample small and the timeline short. Three to ten customers and a handful of delivery cycles is enough to decide whether to build, stay manual, or kill the idea.
- Set an end date before you start. A concierge MVP is a test, not a business model — decide upfront when you'll stop and make the build-or-kill call.
Frequently Asked Questions
What is a concierge MVP?
A concierge MVP is a validation method where the founder personally and openly delivers the outcome a product would eventually automate, to a small group of real paying customers, using manual tools like spreadsheets, email, and phone calls instead of software. It tests whether people will pay for the outcome before any of the automation gets built.
How is a concierge MVP different from a Wizard of Oz MVP?
The customer's awareness is the difference. In a concierge MVP, the customer knows a person is doing the work by hand — it's an openly manual service. In a Wizard of Oz MVP, the customer believes they're using automated software, while a person is secretly performing the "automated" steps behind the interface.
How many customers do you need for a concierge MVP to mean anything?
There's no fixed number, but three to ten paying customers is typically enough to learn whether the outcome is worth paying for and which manual steps are actually painful, since you're doing the delivery work yourself and can't scale past a handful of people anyway. The goal is a real decision, not statistical certainty.
When should you stop running a concierge MVP and start building software?
Stop when one manual step is consistently the most time-consuming or error-prone part of delivering the outcome, and customers have already shown they'll pay for the result — that combination tells you exactly what to automate first. If customers stop paying or renewing partway through, that's also a decision point: the idea, not the delivery method, is what needs to change.