Journal / Founder Decision Frameworks

Founder Decision Frameworks

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.

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 prepayment 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 prepayment 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 presale offer

The presale 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 prepay 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 presales

  1. Asking for money before demonstrating enough specificity about what will be built. Customers do not prepay for vague ideas. They prepay for specific solutions to specific problems on a credible timeline.
  2. Targeting people who have expressed curiosity rather than people who have the problem today. Interest and urgency are different. Urgency is what generates prepayments.
  3. Treating a failed presale 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.
  4. Building before getting any prepayments. The whole point is to validate before building. If you build first, you lose the feedback the presale conversation provides.
  5. Not delivering on the timeline promised. Late delivery on a presale is a broken promise. It damages trust before the product relationship has a chance to form.

Where to start: a presale validation plan in three steps

Step 1: Write the presale 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 prepayments. 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 Presale 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 presale 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.

FAQ

Frequently asked

  • Is it ethical to charge before a product exists?
  • How much should I charge before the product exists?
  • What do I do if no one pays?
  • How do I find early customers willing to prepay?
  • What should I promise in exchange for early payment?

Author

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 on the side. 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.

Start the conversation See the work DM on Instagram