Concierge MVP: How to Run One, with Examples

TL;DR

A concierge MVP is a validation method where you personally deliver, by hand and out in the open, the service your product will eventually automate, so you learn exactly what to build before writing any code. The customer knows a human is doing the work, which is the whole point: it buys you the deepest possible insight into what they actually need, step by step. It is the right MVP type when your biggest unknown is not whether people want a solution, but what the solution should actually be. It does not scale, and that is by design.

Where it leads: a concierge MVP teaches you the workflow; the next move is to automate the part that proved valuable. At HorizonLux we help founders run that learning and then build the real product, usually a single-feature MVP shipped funding-ready in under 4 weeks. This guide covers how to run a concierge MVP well, with real examples and a step-by-step playbook. It is one of the eight types of MVP in our wider map.

What is a concierge MVP?

A concierge MVP is a manual, high-touch test where the founder personally performs the service that software will later do automatically. If you are building an AI meal planner, you become the meal planner: you talk to each customer, build their plan by hand, and deliver it yourself. No product exists yet. You are the product.

The name comes from a hotel concierge: a real person who handles your request personally, attentively, and visibly. That visibility is the defining trait. The customer knows the service is being delivered by hand, and they expect the hands-on attention. You are not pretending to be software. You are deliberately doing the manual version so you can watch, up close, exactly what creates value and exactly where the eventual product needs to be smart.

The purpose is learning, not scale. A concierge MVP answers the question "what should we actually build?" by letting you discover the real workflow through real delivery, instead of guessing it from a whiteboard. You learn the steps, the edge cases, the moments that matter, and the parts customers do not care about, before you spend a cent on engineering.

Concierge MVP vs Wizard of Oz MVP

The concierge MVP is constantly confused with its sibling, the Wizard of Oz MVP, because both deliver value manually. The difference is one word: transparency.

The simplest way to hold the distinction: a concierge test is conducted behind the desk, in plain view, while a Wizard of Oz test happens behind the curtain. Use the concierge approach when the idea is novel and you are still figuring out what the product even is. Use Wizard of Oz when you already know the solution and want to test whether people will use it as if it were automated. Many founders run them in sequence: concierge first to learn, then Wizard of Oz to validate. We cover the hidden-automation sibling in the full Wizard of Oz MVP guide.

When to use a concierge MVP

A concierge MVP shines in specific situations and wastes effort in others. Reach for it when:

• Your product is a service or a workflow. Anything that guides a user through steps (planning, matching, recommending, advising) is a natural fit, because you can perform those steps by hand.
• You do not yet know what to build. The idea is novel enough that the right feature set is genuinely unclear. Concierge delivery surfaces the answer.
• Qualitative depth matters more than volume. You want to deeply understand a few users rather than lightly measure many.
• The cost of building the wrong thing is high. A few weeks of manual service is far cheaper than months of building a product nobody needed.

Skip the concierge approach when:

• Your only real risk is demand. If the question is just "do people want this," a cheaper demand-validation MVP (a landing page or fake door) answers it faster.
• The value cannot be delivered by hand. Some products (real-time, high-volume, or technically complex at their core) cannot be meaningfully faked manually.
• You already know the workflow cold. If you have run this service before and understand it deeply, you may be ready to build a single-feature MVP directly.

How to run a concierge MVP: a step-by-step playbook

The concierge MVP looks simple, but running one well takes discipline. Here is the playbook we use.

Step 1: Narrow the market to one segment

Pick the smallest, sharpest customer segment you can: one persona, one neighborhood, one industry niche. A narrow market makes the manual work manageable and the insights clean. You are not trying to serve everyone; you are trying to deeply understand a specific someone. Breadth comes later, after you know what you are building.

Step 2: Recruit users one by one, personally

Do not wait for sign-ups. Go and find your first few customers yourself: direct outreach, your network, the communities where they already gather. Personally invite and onboard each one. At this stage, ten engaged customers you recruited by hand are worth more than a thousand anonymous email addresses, because you can actually talk to them.

Step 3: Deliver the service by hand, in the open

Now do the work. Perform the service manually, end to end, for each customer, and be transparent that you are doing it personally. Watch everything: what they ask for, where they hesitate, what delights them, what they ignore. The goal is not just to satisfy them; it is to learn the real shape of the solution from the act of delivering it.

Step 4: Charge real money

