Why we build MVPs with real payments, not fake "coming soon" buttons

A fairly common piece of lean startup advice circulating online is to test demand with a fake "buy now" button that simply shows a "coming soon, thanks for your interest" message when someone actually clicks it. It's genuinely cheap to build, and it does measure something real: raw click interest. What it doesn't measure is the thing that actually determines whether a business survives long-term, which is whether real people will actually hand over a real credit card number for it.

We've watched founders get genuinely excited about a healthy 4 percent click-through rate on a fake buy button, then go on to build a full, expensive product around that early signal, only to discover months later that actual willingness to pay real money was a small fraction of what that initial click rate had implied. A real, even genuinely minimal, checkout flow filters out the merely curious clickers from the people who actually, seriously intend to buy the product.

Stripe's own hosted checkout page can realistically be integrated in a matter of days, not months, and it handles the significant compliance and security burden that used to make "just build real payments already" sound genuinely intimidating to a small team without payments experience. For most MVPs today, there's very little remaining excuse to fake this particular signal, when the genuinely real version is this achievable in practice.

A fake button rarely tests any specific price point seriously or rigorously, since there's genuinely no real consequence attached to clicking it either way. A real checkout flow at a real, specific price gives you actual, honest conversion data at that exact price point, which is far more genuinely useful for deciding whether your intended pricing model is actually viable than any survey question could ever reliably tell you.

This hesitation is common and understandable, especially for a first-time founder. We usually suggest starting with a meaningfully discounted founding-member price rather than skipping payment entirely, which lowers the psychological barrier to asking while still generating the real signal that a free or fake option never can.

A discounted real price still tests genuine intent. It just tests it at a friendlier number, which tends to feel like a reasonable middle ground to founders who aren't yet comfortable charging full price for something still this early in its life.

Some MVPs genuinely can't take a real payment before the core product is built, a marketplace with no supply side yet, a service that requires manual fulfillment nobody's set up. In these specific cases we still avoid the fake button, and instead ask for a real, refundable deposit tied to an actual delivery commitment with a specific date attached, rather than an open-ended "we'll notify you when it's ready" promise with no real stakes on either side.

A refundable deposit still carries genuine financial commitment, which filters for real intent the same way a full payment does, while giving the founder honest room to build before fully delivering. The key difference from a fake button is that money genuinely changes hands, and a broken promise has a real, tangible cost attached to it rather than none at all.

Once real money is involved, even a small amount, the entire tenor of early user feedback shifts noticeably. Paying users report bugs with real urgency because they have genuine skin in the game, and they tend to give considerably more specific, more useful feedback than someone who clicked a free interest button and has nothing at stake. We've noticed feature requests from paying early users are consistently sharper and more actionable than the vaguer wishlist items that tend to come from a free waitlist.

This shift in feedback quality alone is often worth more to a founder during the earliest weeks than the revenue itself, since it's the difference between guessing what to build next and actually knowing, from people who've already proven they'll pay for it.

One founder came to us confident their product needed a free trial period before any payment could reasonably be asked for, based on how competitors in their space structured their own onboarding. We suggested testing a real, small upfront payment instead, even just a modest deposit, purely as an experiment alongside their planned free trial funnel.

The paid option converted at a lower raw rate than the free trial, exactly as expected, and the users who did pay upfront had a dramatically higher activation and long-term retention rate than the free trial cohort. The founder ultimately moved to a paid-first model across the whole product, specifically because the real payment signal turned out to identify meaningfully better-fit customers than the free option ever had.

For products with a genuinely hard supply constraint, a service that requires hiring and training real staff before it can serve its first paying customer, a physical product with a real manufacturing lead time, an upfront waitlist genuinely does make more sense than asking for payment against something that literally can't be delivered yet on any reasonable timeline. Even here, though, we recommend a real, non-refundable deposit over a purely free waitlist wherever the business model can reasonably support it.

The underlying principle stays the same regardless of the specific mechanism: whatever signal you're collecting before the product exists should carry genuine, real stakes for the person giving it, because a stakes-free signal reliably tells you less than founders hope it will once real building decisions actually depend on it.