Pre-Selling Your SaaS: How to Collect Real Revenue Before Writing a Line of Code

If you want to know how to pre-sell a SaaS product, the answer is simpler — and more uncomfortable — than most founders expect. Pre-selling a SaaS product means collecting real payment from customers for software that does not yet exist — using a Stripe link, a written spec, and direct outreach — before committing to any code. You charge money first. Not a waitlist. Not a “sign up to be notified.” Actual dollars transferred from a stranger’s bank account into yours, against a product that does not yet exist. That exchange is the only validation that actually counts.

I’ve run and advised on multiple SaaS pre-sells, and I’ve watched dozens of technical founders spend three to six months building an MVP nobody buys. The tragedy is always the same: the idea tested well in conversations. Friends said it was great. A few Twitter polls went positive. What was missing was financial commitment — the one signal that is genuinely hard to fake. This post is a field-tested playbook for running a full pre-sell in 7–14 days, collecting $495–$1,495 in real revenue from 5 paying beta customers at $99–$299 each, before your codebase has more than a README.

Why a Waitlist Is Not Validation (And What Is)

Waitlists feel good. They produce a number — “1,200 signups!” — that looks like traction. They are not traction. CB Insights has tracked startup failure across thousands of post-mortems and consistently identifies “no market need” as the leading cause of startup failure, accounting for roughly 42% of cases. Most of those founders had positive signals before they built. They had waitlists. They had verbal yeses on sales calls. What they didn’t have was a customer who had surrendered cash with no working product in exchange.

The psychology is simple: saying yes costs nothing. Pulling out a credit card costs something real — attention, friction, the mild cognitive discomfort of spending money on something unproven. When someone clears that friction, you have learned something irreplaceable. When they don’t, you’ve learned that too, and the lesson cost you zero engineering hours.

Pre-selling is also different from crowdfunding. Crowdfunding works on social proof and momentum; it rewards the founder with an audience. Pre-selling works on direct outreach and a specific value proposition; it rewards the founder with customer conversations. That distinction matters enormously for a solo technical founder who doesn’t have 50,000 Twitter followers.

If you’ve ever had a product idea tank quietly after launch, you’ll recognize the pattern that most first products fail because founders skip this validation step entirely. Pre-selling closes that gap mechanically.

The 7-Day Pre-Sell Sprint: Exact Sequence

Here is the precise sequence I use and recommend. It requires no developer tools and runs on three pieces of infrastructure: a Stripe payment link, a Notion spec document, and a cold outreach system. Total setup time: under four hours. Total sprint: 7 days minimum, 14 days if your target market requires a longer buying cycle (enterprise-adjacent B2B is the exception where 14 days is more realistic).

Day 1–2: Build the Offer Document (Notion Spec)

Before you touch Stripe, write the spec. Not a landing page — a working document that answers five questions with specificity:

1. What exact pain does this solve? Name the workflow, the spreadsheet, the manual step. Specificity is credibility.
2. Who experiences it? Job title, company size, tech stack, the moment in their day when this pain surfaces.
3. What does the product do? Three to five functional statements. Not “saves time” — “replaces the weekly CSV export from Salesforce that your ops team manually reformats every Monday.”
4. What does beta access include? Access window, support channel (direct Slack with the founder is a powerful beta perk), and the explicit refund guarantee.
5. When does it ship? Give a real date. If you can’t name a ship date, you’re not ready to charge.

This document is your pitch asset. You will share it on every outreach. It does not need to be pretty — Notion’s default styling is enough. What it needs is precision. Vague specs do not convert to paid betas.

Day 2–3: Create the Stripe Payment Link

Go to Stripe Payment Links (no code required) and create a one-time payment product. Configuration decisions that matter:

• Price point: $99 (lowest friction), $149 (middle), or $299 (signals budget seriousness). I recommend $149 for most B2B SaaS ideas targeting SMBs. If your target customer has a $5,000+ annual software budget, $299 is defensible.
• Product description: Include “Beta Access — ships [date]” directly in the Stripe product name. The customer sees this at checkout. Transparency here reduces post-purchase anxiety.
• Receipt: Customize the confirmation email in Stripe to include your Notion spec link and a direct email address. The first touchpoint after payment should feel personal, not automated.
• Refund policy statement: Add a line to the product description: “Full refund if the product isn’t released by [ship date + 30 days].” This is the friction-reducer that converts hesitant buyers. Stripe’s refund tools make honoring this simple.