This is the step founders skip, and it is the most important. Charge for the service, even a small amount. Willingness to pay is the strongest validation signal there is, far stronger than a "yes, I would use that." Food on the Table charged $9.95 a week from the very first hand-built meal plan. Real money turns a friendly experiment into a real test.

Step 5: Document everything into a spec

Every delivery is research. Write down the steps you took, the decisions you made, the rules you followed, and the moments that mattered to the customer. Over a handful of customers, patterns emerge: this is the workflow, these are the rules, here is where judgment is needed. That document becomes the specification for the eventual product. You are not just serving customers; you are reverse-engineering your own product from real delivery.

Step 6: Find the repeatable workflow, then automate

After enough cycles, you will see which parts of the service are repeatable and valuable, and which were noise. Automate only the validated workflow, the part that customers paid for and came back for. This is the bridge from concierge MVP to a real product, usually a single-feature MVP built around the one workflow that proved its worth. You build software to scale something you already know works, instead of guessing.

A worked example: a concierge MVP in action

To make the playbook concrete, here is how it plays out for a realistic product. Imagine you want to build an AI tool that writes personalized cold-outreach emails for B2B sales teams. The automated vision is software that ingests a prospect list and generates tailored emails. The concierge version skips the software entirely.

Narrow the segment (Step 1). You do not target "all salespeople." You pick solo founders selling a B2B SaaS product under $200 a month: a sharp, reachable niche with a clear pain.

Recruit by hand (Step 2). You find ten of them in a founder community, message each personally, and offer to write their cold emails for a week. You onboard each one yourself, learning their product and their target customer in a short call.

Deliver openly (Step 3). Each day you personally research their prospects and write the emails by hand, telling them clearly that you are doing it yourself. You watch which emails they actually send, which they edit, and which they discard, and you ask why.

Charge (Step 4). You charge $50 for the week. Five of the ten pay without hesitation, three negotiate, two drop out. That split is data: real willingness to pay, and a read on price sensitivity.

Document (Step 5). After a week your notes reveal the pattern: the emails that landed all opened with a specific, researched observation about the prospect, and the founders valued the research far more than the writing. That insight is the prize. It tells you the product's core is the research, not the prose.

Automate the proven part (Step 6). You now know what to build: not a generic email writer, but a tool that surfaces the one sharp, researched hook per prospect. That is your single-feature MVP, and you discovered it by hand instead of guessing.

The whole exercise took two weeks, cost nothing but time, earned a little revenue, and replaced a dozen risky assumptions with a validated product spec. That is the concierge MVP doing exactly its job.

The concierge MVP toolkit: scripts and templates

Running a concierge MVP is easier with a few reusable pieces. Adapt these to your product.

The recruiting message. Keep it personal, specific, and honest about the manual nature:

"Hi [name], I am building something to help [specific person] with [specific problem]. Before I build it, I am doing it by hand for a few people to learn what actually helps. Can I do [the service] for you this week for [small price]? You would get [clear benefit], and I would get to learn from your feedback."

The delivery-and-learning loop. For each customer, each cycle:

1. Deliver the service by hand.
2. Note what they asked for, edited, or rejected, and why.
3. Ask one open question: "What was most and least useful about this?"
4. Record the answer in their own words.

The spec-extraction template. After each customer, fill in:

• What steps did I perform, in order?
• Which steps created the value the customer actually cared about?
• Which steps did the customer not care about?
• What rules or judgment did I apply that software would need to replicate?
• What surprised me?

After five to ten customers, these notes converge into a product specification grounded in real delivery, the single most valuable artifact a concierge MVP produces.

Real concierge MVP examples

Food on the Table (the textbook example)

The cleanest concierge MVP in startup history. Before building any software, founders Manuel Rosso and his team personally met with each customer, ran an in-depth interview to learn their food preferences, manually searched a local grocery store's catalog, matched recipes to what was on sale, and hand-delivered a custom meal plan and shopping list, charging $9.95 a week. Every week they returned, offered the white-glove service again, and drew insight on how the eventual technology should work and what actually created value. Only after the workflow was proven did they build software, eventually scaling to thousands of stores. They had revenue and a validated product spec before they hired a single developer.

Airbnb

Early Airbnb is often cited as concierge-style validation. The founders did not just list a site and wait. They photographed listings themselves, communicated directly with hosts and guests, and managed bookings by hand, learning the real friction in the marketplace before automating any of it. The hands-on period taught them what the product needed to be.

