Concierge test or partial build? How founders can prove the workflow before they commit to software
A practical guide for founders who want to test a risky workflow or value proposition with the smallest useful experiment. It explains when to simulate the service manually, when to build a thin product slice, and when a fuller release is justified.
On this page
Why this mattersTwo testsHow to chooseTrade-offsSafeguardsWhen to buildNext stepsIn short
- Test the riskiest assumption first, not the fullest feature list.
- Use manual delivery when the main question is whether people want the outcome.
- Use a partial build when the workflow is real but some steps still need human help.
- Do not hide manual work so well that you learn the wrong lesson.
- Choose a fuller release only when the value proposition is already credible.
If the biggest uncertainty is not the technology but the workflow, the promise, or whether people will actually use the thing, the best first step is often not a full build. Product research treats an MVP as an experiment: the smallest version that can tell you whether the idea creates meaningful value. Recent guidance also suggests matching the test to the risk. High-risk ideas should usually start with a prototype-style test, while lower-risk ideas can move more quickly into live code.
That is where concierge and Wizard-of-Oz tests are useful. They let you learn before you automate everything. The trick is choosing the lightest version that still gives honest evidence.
Why the lightest useful test usually wins
A founder can waste time and money by building the wrong thing beautifully. If the real question is whether the workflow works, whether customers trust the outcome, or whether the value proposition is strong enough to matter, a full product can be too much too soon. NNG’s 2026 guidance frames MVPs as learning tools, not polished mini-products, and says the point is to evaluate whether users will get meaningful value.
That is why manual experiments still matter. A concierge test is useful when you want to see whether people care about the result, even if humans are doing some of the work behind the scenes. A Wizard-of-Oz test is useful when the front end should look real, but the back end is still manual or semi-manual.
Concierge and Wizard-of-Oz are not the same thing
Concierge test
A human delivers part or all of the service manually. The user may know that people are involved, or the manual nature may be obvious. This is good when you want to learn whether the outcome is valuable and whether the process can be sustained.
Wizard-of-Oz test
The product looks automated to the user, but people are handling some of the work behind the curtain. This is useful when the interface or perceived automation is part of the question, but you are not ready to build the full system.
The practical difference is about what you are trying to learn. If you need to know whether people will pay for a result, a concierge test may be enough. If you need to know whether the experience feels like software and the workflow is acceptable when hidden automation is missing, a Wizard-of-Oz test is closer to the real thing.
Choose based on the riskiest assumption
- 1
If the value proposition is the real uncertainty, start manual
When you are unsure whether people want the outcome at all, keep the process simple and human. The goal is to learn whether anyone cares enough to engage, wait, pay, or come back.
- 2
If the workflow is the uncertainty, simulate the experience
When the business promise depends on a specific flow, the interface matters. A Wizard-of-Oz approach helps you see whether people can move through the journey as expected before you build the full backend.
- 3
If the process is already proven, build a thin slice
Once the value proposition is believable and the steps are understood, a partial build can replace the most repetitive manual work. This is often the point where live code becomes more informative than extra simulation.
- 4
If the product is mature enough to measure properly, release more fully
A fuller release makes sense when the first question has been answered and you now need real analytics, reliability data and system behaviour under normal use.
The danger is choosing the test that feels easiest instead of the one that reduces the biggest risk. A manual experiment can be cheap and fast, but it can also overstate demand if the founder is doing a lot of invisible work. A partial build can create a sense of progress while still hiding the problem that matters most.
What manual tests do well, and where they mislead
What they do well
They reduce build cost, shorten feedback loops and expose whether the workflow is understandable in the real world. They are also useful when a team is blocked on engineering or still deciding what to automate first.
Where they mislead
They can hide operational pain, distort response times and make a process look easier than it will be at scale. If the manual version depends on unusual founder attention, it may not survive contact with normal usage.
NNG also notes an important safeguard: an MVP still needs adequate usability. If the interface is too awkward, you may end up testing the interface itself rather than the underlying idea. That is true for manual experiments too. If users cannot understand the flow, their reaction may tell you more about confusion than demand.
How to keep the test honest
0 of 6 complete
These safeguards matter because a good discovery exercise should lead to a decision, not just activity. If you are trying to learn whether the workflow is worth automating, you need to know not only whether people liked it, but also what it cost in time, attention and exceptions. Otherwise you may scale an idea that only works when it is being carefully babysat.
When a partial build or fuller release is the better move
A partial build is the better choice when the workflow is already credible and the next bottleneck is repeatability. At that point, software can remove the most expensive manual steps while preserving the logic you have already tested. This is often where founders start to care about reliability, handover and operational ownership as much as the user experience.
A fuller release is justified when you need real usage data, not just directional feedback. NNG points out that live-code MVPs become more useful once the value proposition is validated, because they let teams observe real behaviour and system performance.
| Situation | Best first test | Why |
|---|---|---|
| You are unsure anyone wants the outcome | Concierge test | Fastest way to learn if the promise matters |
| You are unsure the workflow feels right | Wizard-of-Oz test | Lets you test the experience before building the engine |
| You know the workflow works but it is repetitive | Partial build | Automates the painful parts without overbuilding |
| You need reliable usage data and stable operations | Fuller release | Shows real behaviour, volume and performance in production |
A practical way to decide this week
- 1
Name the riskiest assumption
Is it demand, workflow, trust, timing, pricing or operational effort?
- 2
Choose the lightest test that answers that assumption
Use a concierge or Wizard-of-Oz test if the main question is still behavioural or experiential.
- 3
Define one signal of success and one signal of concern
Keep the decision criteria simple enough that the team can act on them without debate.
- 4
Set a limit on manual effort
If the experiment is swallowing too much time, it may be telling you that the eventual product will be operationally heavy.
- 5
Decide the next move before you launch
Plan whether you will stop, iterate, partially build or move to a fuller release if the evidence is clear.
For founders, the value of this approach is that it keeps the first release honest. You are not trying to impress people with software; you are trying to learn whether the business is worth building in the first place. If you need help turning a risky idea into a scoped MVP, a structured discovery step can help you choose the lightest test and avoid building more than the evidence supports.
About the author
Nixim Team, Product Engineering
Practical guidance from Nixim on building software, working with AI and running dependable cloud systems.