Lesson 4 of 6

The Concierge MVP

Before you automate anything, deliver the value by hand to a few people. If they will not take it free, they will not pay.

8 min read

The fastest way to find out if people want your product is to deliver the result by hand, to a few real people, before you build anything. This is the concierge MVP: you become the software. It feels like cheating and it feels like it does not scale, and both of those are exactly the point. You are not trying to scale yet. You are trying to learn whether the value is real, and you can learn that in a week instead of a quarter.

Be the software before you build the software

A concierge MVP delivers the outcome your product promises, manually, with you doing the work behind the curtain. If the idea is an app that builds people a personalized workout plan, you do not build the app. You take three people, ask them the questions the app would ask, and write their plans yourself in a document. They get the real value. You find out, fast, whether the value is something they actually want and use.

This works because customers do not care how the value is produced, they care that they get it. A human doing it by hand produces the same outcome as software, minus three months of building. And because you are in the loop personally, you see every reaction, every place they get confused, every feature they ask for and every one they ignore. That texture is worth more at this stage than any amount of clean code.

If they will not take it free, they will never pay

The concierge MVP gives you a brutal, useful filter. If you offer to solve the problem by hand, for free, and the person still will not show up, give you their information, or use what you make them, the problem is not painful enough to build a business on. You just learned that for the price of a few hours instead of a few months. People make time for things that genuinely help them. Indifference to a free fix is the loudest no there is.

The flip side is the good signal: people who lean in, who do the homework you ask for, who come back and ask for more, who try to pay you before you have a way to charge. When your hand-delivered, unscalable, slightly embarrassing version creates that pull, you have found something real. Now building the product is justified, because you are automating a value people have already shown they want.

Pick three to five real users, not friends doing you a favor.
Deliver the core outcome by hand. Do the unglamorous work yourself.
Do not automate anything yet. The manual mess is where you learn.
Watch for pull: do they come back, ask for more, try to pay?

Keep the curtain closed with a Wizard of Oz

A close cousin is the Wizard of Oz MVP, where there is a real-looking product on the front, but a human is pulling the levers behind it. The customer sees what looks like a finished app. You are manually doing in the background what the app appears to do automatically. This is useful when the experience itself, the interface and the flow, is part of what you need to test, not just the raw outcome.

Both approaches share one rule: spend nothing building what you can fake. Fake the back, make the front real, and protect the one thing you are actually testing. The goal is never to deceive the customer about the value they receive, it is to avoid building the expensive machine until you know the machine is worth building.

Worked example

Zappos faked the warehouse, not the demand

When Nick Swinmurn wanted to test whether people would buy shoes online in 1999, the obvious plan was to raise money, sign deals with brands, and build warehousing. Instead he went to local shoe stores, photographed their stock, and put the photos online. When an order came in, he bought the shoes at full retail and shipped them himself, often losing money on the sale.

He was not trying to make a profit. He was buying the answer to one question: will people buy shoes online without trying them on. Every order was a real person spending real money, the strongest validation there is. The warehouse, the inventory, the logistics, all the expensive parts, came later, once the demand was proven. The company eventually sold to Amazon, built on a first MVP that was mostly one founder and a camera.

Learn by doing

Paste these into ChatGPT or Claude and run them against your own idea. The model will answer happily. Olune goes further and checks the answer against real Reddit threads, competitor maps, and keyword volume.

Tip: grab the downloadable playbook to run every play with fill-in worksheets →

Prompt 1 · Design a concierge MVP for your idea.

I want to validate this idea without building software: [describe the idea and the outcome it delivers]. Act as a lean-startup coach. Design a concierge MVP where I deliver that outcome by hand to my first three to five users. Tell me exactly what I do manually, what I can fake, what I must not automate yet, and the single signal that would prove they actually want it.

What a good output looks like

For a meal-planning idea: recruit five busy parents, collect their preferences in a form, write each plan and shopping list yourself in a shared doc, deliver it Sunday night. Do not build an app. The signal that matters: do they use the plan and ask for next week, unprompted.

Prompt 2 · Find the cheapest thing you can fake.

Here is the product I eventually want to build: [describe it, including the automated parts]. For each major feature, tell me whether I could fake it with manual work or a no-code tool for the first ten customers, and how. Then tell me the one part I should not fake because it is the actual thing I need to test.

What a good output looks like

It suggests faking the matching algorithm with a human, the dashboard with a spreadsheet, the notifications with you sending emails by hand, then flags the one core experience, say the quality of the match, that you must keep real because that is the bet.

Key terms in this lesson

Takeaways

Deliver the value by hand to a few real people before you build. You become the software.
Customers care about the outcome, not how it is made. A human produces the same value minus the build time.
If people will not take your free, hand-made fix, they will never pay for the automated one.
Spend nothing building what you can fake. Protect only the one thing you are actually testing.

Now run your own idea through it.

You have the method. Olune does the legwork: an honest build-or-kill verdict on live Reddit signals, competitor maps, and keyword volume, in about eight minutes. Free to start.

Test your idea →

Common questions

Does a manual MVP just prove people like free work, not that they will pay?

It proves the value is real, which is the first thing that has to be true. Pair it with a willingness-to-pay test: at some point, ask the engaged users to pre-pay or commit, even at a small price. Concierge proves they want it. A pre-sale proves they will pay. You usually want both, in that order.

How is a concierge MVP different from just consulting?

The intent. A consultant delivers the work and moves on. With a concierge MVP you are watching for the patterns you will automate: the same steps you repeat for every user, the questions everyone asks, the parts that obviously should be software. You are doing it by hand specifically to learn what to build.

When do I stop doing it manually and actually build?

When the manual work is clearly working and clearly painful to keep doing by hand, and you have the same outcome repeating across several users. That repetition is your spec. Build the part you are tired of doing manually, for the users who already want it, and keep faking everything else.