Wealthfront

Before building an automated investment platform, the team individually consulted with each early client, understanding their needs and delivering advice personally. That direct service shaped what the automated product eventually had to do, so the software was built on real understanding rather than assumptions.

DoorDash

DoorDash began as a concierge-style test called Palo Alto Delivery. The founders put up a simple page listing local restaurant menus, then personally took the orders and delivered the food themselves. They were openly the operation, learning the real logistics of on-demand delivery (what people ordered, how timing worked, what went wrong) before building any driver app or dispatch software. The manual phase taught them the business they were actually in.

Stitch Fix

Stitch Fix's early styling was deeply hands-on: real stylists personally selected clothing for each customer based on their stated preferences, learning what drove satisfaction and what drove returns before heavy algorithmic automation. The human styling was not a stopgap. It was how the company learned what its eventual recommendation system needed to optimize for.

How concierge MVPs work for different product types

The concierge approach is often associated with consumer services, but it adapts to almost any product where value can be delivered by hand.

The constant across all of them is the same: you trade your time for the deepest possible understanding of what to build, and you only write code once the manual version has shown you the answer. The format flexes; the principle does not.

The AI case deserves a special note, because it is where the concierge MVP is most powerful right now. If you are building an AI product, being the AI yourself for the first few customers, producing the output by hand with your own judgment, teaches you exactly what "good" looks like. You learn the patterns a model would need to learn, the edge cases it would have to handle, and the quality bar users actually expect. Then you build the model to reproduce a standard you have already defined, instead of hoping it lands.

What to measure in a concierge MVP

Because the concierge MVP is qualitative, the metrics are different from a product launch. Track:

• Willingness to pay: do customers actually pay, and keep paying? This is the headline signal.
• Retention and repeat use: do they come back week after week, or was it a one-time novelty?
• Workflow clarity: are you converging on a repeatable set of steps, or does every customer need something wildly different? Convergence means a product is buildable.
• The "aha" moments: the specific points where customers light up. These are the features worth automating first.
• Referrals: do delighted customers tell others? Word of mouth from a hand-delivered service is a strong early signal.

You are not looking for statistical significance. You are looking for a clear, repeatable picture of what to build and proof that people will pay for it.

Pros and cons of the concierge MVP

Pros:

• The deepest qualitative insight of any MVP type. Direct, hands-on contact teaches you things no survey or analytics dashboard ever will.
• Revenue before product. You can earn money and validate willingness to pay before writing a line of code.
• A ready-made product spec. The service you deliver becomes the blueprint for what to build.
• Very low technical cost. No engineering required to start.

Cons:

• It does not scale, by design. Manual delivery caps how many customers you can serve. That is the point, but it means the concierge phase is temporary.
• It is labor-intensive. Your time is the product, and that time is finite.
• Small sample size. You learn deeply about a few people, which is powerful but not broad.
• Not every product fits. Some value genuinely cannot be delivered by hand.

Common mistakes founders make

1. Not charging. Giving the service away removes the single most important signal. Charge from day one, even a little.

2. Automating too early. Building software before the workflow is clear defeats the purpose. The whole point is to learn first, build second.

3. Serving too broad a market. Trying to please many segments at once muddies the insight. Stay narrow until the pattern is clear.

4. Treating it as customer support, not research. The goal is not only to make customers happy; it is to extract the product spec from each delivery. Document relentlessly.

5. Running it forever. The concierge MVP is a stage, not a business model. Once you know what to build, graduate. Lingering in manual delivery burns founder time that should go into the product. It is one of the MVP development challenges we see: staying manual past the point of learning.

Concierge MVPs in the age of AI

In 2026, AI changes how a concierge MVP runs, but not why you run one. The why, learning what to build by delivering it yourself, is unchanged. What changes is how much one founder can deliver by hand.

A modern concierge MVP is often a founder plus AI tools working behind the scenes. If you are testing that cold-email tool, you might use an AI assistant to draft faster while you apply the judgment, selection, and personalization that make the output good. You are still openly delivering the service by hand; you are just faster at it. This lets one founder run a richer concierge test than was possible a few years ago.

It also blurs the line with the Wizard of Oz approach, where a human plus AI quietly produces the result behind an automated-looking front end. The distinction still holds, transparency, but the practical setup can look similar. The deciding question remains whether the customer knows a person is involved. If they do, and you are learning from direct contact, it is still a concierge MVP, no matter how much AI helps you behind the desk.