Day 3–7: Cold Outreach at Volume and Precision

The outreach sequence is where most founders underinvest. They send 10 emails, get 2 responses, and conclude the idea is invalid. The floor for a meaningful signal is 75–100 outreach contacts. Here is the exact framework:

List building (Day 3): Use LinkedIn to search your specific ICP (Ideal Customer Profile) by job title, company size, and industry. Apollo.io has a free tier that can surface 50 verified email addresses per month. Build your 100-person list before writing a single email.

Email structure (Days 4–6): Keep it under 150 words. Subject line: name their pain in five words or fewer. Body: one sentence on who you are, one sentence on the problem you observed in their specific context, one sentence on what you’re building, one ask. The ask is not “would you be interested” — it’s “would you be willing to spend 15 minutes on a call this week?” Do not include the Stripe link in the first email. The first email is for booking a call.

The call (Days 5–7): Run a 20-minute Loom-backed demo using your Notion spec and any Figma mockups. The goal of the call is not to close — it’s to confirm fit and extend the offer. At the end, if there’s a clear problem match: “We’re offering 10 beta spots at $149. I can send you the payment link right now if you want to lock it in.” That is a closing ask. Do not skip it.

Benchmarks: What Good Looks Like at Each Stage

Note: “strangers” means no prior relationship — not co-workers, not friends. Payments from your personal network are warm-signal data, not cold-signal validation.

What to Do With the Money (and the Customers)

Once you’ve collected payment, you have three obligations that function as the core of your early GTM motion:

1. Start weekly check-ins. Every beta customer gets a 20-minute weekly call or a structured async update in a shared Slack channel. This is not customer service — it’s product discovery under financial contract. These conversations are where your feature priorities come from. Ignore them and you’ll build the wrong product even with paying customers in the room.

2. Scope down ruthlessly. Your Notion spec likely has 12 features. Your beta customers are paying for one core outcome. Find it in the first two check-in calls and build that one thing first. Ship something they can click in 30–45 days. In pre-sells I’ve run and advised on, a working v0.1 that solves one problem well consistently converts beta customers into long-term subscribers — because they were in the room when the product was shaped and they trust the builder. A 90-day build that tries to do everything ships late and arrives to indifference.

3. Honor your refund commitment explicitly. Send every paying customer a reminder at Day 30 and Day 60 of their beta. Tell them where you are, what’s shipping next, and restate the refund guarantee. This is trust-building in practice, not theory. Based on founder interviews published by Failory, founders who maintained proactive communication with beta customers consistently saw higher conversion rates to paid annual plans at launch.

The validation exercise isn’t just about proving demand. It’s about building customer relationships that are immune to the feedback distortions that come from friends and professional networks. Paying strangers will tell you the truth. People who want to be kind to you will not.

Common Pre-Sell Mistakes That Kill the Signal

After running and advising on multiple pre-sells, these are the four patterns I see most reliably destroy the signal:

• Selling to warm contacts only. If your five paying customers are former colleagues or friends, you have social proof, not market validation. Include it in the story, but don’t build on it.
• Pricing too low to attract serious buyers. $9/month for a B2B tool attracts people who want free stuff. It filters out buyers who actually budget for software. Price at least at $99 one-time or $49/month to get the right signal.
• Confusing “interested” with “committed.” A prospect who says “send me the link and I’ll sign up” and then never does is a no. Count only completed payments.
• Stopping at 40 contacts because you got 2 paying customers. Two is not five. Keep the outreach running until you hit the benchmark or exhaust the realistic ICP pool. If you exhaust 200 contacts with fewer than 3 payments, the data is the data.

This connects directly to why most indie hacker side projects fail — they validate with the wrong signals and build for the wrong people. Pre-selling with real payment links forces you to confront the right signal before the build begins.

The 14-Day Variation for B2B SaaS Targeting Larger Teams

If your ICP is a department head at a 50–500 person company rather than a solo operator or SMB owner, extend the sprint to 14 days and adjust the sequence:

• Day 1–3: Build spec document + mockups (Figma, not just Notion text)
• Day 3–5: Targeted LinkedIn outreach to 50 specific contacts (quality over volume at this buyer level)
• Day 5–10: Discovery calls — expect longer sales cycles; two calls before the payment ask is normal at this buyer level
• Day 10–14: Follow-up sequence for warm contacts who haven’t committed
• Target: 3–5 paying customers at $299–$499 (higher price reflects real enterprise software budgets)

