This is the play for when there is no production system yet and someone wants to learn whether an idea is worth building. The goal is not to ship a finished product; it is to learn, cheaply and honestly, whether real users want what is being proposed, and to leave the sponsor with a usable decision either way.

When to use this play#

Run this play only when every one of these is true. If any is missing, the engagement will drift, so treat the gate as pass or fail.

• There is a real, written user-problem hypothesis, not a hunch in someone's head.
• There is an identifiable user who is not the founder.
• There is a sponsor who will show up at least weekly.
• There is budget that funds both discovery and a build, not just one.

Walk away from anything that fails the gate. The clearest warning signs are: the founder is the only person who would use the product; the request is "build me [famous app]" with no problem definition; or a demand to start coding before discovery has produced a decision.

How to run it#

1. Run paid, separately-scoped discovery first. Before any build, spend one to two weeks on discovery that is scoped and paid on its own. The deliverable is a short decision document that has value even if the sponsor walks away afterward. It contains:

• The problem and who actually has it.
• The one job the user hires the product to do.
• A single MVP success metric.
• The smallest feature set that completes that job.
• An architecture sketch and a stack recommendation.
• The top five risks.

2. Make the first build iteration a spike, not a sprint of tickets. The first iteration is an architecture spike plus a UX prototype on the critical path. You are proving the riskiest path works and that the experience makes sense, not burning down a feature backlog.

3. Work in two-week iterations with working software every time. Every iteration produces something that runs. At the end of each one, demo it to the sponsor. The demo is the feedback loop, not a status meeting. If the only thing happening at the demo is a progress report, the loop is broken.

4. Default to boring and instrument from day one. Use a proven, unremarkable stack so the novelty lives in the product, not the infrastructure. Wire up metrics from the first iteration and document operations as you go, so the question "is this getting better or worse" always has an answer.

5. Triage features against the MVP, not against enthusiasm. Scope creep is the default failure mode here. The default answer to "can we add" is "yes, in v2," and there is a visible v2 backlog where those ideas go to live, not die. When a mid-build feature request lands, ask three questions in order:

1. Does the MVP fail without it?
2. Is it a one-day change?
3. Will the sponsor accept the timeline shift it causes?

If all three are no, it is v2. Put it on the backlog and move on.

Common traps#

• Letting scope creep in through the side door. Every "small" addition is small in isolation and fatal in aggregate. The visible v2 backlog is what keeps the conversation honest.
• Skipping discovery to start coding. This is almost always a request to be told the idea is good rather than to learn whether it is.
• Treating demos as status updates. If the sponsor is not reacting to working software, you are not learning anything.
• Over-engineering the stack. A clever architecture on an unproven idea is wasted effort and a maintenance burden you may never need.
• Building for the founder. If the founder is the only user, you are building a tool, not a product, and the play does not apply.

Signals it's working#

• Each demo changes something about the next iteration.
• The sponsor is making "v2" decisions calmly because the backlog is visible.
• The single MVP metric is moving, or you are learning specifically why it is not.
• Real users, not the founder, are touching the product.

How it ends#

This play ends. That is the point. Plan the transition deliberately rather than letting the engagement default into open-ended staff-augmentation. The honest exits are:

• Graduate to scale-up once there is evidenced usage and the question becomes "does it work at load."
• Take it in-house with a real knowledge transfer so the team can run it.
• Move to a retainer for steady, lighter-touch support.
• Wind it down if discovery and the build together showed the idea does not earn a place in the world.

Any of these is a success if it is chosen on purpose. The only failure at the end is drift.