The trap to avoid is letting AI tempt you into building the product too early. AI makes it cheap to generate a real-looking tool, which can pull you out of learning mode before you have understood the workflow. Stay in the concierge phase until the manual delivery, AI-assisted or not, has taught you what the product should be.

A concierge MVP checklist

Run through this to keep your concierge MVP on track.

Before you start:

• You have a narrow, reachable customer segment.
• You can describe the service you will deliver by hand, end to end.
• You have a small price to charge.
• You have a way to recruit the first five to ten customers personally.

While running it:

• Customers know the service is delivered manually.
• You are charging real money.
• You document each delivery into your spec template.
• You are converging on a repeatable workflow, not improvising wildly each time.

Before you graduate:

• You can name the one workflow worth automating.
• You have proof that people will pay for it.
• You have a written spec drawn from real delivery.

If every box is checked, you are ready to build, with a validated plan instead of a guess.

Why founders avoid the concierge MVP (and why they should not)

For a method this effective, the concierge MVP is surprisingly underused. The reasons founders skip it are understandable, and mostly wrong.

"It does not scale." True, and irrelevant. The concierge MVP is not meant to scale; it is meant to teach. Dismissing it because it does not scale is like refusing to sketch because a sketch is not a building.

"It feels unprofessional to do things by hand." Founders worry that manual delivery signals they are not a real company. The opposite is true: doing things that do not scale is one of the most respected early-stage moves, precisely because it produces learning that polished automation cannot.

"I would rather just build it." Building feels like progress, and manual service feels like a detour. But building the wrong thing is the most expensive detour of all. A few weeks of concierge delivery is the cheapest insurance against months of wasted engineering.

"My idea is too technical to fake." Sometimes true, but less often than founders think. Even technical products usually have a core workflow that can be delivered manually for a few customers, long enough to learn what matters.

"I do not have time to serve customers by hand." The honest reframe: you do not have time to build a product nobody wants either. The hours spent on a concierge MVP are not overhead, they are the research that makes every later hour of engineering count.

The founders who embrace the concierge MVP tend to be the ones who have been burned before, who shipped a polished product nobody wanted and learned the hard way that understanding beats building. The concierge MVP buys that understanding cheaply.

Signs your concierge MVP is working (and when to stop)

A concierge MVP is working when the signals point clearly in one direction. Watch for:

• Customers pay and renew. The strongest signal. If they keep paying for a manual service, the underlying value is real.
• The workflow stabilizes. Each delivery starts to look like the last. When you stop improvising and start following a repeatable process, you have found the thing to automate.
• Customers refer others. Unprompted word of mouth from a hand-delivered service is rare and meaningful.
• You can predict needs. When you anticipate what a customer wants before they ask, you understand the problem deeply enough to build for it.

And the clearest sign to stop: when you are spending your time delivering instead of learning. Once each delivery teaches you nothing new, the concierge MVP has done its job. Continuing past that point is no longer validation, it is underpaid labor that software should replace. Graduate, build the single-feature MVP, and put your time back into the product.

How to graduate from concierge to a built product

The concierge MVP ends when you can answer two questions with evidence: what is the repeatable workflow, and will people pay for it? When both are clear, it is time to build the automated version of the one workflow that proved valuable, your single-feature MVP.

This is the natural handoff. The concierge phase gave you a validated spec and paying customers; now you turn the most valuable, most repeatable part into software. You are not guessing at features; you are automating a proven service. That is the cheapest, lowest-risk way to build a real product, and it is exactly where a focused MVP build belongs. For where this sits in the bigger journey, see the MVP stage of a startup; for the budget, how much it costs to build an MVP.

How HorizonLux helps

A concierge MVP is the best tool there is for learning what to build, and we often tell founders to run one before we write any code. It costs almost nothing and produces a validated product spec that makes the eventual build faster, cheaper, and far more likely to work.

When the concierge phase has done its job, we build the automated version: most often a single-feature MVP, shipped funding-ready in under 4 weeks for a fixed $2,999, built by senior engineers around the one workflow your concierge run proved valuable. You get honest advice on whether you are ready to build, and the team to build it when you are.

Running a concierge test and wondering what to automate? Tell us what you have learned and we will help you turn it into a real product.

