[KongchangAI]
· 1 min read· 879 words

Would You Pay?: Validate Who Will Actually Pay Before You Build

Would You Pay?: Validate Who Will Actually Pay Before You Build

Would you pay? uses a Tinder-style swipe mechanic to validate real payment intent before you build anything.

The most common failure mode for side projects is discovering nobody will pay only after you've already built the product. Would you pay? addresses this by letting real users swipe to express payment intent, returning data on the percentage willing to pay, audience profiles, and interest depth. It's a lightweight implementation of Lean Startup smoke testing that moves validation before product development, helping indie developers filter out dead-end directions at minimal cost. The product is free. However, swiping "I'd pay" is intent, not actual payment — the intention-behavior gap means this data should inform direction, not serve as final business validation.

Most Side Projects Die in Silence

For indie developers and entrepreneurs, the most painful lesson usually isn't that the product wasn't good enough — it's that nobody was willing to pay for it in the first place. You spend months heads-down building, launch with high hopes, and get back nothing but silence: no paying customers, no feedback, not even a rejection. This kind of "quiet failure" is remarkably common among side projects.

A product on Product Hunt called Would you pay? targets exactly this pain point. Its core proposition is simple and direct: before you invest more time building, figure out whether anyone is actually willing to pay.

Would you pay? product page

Validating Real Purchase Intent Through Swiping

Would you pay? borrows its interaction model from social apps: your startup idea or product is shown to real users, who only swipe right if they would genuinely pay for it. The cleverness here is that it transforms a vague "I'm interested" into an action that more closely mirrors an actual buying decision.

The problem with many validation tools is that users will say "looks good" or "there's definitely a need for this" — but that kind of polite feedback often misleads founders. Purchase intent is a harder signal. There's a real gap between being willing to pay and finding something interesting.

The product surfaces three key data points:

  • Percentage of users willing to pay: directly quantifies market payment intent
  • Who those users are: helps you understand your target audience profile
  • Who clicked to learn more: measures depth of further interest

Why "Validate Before You Build" Deserves Serious Attention

This approach is essentially a lightweight implementation of Lean Startup thinking. A traditional MVP still requires you to build something functional first, whereas Would you pay? tries to move validation even earlier — to the stage before any product exists — filtering out ideas that nobody will buy at a fraction of the cost.

For indie developers working with severely limited time and energy, the value of this kind of upfront validation is self-evident. Rather than spending three months building something nobody wants, spend three days confirming whether the direction is worth pursuing at all. The product is currently free, which lowers the barrier to trying it even further.

In terms of Product Hunt performance, the product has received 78 upvotes, 7 comments, and ranked 14th, categorized under Marketing, SaaS, and Startup Lessons. The numbers aren't viral, but the need it addresses is real and enduring.


The Lean Startup methodology, introduced by Eric Ries in 2011, centers on the Build-Measure-Learn loop: release a testable version at minimal cost, use real data to guide the next iteration, rather than betting all your resources on assumptions. The MVP (Minimum Viable Product) is the most well-known tool from this framework — it asks founders to strip away every "nice-to-have" feature and keep only the minimum set needed to validate the core hypothesis. But even an MVP requires significant development effort. Would you pay? represents a more extreme "Smoke Test" philosophy: before any code is written, test market reaction with a fake or simplified product page, eliminating directional errors at near-zero cost. This practice has a long history in early Silicon Valley startup circles — Dropbox's original demo video is a classic example. They collected tens of thousands of waitlist signups with a single video, confirming market demand existed before the product was actually finished.


A Moment of Sober Reflection

It's worth scrutinizing: "swiping to indicate willingness to pay" is ultimately an expression of intent, not a real financial transaction. Users clicking "I'd pay" without actually opening their wallets may still represent a meaningful degree of overestimation. This kind of data is therefore better treated as a directional reference rather than the basis for final business decisions.

Real payment validation typically requires getting to the stage of pre-sales, collecting deposits, or securing first orders. But as an early, ultra-low-cost filter, Would you pay? can help you avoid obvious dead ends before you commit significant resources — and that alone is genuinely valuable.

For entrepreneurs incubating a side project or new product, it at least provides a starting point for asking the right question: before you start building, ask yourself — will anyone actually pay for this?


Behavioral economics describes a phenomenon called the Intention-Behavior Gap: there is consistently a significant gap between what people say they intend to do and what they actually do. In product validation contexts, this bias is especially pronounced. Survey and intent-based tools typically overestimate real demand due to factors including the social desirability effect (not wanting to discourage someone), present-moment emotional bias (overestimating your future self's willingness to buy when you're currently excited), and context distortion (judgments made without price pressure are unreliable). This is precisely why startup methodology circles consistently emphasize that making users incur a cost is a more reliable signal — even just entering credit card information, paying a symbolic $1 deposit, or joining a waitlist that requires commitment filters out false demand far better than swiping or checking a box. Would you pay?'s data should be interpreted in this context: it's a low-cost early-stage filter, not a substitute for real transactions as a definitive validation method.

#Would you pay#startup validation#payment intent#Lean Startup#smoke test#MVP#Product Hunt#indie developer#side project#pre-launch validation
Share:

Related articles