The Decision to Charge Money Before You Have a Product
Charging money before a product exists is the most reliable form of market validation. Free signups signal interest. Paid commitments signal willingness to pay, which is the actual question early-stage founders need to answer. A founder who collects $500 from five potential customers before writing a line of code knows more about their market than a founder who gets 500 email signups.
Written by Yashveer Singh, founder of Yashveer Labs.
What you actually need to know
- Five customers who pay $500 before you build is worth more than five hundred who sign up for a free waitlist. Cash is the validation signal.
- The conversation that produces a payment is itself the validation. If the customer cannot articulate why they would pay, the problem statement needs revision.
- Be specific about what you are selling: early access to a specific product that will do a specific set of things by a specific date.
- If you cannot get anyone to pay after 20 serious conversations, the premise needs to change. Do not build.
- The pre-payment creates accountability: now you have customers who expect delivery.
| Validation Signal | What It Proves | Reliability |
|---|---|---|
| Email waitlist signup | Awareness and mild interest | Low |
| Free trial signup | Willingness to try | Medium |
| Payment with no product | Willingness to pay for the solution | High |
| Annual contract before product ships | Strong conviction in the value | Very high |
The core argument
Most founders validate ideas the wrong way. They talk to potential customers, who tell them the idea sounds interesting. They build a landing page, which gets 200 email signups. They feel confident they have validated the market. Then they spend six months building the product, launch it, and discover that the people who said it sounded interesting are not interested enough to pay.
The gap between "this sounds interesting" and "I will pay for this" is where most failed startups live. Customers are naturally polite. Telling a founder that their idea is bad is uncomfortable. Telling them it sounds interesting is easy and harmless. The email signup removes even that small friction. The only signal that removes the politeness filter is money.
Charging before you have a product forces the real conversation. The customer has to decide whether the problem is real enough, and the proposed solution plausible enough, that they will commit money. This is a different decision than clicking "join waitlist." It requires them to evaluate the proposal seriously. The conversations that lead to payment teach you more about the market than any amount of free signups.
The founders who do this well treat the pre-payment phase as a research phase, not just a sales phase. Each conversation is an interview. What are you using now to solve this problem? What does it cost you in time or money? What would you need to see in a product to be confident it is better? What would prevent you from switching? The answers to these questions shape the product. The payment confirms the market.
How to structure the pre-sale offer
The pre-sale offer needs to be specific enough to be credible and flexible enough to survive the product development process.
What you are selling: Early access to a specific product that will [solve this problem] by [this date]. The scope needs to be honest. Do not promise a full-featured product if you are building an MVP. Be explicit about what version one will and will not do.
What the early customer gets: Access to the product as it is built. Typically, that means a working version within 60 to 90 days. Input into the roadmap through regular calls. A discount from the price that will be charged after launch. Priority support.
What you are charging: A meaningful amount that requires a real decision. For B2B products, this is often one to three months of the planned subscription price paid upfront. For a $200 per month product, this is $200 to $600. It is not a lifetime deal or a steep discount. It is a commitment that represents real money to the buyer.
The refund policy: If the product does not launch within a specific window (say, 90 days past the promised date), the customer gets a refund. This protects the customer and creates accountability for you.
Finding early customers to approach
The customers most likely to pre-pay are the ones who have the problem right now and are suffering under an inadequate current solution. Not people who might have the problem someday.
The clearest signal: people who are manually doing something your software would automate. They are spending 10 hours per week in spreadsheets doing something your product would handle in 10 minutes. They know the problem intimately. They know what a solution is worth to them.
Find them in the places they gather: industry-specific Slack communities, LinkedIn groups, subreddits for the industry or profession, newsletters written for the specific audience. Direct outreach works better than broad advertising. Write a message that describes the specific problem precisely and asks whether it resonates. The people who respond enthusiastically are the ones to have conversations with.
The conversation goal is not to sell. It is to understand whether the problem description is accurate and whether the proposed solution would address it. Selling comes after you have confirmed the fit.
Common mistakes founders make with pre-sales
- Asking for money before demonstrating enough specificity about what will be built. Customers do not pre-pay for vague ideas. They pre-pay for specific solutions to specific problems on a credible timeline.
- Targeting people who have expressed curiosity rather than people who have the problem today. Interest and urgency are different. Urgency is what generates pre-payments.
- Treating a failed pre-sale as a negotiation problem rather than a validation signal. If a customer will not pay after a thorough conversation, the issue is the product, not the sales technique.
- Building before getting any pre-payments. The whole point is to validate before building. If you build first, you lose the feedback the pre-sale conversation provides.
- Not delivering on the timeline promised. Late delivery on a pre-sale is a broken promise. It damages trust before the product relationship has a chance to form.
Where to start: a 3-step pre-sale validation plan
Step 1: Write the pre-sale offer document. One page: the problem you are solving, the specific solution version one will provide, the timeline, what early customers get, and the price. This document forces you to make commitments explicit before you have had a single conversation.
Step 2: Identify 20 potential customers with the problem right now. Not people who might have the problem someday. People who are currently dealing with the inadequacy that your product will solve. Find them through communities, LinkedIn, or warm introductions. Approach with specificity about the problem, not a pitch.
Step 3: Have 20 conversations with the goal of 5 pre-payments. If you get 5, you have market validation and your first customers. If you get 2, you have weak validation and a signal to revisit the offer. If you get 0, the premise needs to change before you build anything.
Why Pre-Sales Thinking Applies to How I Work
Yashveer Singh. Founder of Yashveer Labs. The systems I build are for customers who have real problems, not for demonstrations of technical ability. The pre-sale mindset, building only what customers will pay for, shapes how I approach every project. If you are at the stage where you need to figure out whether your product has a market, that is a conversation I have had with enough founders to be useful in.
Related reading
Frequently asked
The engineer behind this page
This was written by Yashveer Singh. Full stack developer, founder of Yashveer Labs, currently in Class 12 in New Delhi, shipping production systems while most of my peers are still writing their first console app. I am pointing the work, on purpose, at machine learning, AI engineering, and cybersecurity. If you are reading this because you want to hire someone who will not waste your time or your money, that is the role I am built for.
Posts that line up with this one.
- Founder Decision Frameworks
The Decision to Change Pricing
How to reprice a SaaS product without losing existing customers, alienating prospects, or leaving revenue on the table.
- Founder Decision Frameworks
The Decision to Remove a Free Plan
When removing a free plan is the right call, how to handle the migration for existing free users, and what to expect on the other side.
- Founder Decision Frameworks
The Decision to Add a Free Plan
When a free plan accelerates growth and when it cannibalizes revenue, and how to tell the difference before you ship it.
- Founder Decision Frameworks
Should You Build a Marketplace, a SaaS, or a Service Business?
Three business models, three very different bets. Here is how to pick the one that matches your actual situation.