Frequently asked questions

What is a concierge MVP?

A concierge MVP is a validation method where the founder personally delivers, by hand and openly, the service that the product will eventually automate. The customer knows a human is doing the work. Its purpose is to learn exactly what to build by delivering the service manually first, before committing to engineering. It produces deep qualitative insight and validates willingness to pay.

What is an example of a concierge MVP?

The classic example is Food on the Table, whose founders personally interviewed each customer, hand-built a custom meal plan and grocery list matched to local store deals, and charged $9.95 a week, all before writing any software. They used the insights from manual delivery to design the eventual product. Airbnb and Wealthfront ran similar concierge-style validation early on.

What is the difference between a concierge MVP and a Wizard of Oz MVP?

Transparency. In a concierge MVP the customer knows the service is delivered manually and expects personal attention, so you are testing the back end (what to build). In a Wizard of Oz MVP the manual work is hidden and the user thinks the product is automated, so you are testing the front end (whether a known solution works). Concierge is for learning what to build; Wizard of Oz is for validating a known solution.

When should I use a concierge MVP?

Use it when your product is a service or workflow, you do not yet know exactly what to build, and deep qualitative learning matters more than volume. It is ideal when building the wrong thing would be expensive. Avoid it when your only risk is demand (use a landing page instead) or when the value genuinely cannot be delivered by hand.

Does a concierge MVP scale?

No, and that is by design. Manual delivery limits how many customers you can serve, which is fine because the concierge MVP is a temporary learning stage, not a business model. Once you understand the repeatable workflow and have proven willingness to pay, you automate the validated part and move to a real product, typically a single-feature MVP.

Should I charge money during a concierge MVP?

Yes. Charging real money, even a small amount, is the strongest validation signal you can get, far stronger than someone saying they would use your product. Willingness to pay separates genuine demand from polite interest, and it turns the experiment into a real test. Food on the Table charged from the very first hand-built plan.

How long should a concierge MVP last?

Only as long as it takes to answer two questions: what is the repeatable workflow, and will people pay for it? For most founders that is a few weeks to a couple of months of serving a narrow segment. Once both answers are clear, graduate and build the automated version. Running a concierge MVP indefinitely wastes founder time that should go into the product.

What comes after a concierge MVP?

You automate the validated workflow, usually by building a single-feature MVP around the one part of the service that proved most valuable and repeatable. The concierge phase hands you a real product specification and paying customers, so the build is grounded in evidence rather than guesses. From there the product can expand toward product-market fit.

Can I use AI to run a concierge MVP?

Yes. In 2026 many founders run a concierge MVP as a person plus AI tools working behind the scenes, using AI to deliver faster while applying their own judgment. It is still a concierge MVP as long as the customer knows a human is involved and you are learning from direct contact. Just avoid letting AI tempt you into building the real product before the manual delivery has taught you what to build.

How many customers do I need for a concierge MVP?

Usually five to ten engaged customers is enough. The concierge MVP is about qualitative depth, not statistical significance, so a small number of customers you serve personally and learn from deeply is far more valuable than a large anonymous sample. You are looking for a repeatable workflow and proof of willingness to pay, both of which emerge from a handful of real deliveries.

Is a concierge MVP the same as consulting?

They look similar but the intent differs. Consulting delivers a service for its own sake; a concierge MVP delivers the service to learn what product to build, documenting every delivery into a specification for future software. If you are not extracting a product spec and planning to automate the validated workflow, you are consulting, not running a concierge MVP.

How much does a concierge MVP cost?

Very little in money, a lot in time. Because there is no software to build, the main cost is your own hours delivering the service, plus any small tools or ads to find customers. That is the point: it lets you validate what to build for almost nothing before you spend real money on engineering. For the cost of the build that follows, see our guide on how much it costs to build an MVP.

Sources and references

This guide draws on established lean-validation frameworks and documented startup histories:

• LogRocket, Concierge vs Wizard of Oz MVP the manual-validation distinction
• Shortform, What's a Concierge MVP definition and how to build one
• Mind the Product, Wizard of Oz vs Concierge behind the curtain vs behind the desk
• Eric Ries, The Lean Startup the origin of the concierge MVP and the Food on the Table example

Startup examples (Food on the Table, Airbnb, Wealthfront) are widely documented; the four-week, $2,999 figure reflects HorizonLux delivery data for single-feature MVP builds.