The Concierge MVP: Validate by Doing It Manually First
A concierge MVP is when you deliver your product’s promised result by hand, one customer at a time, before you build any software, so you find out whether people actually want the outcome without spending weeks coding. You act like the software you haven’t built yet. The customer gets a real result. You get real proof that demand exists, plus a front-row seat to every messy step you’d otherwise guess at.
The name comes from a hotel concierge: someone who takes your request and personally makes it happen. That is exactly what you do. Someone wants the thing your future app promises, and you go do it for them, manually, today.
What is a concierge MVP, really?
Think about what your product is supposed to produce. Not the interface, not the login screen, not the dashboard. The actual outcome the customer is paying for.
Say you want to build an app that makes personalized study schedules for AP students. The outcome is a good study schedule. A concierge MVP means you skip the app entirely and just make the schedule yourself. You talk to a student, look at their classes and test dates, and hand them a schedule in a Google Doc. If it helps them, you have proof the outcome is valuable. If they ignore it, no amount of slick app design would have saved you.
The whole point is to separate two questions that beginners jam together:
- Does anyone want this result?
- Can I build software that delivers it?
Question two only matters if the answer to question one is yes. The concierge MVP answers question one for almost no money, which is the only kind of money most high schoolers have. If you are still fuzzy on what an MVP even is, start with this plain-English definition of an MVP and then come back here.
How is this different from a fake MVP?
People mix up three things, so let me draw clean lines between them.
| Approach | What the customer sees | What is actually happening | What it tests |
|---|---|---|---|
| Fake door test | A “Buy” or “Sign up” button | Nothing is built behind it | Will people click and commit? |
| Wizard of Oz MVP | A working-looking app | You do the work behind the scenes, secretly, by hand | Does the experience work? |
| Concierge MVP | A person openly helping them | You do the work by hand, out in the open | Do people want the result at all? |
The difference between a concierge MVP and a Wizard of Oz MVP is honesty about the machine. In Wizard of Oz, the customer thinks it is software. In a concierge MVP, they know a human is doing it, and that is fine. You are not lying; you are running a tiny service business on purpose so you can learn.
If you want the automation-focused cousin of this idea, my teammate wrote a good piece on the manual MVP where you fake the product before you build it. If you specifically want the click-a-button demand test, read the fake door test explained. This post is about the third row: doing the real work, in the open, to prove the outcome is wanted.
Why do this instead of just building the app?
Because building teaches you almost nothing until it is too late. When you spend a semester coding, you learn whether you can code. You do not learn whether the thing is worth building. Those are different lessons, and only one of them keeps you from wasting three months.
Doing it by hand gives you things an app never could at this stage:
- You feel every step. You find out the schedule takes 40 minutes to make, not 5. That is a business fact you needed before, not after, you automated it.
- You hear the real objections. “Can you make it around my swim practice?” is a feature request you would have missed sitting alone in your room.
- You get paid proof. If someone Venmos you $8 for a hand-made study schedule, that is worth more than 500 people saying “cool idea.” Compliments are cheap; money is honest. If your friends have been telling you they love it, read why “my friends love it” is not validation before you trust that feeling.
It is also the cheapest possible test. Your only costs are your time and maybe a free tool or two. There is no server bill, no domain, no “I’ll learn to code first.” You can literally start this afternoon.
How to run a concierge MVP in one week
Here is a step-by-step version you can actually do between school and dinner. Give it a week.
- Write down the exact outcome you promise. One sentence. “A student gets a week-by-week AP study plan built around their real schedule.” If you cannot say it in one sentence, you do not understand your product yet.
- Find 3 to 5 people who have the problem right now. Not “people in general” — people currently stressed about AP exams. Classmates, a group chat, a subreddit, a Discord. Not sure where to look? Here is where to find people to interview.
- Offer to do it for them, by hand, for a small fee. Charge something, even $5. Free customers lie because it costs them nothing to say yes. A price filters for people who actually care.
- Deliver it manually and time yourself. Make the study plan in a Google Doc. Note how long it took, what confused you, and what they asked for that you did not expect.
- Watch what they do next. Do they use it? Come back? Tell a friend? Ask for another one? Usage is the signal. A polite thank-you is not.
- Write down what you learned every single time. After each customer, spend five minutes writing what surprised you. This log becomes your product spec later.
Notice that “build the app” is not on this list. That is the point. You are buying information about demand for the price of a few afternoons, not a semester.
What counts as a real pass or fail?
Before you start, write down what a win looks like, or you will move the goalposts to protect your feelings. Everyone does it, including me.
A pass is a costly action repeated. Someone paid you. Then they came back and paid again, or referred a friend, or begged you for the next one before you offered. That pull — where the customer wants it more than you have to sell it — is what validation actually feels like.
A fail is when you have to chase every single sale, people ghost after getting the free result, or the honest answer to “would you pay again?” is a shrug. That is not a marketing problem you can fix later. It means the outcome is not valuable enough yet. Better to know now.
Be honest about which one you are seeing. The concierge MVP is only useful if you let it tell you no. For a fuller framework on reading these early signals, how to validate a startup idea with no money and how to test a business idea before you build it both go deeper.
When to stop doing it by hand
You automate when, and only when, two things are true: people keep paying, and the manual work is eating you alive. If demand is real and you are drowning in Google Docs at midnight, now code is the right answer, because you are automating a proven, painful task instead of guessing.
If demand never showed up, do not build the app to “give it a fair shot.” That is sunk-cost talking. Change the idea or change the customer, and run the concierge test again on the new version. You will have lost a week, not a semester.
This do-it-by-hand-first mindset is the backbone of the Validate sprint in the batch0 program, where you test your idea with real people before you write a single line of code. If you would rather run this with a cohort, deadlines, and mentors pushing you, applying is free and you only pay if you get in.
Start with a spreadsheet and one customer. If they pay you twice, you are onto something. If they do not, you just saved yourself three months.