At this buyer level, a PO (purchase order) or a signed letter of intent can substitute for an immediate Stripe charge — but only if it comes with a specific dollar amount and a committed start date. “We’ll definitely buy when it’s built” is a verbal yes. It does not count.

Frequently Asked Questions

How many paying customers do you need before building a SaaS product?

The minimum validated benchmark is 5 paying strangers (no prior relationship) at $99–$299 each, totaling at least $745 in collected revenue. Fewer than 3 payments from 100+ outreach contacts is a signal to pivot the problem framing, not continue building. The “strangers” qualifier is load-bearing: payments from friends or former colleagues are warm-signal data. They tell you people like you, not that a market exists.

Is it legal to charge money for software that doesn’t exist yet?

Yes — pre-selling is a standard commercial practice used by everything from software companies to hardware startups to book authors. The key legal requirement is transparency: customers must know they are paying for a product not yet built, understand the expected delivery timeline, and have access to a clear refund policy. Standard Stripe Terms of Service permit this for pre-orders. If you are selling to US businesses, ensure your terms clearly state the nature of the pre-order and your refund policy. This is general information, not legal advice — consult a licensed attorney if you have jurisdiction-specific questions about your pre-sell structure.

What if I hit 5 paying customers but the product takes longer to build than promised?

Communicate early, often, and proactively. Ship a working partial version before the promised date rather than a complete version late. Every beta customer should hear from you at least weekly. If the timeline slips significantly, offer refunds proactively — don’t wait for customers to request them. Founders who honor the refund guarantee voluntarily almost always retain the customer anyway; the act of offering a refund is itself trust-building. Customers who paid $149 and were treated well are worth far more than that number suggests in referral value and eventual revenue.

Should I use a lifetime deal to make the pre-sell easier?

Use a lifetime deal only if you are confident the product will survive the economics. LTD pricing attracts deal-hunters who may not be your long-term ICP. For validation purposes, an annual subscription or a one-time beta access fee generates a cleaner signal because it more closely mirrors how your eventual pricing will work. If your go-to-market plan is subscription SaaS, validate with subscription-like pricing. Use LTD pricing only as a deliberate launch strategy — not as a shortcut to hit your validation number.

How to Pre-Sell a SaaS Product: The One-Week Checklist

1. Write the 5-question Notion spec (2–3 hours)
2. Create a Stripe Payment Link with explicit beta language and refund terms (30 minutes)
3. Build your 100-person cold outreach list via LinkedIn + Apollo (3–4 hours)
4. Send first outreach batch — 30–40 contacts — with a 15-minute call ask (Day 3)
5. Send second outreach batch — 40–60 contacts (Day 4–5)
6. Run discovery calls; close with payment link for confirmed fits (Days 4–7)
7. Follow up once on non-replies (Day 6–7)
8. Count only completed Stripe payments toward your 5-customer target
9. If you hit 5: start building. If you don’t: analyze which calls came closest and what objection blocked payment

The hardest part of this sequence is not the cold email. It’s the closing ask on the call — the moment where you say “would you like to pay now?” Most technical founders delay or soften this ask. Don’t. If your value proposition works, the ask is a courtesy. If it doesn’t, you need to know that in week one, not month six.

Conclusion: Collect Revenue Before You Write Code

Learning how to pre-sell a SaaS product is really learning how to reorder the founder’s natural sequence. Most technical founders want to build something great and then find customers. Pre-selling requires you to find customers first — and to ask them for money before the thing exists. That inversion is uncomfortable. It is also the most reliable path to building something the market actually wants.

Five paying beta customers at $99–$299 is not a vanity metric. It is hard evidence that your ICP has a problem, understands your proposed solution, and trusts you enough to pay before it exists. That evidence is worth more than any amount of positive feedback, waitlist signups, or positive first calls.

Run the 7-day sprint. Count only completed payments. Build only when you hit five. The market will respect the discipline even when it’s uncomfortable — and so will you, six months later, when your paid beta customers have become your founding cohort and your MRR is climbing instead of starting from zero.

Disclaimer: This post is for general informational purposes only. Nothing here constitutes legal, financial, tax, or investment advice. Pre-selling involves real commercial commitments — consult appropriate professionals for advice specific to your situation and jurisdiction.