“Ship an MVP” often mashed two different jobs into one phrase:

Helping someone understand and try, and getting paid for something you can deliver reliably, are different goals.

The first needs interest and a path.
The second needs a deliverable that matches the price.

Feature lists almost never match. Mix the same “minimum” and you get pretty demos that never convert—or half-built beasts shipped in the name of billing.

One decision only:

Is this release for “someone gets it / uses it,” or “someone pays”?

1. Choose the goal, then cut

	Demo-minimum	Paid-minimum
Goal	Interest, comprehension, path completion	Willingness to pay; reliable delivery
Success looks like	A stranger finishes the core action; or a page/demo yields qualified intent	Someone pays list-ish price; delivery doesn’t need nightly heroics
Primary metrics	Activation / completion / intent quality	Payment / delivery cost / refunds or rework
Usually includes	One path, barely-ok UI, observable behavior	Clear scope, payment/contract, fulfillment (can be manual)
Usually excludes	Full billing, roles matrix, edge cases	“Everything on the roadmap someday”
Main risk	Mistaking interest for WTP	Overbuilding to charge—or promising what you can’t ship

Rules of thumb:

• Don’t know if anyone cares → demo (or lighter landing/demo) first
• People already ask price, or you must test the model → paid first
• Value only lands after use → demo must include one felt win, not a poster

Don’t charge against demo standards—and don’t require paid-grade completeness for the first interest test.
First demand test: you don’t need roles, billing, or a full admin.
First charge: you don’t need full automation, but delivery must be explicit.

2. Demo-minimum: a path, not a shrunk product

Demo answers:

Can the target user hit one “oh—that’s it” on the shortest path?

Keep only:

1. One persona
2. One job
3. One success state (export, generate, send, see a result…)
4. A way to see completion (even a spreadsheet)

Ugly, slow, human-backed backends are fine.

The MVP backend can be fake; the result the user gets cannot.

For example:

• AI tool: real input/output in the UI; you call the model by hand behind the scenes.
• Content/report service: real checkout on the page; you assemble delivery manually.

Broken core path, fuzzy success, or “we’re not sure what we’re demoing” are not fine.

If the unknown is messaging/audience, you may not need a clickable app yet—landing page, explainer, sales demo can be the demo.
If the unknown is whether use works, build the smallest clickable path.

Classic miss: a “smaller full product”—every module a little, no complete win. When it fails, you can’t tell weak demand from a failed demonstration.

3. Paid-minimum: deliverable must match price

Paid answers:

When buyers pay, what do they think they bought—and can you deliver next week?

So paid-minimum is often clearer boundaries, not more features:

Must decide	Examples
Deliverable	Boilerplate zip, one report, 30-day account, one week done-for-you
Out of scope	No custom work, no infinite revisions, no “lifetime every feature”
Fulfillment	Auto-delivery / calendar booking / Friday handoff
Price shape	Buyout, per use, short sub—aligned with pricing shape

A common failure mode isn’t “nobody would buy”—it’s selling the future version: buyers pay for expectation; founders take on unlimited delivery.
That’s the same family of mistake as “buyout + vague lifetime updates = long debt” in the pricing-shape guide: wrong boundaries pollute WTP signals.

ShipFast-style boilerplates matter less as “the template itself,” more as packaging a messy build process into a delivery with clear edges.
A paid MVP can be concierge/manual—code can wait; the promise and the charge cannot be mush.

If payment only works via endless exceptions, you didn’t validate WTP—you prepaid a reputation debt.

4. Moving from demo to paid

Order by unknown:

1. Interest unknown → demo or landing; watch completion and intent quality
2. WTP unknown → ask money from people who already won once: prepay, paid trial, list checkout
3. Delivery unknown → take few orders with written scope; automate after you can fulfill

Classic skip-ahead failures:

• Billing systems before the path works;
• Enterprise features before anyone finishes the core job;
• Free forever actives who never saw a real price;
• Charging against demo standards, or requiring paid-grade completeness for the first interest test.

One-line transition test:

Among people who completed the demo path, does non-friend payment appear?

When this applies

Best for tools, templates, light SaaS, info products.
Weaker for strong network-effect products (solo demos don’t prove cold start) or compliance walls that block any touch without full capability.
Paid may be manual; it may not be “spoken price vs delivered reality” forever.

30-second: demo or paid this version?

① Testing interest—or willingness to pay?
② Can value be felt in one path—and is the result real?
③ If charging, can delivery fit in five sentences?

• Interest unknown → demo (or lighter)
• WTP unknown and path already works → paid (manual OK)
• Can’t write five delivery sentences → not ready to charge—narrow the promise

Related

• ShipFast: why selling a boilerplate worked
• Subscription, buyout, or usage
• Nobody’s paying yet: push or call demand too weak