Essay
The wallet test
Everyone loves your product right up until it’s time to open their wallet. In the interview, in the demo, in the group chat, people are generous. “This would change how we work.” “I’d definitely use this.” “Sign me up.” Then you send the actual invoice, or ask for a card, or name a price, and half of them go quiet.
That’s not a rejection. That’s information. It’s the most useful information you’ll get before you build anything.
Interest is nearly free to generate. Curiosity, politeness, and the desire to be encouraging will get you a room full of people who say yes to a survey. None of that tells you whether the thing you’re building solves a problem big enough that someone will trade money for it. Only a real transaction tells you that — and it doesn’t need to be a big one.
The Wallet Test: A validation method that requires a real financial commitment — not expressed interest, not a survey response, not a signed letter of intent — before committing serious development resources. A $1 deposit that someone actually pays is worth more than a hundred replies that say “sounds great.” The test answers one question: is this problem expensive enough, to this specific person, that they’ll trade real money to solve it today?
Why “sounds great” is the most dangerous phrase in product
“Sounds great” costs nothing to say. It’s the path of least resistance in a demo, in a customer discovery call, in a Slack DM from a potential user you’re excited to talk to. People say it because they’re polite, because they don’t want to discourage you, because evaluating a product carefully requires effort they haven’t budgeted.
The problem is that “sounds great” feels like signal. Teams treat survey responses, waitlist signups, and enthusiastic demo calls as evidence that they’re on the right track. They cite “strong early interest” in investor decks. They let that interest justify six months of engineering. Then they launch and discover that interest was never correlated with willingness to pay.
There are three specific ways this goes wrong.
False precision from the wrong group. The people willing to give you 30 minutes in a discovery call are not a random sample of your potential market. They’re the most generous, most curious, most available people in your network. They skew toward people who like new things, who enjoy talking to founders, who have a professional interest in seeing startups succeed. Their enthusiasm tells you almost nothing about whether the people who actually have the problem will pay to solve it.
The encouragement gap. In a live demo or interview, social pressure runs toward encouragement. It’s uncomfortable to tell a founder their idea doesn’t work, especially to their face, especially when they’re clearly excited. People manufacture reasons to be positive. The wallet is the only thing that doesn’t lie — it has no social obligation to be encouraging.
Problem severity is invisible until you price it. A problem can feel real and frustrating to someone without being expensive enough to solve with money. Lots of people have lots of problems. The question isn’t whether your product addresses a problem — it’s whether that problem is in the tier of problems someone will actually budget for. You don’t know the answer until you ask for payment.
What counts as a wallet test
The test doesn’t have to be a full purchase. It has to cost the customer something real. Options, in roughly increasing order of signal strength:
A waitlist with a card on file. Not a free email signup — a signup that requires payment information. Stripe makes this trivial. If someone won’t enter a card number to be first in line, they won’t buy when you launch. The card captures intent and gives you the ability to charge on release. Even if you don’t charge until then, you’ve filtered for real interest.
A pre-order or deposit. A partial payment toward a future product. The customer pays now, you deliver later. This is the clearest signal short of a live sale: they evaluated the offer against everything else they could spend that money on and chose this. Amounts don’t have to be large — a $50 deposit on a $500 product is a better signal than a thousand “interested” survey responses.
A scoped paid pilot. For B2B products: charge for a limited-scope version that delivers a specific result. Not a free trial, not a discount — full price for a smaller engagement. If they won’t pay for the pilot, they won’t sign a contract for the full product. The pilot also gives you real usage data from a real customer, which is worth more than any amount of discovery conversation.
A real invoice. In some contexts, the cleanest test is just sending one. You have an idea, you have a potential customer who expressed interest, you write up what you’d build and for how much, and you email it to them. Their response tells you more than six months of customer discovery calls.
What doesn’t count: a free sign-up, a LinkedIn like, a “keep me posted,” a signed letter of intent with no financial penalty for walking away, a verbal commitment in a meeting. These are all interest. None of them are payment.
TitanFlow: the beta as a wallet test
When we started TitanFlow in 2020, we had a thesis: retail traders wanted institutional-grade options flow data on mobile, and nothing in the market served them. We could have spent months building a full platform and found out at launch if that thesis was right.
Instead, we ran a wallet test before writing most of the code.
We seeded the beta through specific Discord servers and subreddits — communities of active retail traders who were already talking about options flow. The announcement wasn’t vague. It described the specific thing we were building: a mobile-first options flow app with a real-time feed, for people making decisions during market hours. We asked them to sign up for early access.
A thousand people signed up overnight. That was the first signal. Not survey responses, not “I’d use this” — people actively submitting their information to get access to a specific, described product.
Then we launched on the App Store. Fifty paying customers in the first week, with zero paid acquisition. That was the wallet test completed. They looked at the product, evaluated it against the price, and opened their wallet.
We built everything that came after — watchlists, push alerts, dark pool data, the Elite tier — on the foundation of that validation. We knew there was a real market, at a real price, before committing the full engineering effort. Three years later, TitanFlow was acquired.
If the beta had gotten no signups, or the launch week had gotten no paid conversions, we would have learned that before burning a year. That’s the point. The cost of a failed wallet test is an afternoon. The cost of building the wrong thing well is two quarters of engineering and a lot of runway.
CardSell: when the transaction IS the product
CardSell — a gift-card exchange platform — was a different kind of wallet test problem. The product itself was a financial transaction: users entered a gift card, received an offer, accepted it, and got paid via PayPal. The transaction was the entire user experience.
When I came in, 30 to 40 percent of transactions were fraudulent. That’s the wallet test failing in reverse: the platform was accepting commitments (offers, payouts) based on insufficient signal about whether the other party was real.
The standard response to fraud at that rate is to buy a better model or build a review queue. The real problem was diagnostic: the transaction flow was collecting the wrong signals at the wrong time. The offer was being made before the system knew enough to make it safely. The wallet test was running before the identity check.
The fix was rebuilding the offer pipeline so that every piece of signal — account state, card metadata, duplicate detection, third-party verification, user history — was collected before any commitment was made. Create offer → check quote → run fraud check → accept or reject → execute sale → update payout state. Each step in sequence, each step gated by the right signal.
The result: fraud dropped to near zero. Transaction volume grew 4x. Not because the product added new features — because it stopped making commitments before it had earned the right to make them.
The lesson generalizes: a wallet test isn’t just a marketing tactic before a launch. It’s the principle that you don’t extend commitment until you’ve collected the signal that justifies it. That applies to your first pre-order and to the hundredth transaction in a marketplace.
Harvestdate: the direct sale as validation
Harvestdate was a B2B cannabis CRM and supply-chain platform for Washington state operators — a market that didn’t have established software vendors when recreational cannabis became legal. We built a platform that translated BioTrack compliance data into sellable inventory, without adding a second job for the operator.
We didn’t validate Harvestdate through surveys of whether processors wanted software. We validated it by going and selling it directly. We talked to processors, understood exactly what wasn’t working in their compliance-to-commerce workflow, built the specific thing that removed that work, and asked for payment.
That direct sales loop was the wallet test running in real time. Every time a processor signed on, they were voting with their budget. We reached roughly 30 percent of Washington’s licensed processors before the acquisition in 2019. That penetration happened because we started from a real transaction — a direct sale, at a real price, to a real operator — not from building a platform and hoping distribution would follow.
Named to Marijuana Venture Magazine’s Top 40 Under 40 in 2017. The validation came from paying customers, not award nominations.
How to run a wallet test this week
You don’t need a finished product. You need a specific offer and a real ask.
- Write the invoice first. Before writing any code, write down exactly what you’d charge and for what. A product, a service, a scoped pilot. Make it concrete enough that someone could evaluate it against other things they spend money on.
- Send it to five people. Not your most supportive friends. People who actually have the problem. Send the invoice or the pre-order page. Ask for a decision, not feedback.
- Count yeses, not maybes. A “that sounds interesting, let’s talk more” is a maybe. A paid deposit is a yes. If you don’t get a yes from the first five, ask what changed when it was real money. That conversation is more valuable than a hundred discovery calls.
- Set a threshold before you build. Decide in advance: if X people pay Y, we build this. If not, we revise the offer or the market. Deciding after the results come in lets you rationalize any outcome as signal.
If you’re not sure what offer to test, or you’re getting interest but no payment and can’t figure out why, that’s a sequencing problem — and it’s the kind of thing the Sequencing Audit is built for. We find the smallest sellable version of what you’re building and test it before you commit the full build.
Related: The Chunking Theory — how to sequence the build once the wallet test passes. Distribution Before Development — how to find the right people to run the wallet test with.