Concierge MVP

For a long time the assumption was that you can't know until you build. An idea looked promising, engineers got assigned, six months went by, the thing shipped, and only then did anyone find out whether people wanted it. When the answer was no, the six months were simply gone — and so was any way of explaining the failure. Nothing was left to distinguish a wrong idea from an awkward interface from a launch nobody heard about.

Shrinking the build didn't fully solve it. Even a small version needs screens and a server behind them, which means weeks at minimum. Teams kept spending those weeks on things nobody had confirmed anyone wanted, and the cheapest version of the idea still arrived after the point where it could have been abandoned for free.

A concierge MVP inverts the order. Instead of building less, it builds nothing and has a person perform the service by hand. Pagedeck did exactly this. Mia was sketching a feature that would turn a team's accumulated documents into a one-page weekly summary, and rather than booking engineering time she contacted eight customer accounts and offered to write and send those summaries herself every Friday. She wrote them by hand for three weeks. At the end of those three weeks the team held an answer that six months of building would not have produced.

The loop is: decide what you're testing, serve a small group by hand, and record what happens. The recording is the part that matters most — drop it and the exercise stops being an experiment and becomes unpaid consulting.

1. Write down what you're testing, in one sentence. A hypothesis is a guess written so it can come out true or false, and there should be exactly one of them here. Pagedeck's read: teams drowning in documents will want to keep receiving a weekly summary.
2. Pick five to ten people. You're looking for early adopters — the people feeling the problem hard enough to accept something rough. Customers who have already complained about it are the best candidates.
3. Promise what you'll deliver and by when, and say plainly that a person is doing it. Not hiding it is a condition of the method. Hide it and you're running a Wizard of Oz MVP instead, which carries different obligations.
4. Do the work by hand, and log every round. Three things: what you had to ask, what you produced, and how many minutes it took. Mia's log showed an average of 40 minutes per weekly batch across eight accounts, and that number later decided what got automated.
5. Separate the repeated from the one-off. Anything that came out the same way for all eight accounts is a candidate for automation; the judgment calls that differed per customer stay with a person for a while longer.
6. Set the stopping rule in advance. Pagedeck decided that if more than half still wanted the summaries after four weeks, they'd build it, and otherwise they'd drop it. Decide this afterward and sunk time will keep the project alive on its own.

The method belongs at the stage where nobody knows whether there's demand at all. It costs close to nothing to run, so a wrong idea costs a few days. It fits best where the service leans on human judgment, because you discover what needs automating by doing the work rather than by imagining it in advance. It also fits business-to-business products with few, high-value customers, where the first ten accounts are a number one person can actually serve.

What it cannot do is just as clear.

1. It can't test scale. Past about twenty people the manual work collapses, and what happens beyond that is something this experiment never reveals. Pagedeck could serve eight accounts in one Friday afternoon; eighty would have needed a staffed team, which is a different question entirely. Scalability — whether a system can grow to absorb rising load — has to be checked another way.
2. It's hard to attribute the result. A person delivering a service naturally tailors it to the person in front of them, so a warm response might be the idea working or might be Mia being good at her job. This is why the log records what was actually delivered, with the parts only a human could have done marked separately.
3. Run it too long and the team gets stuck. Forty minutes a week across eight accounts crowds out everything else. Four to six weeks is the usual ceiling, and an answer that hasn't arrived by then usually means the question was wrong.

"Before we build it, let me just do it manually for ten accounts. Two weeks."

A proposal to confirm demand by hand rather than book engineering time.

"Four weeks of concierge and five of the eight want to keep getting it. I think we can build it now."

Reporting against a stopping rule that was set in advance.

"That's not a concierge MVP, that's just doing the work for them. What are you trying to learn?"

Calling out manual service being delivered with no hypothesis attached to it.

At Pagedeck the method surfaces in roadmap meetings. A feature candidate comes up, Grace asks how long it takes to build, and Theo says two months. Mia then offers to run three weeks of concierge before anyone commits the two months. Engineering works on something else during those weeks, and at the next meeting Mia opens the log: how many of the eight kept wanting it, what she had to ask each time, and how many minutes one round took.

The most common reading is that this is a stopgap for teams without time to build properly. Doing the work by hand certainly looks like improvisation. But the point isn't to deliver the service — it's to answer a question that was written down first. Without a hypothesis, a stopping rule, and a log, it isn't a concierge MVP; it's just manual labor. Left that way, a few months later the team is tired and all it has to show is a vague impression of eight accounts.

The second is reading a warm response as proof of a business. Customers paid and were happy, so it looks settled. But what this stage confirms is demand, not margin. If a job that takes 40 minutes was being sold at $25 a month, every new customer deepens the loss. Unit economics — what's left over on a single customer or transaction — has to be recalculated after automation, and if that math doesn't work, demand alone isn't a reason to continue.