How to Pre-Sell a SaaS Before You Build It (2026)

What it means to pre-sell a SaaS

Pre-selling means taking money, or a firm commitment to pay, for software you have not finished building. The buyer gets something specific later (access to the product, a year of it, a seat at a lower price), and you get two things now: proof that somebody will pay, and sometimes enough cash to build. The same steps work to pre-sell a product that is not software; refunds and shipping rules differ for physical goods.

A survey tells you what people say and a signup page tells you who is curious; a pre-sale tells you who will pay, which is what the softer tests try to predict (our roundup of idea validation tools covers those). It only counts if the buyer knows exactly what they are buying, including that it does not exist yet.

Presale vs waitlist vs letter of intent

They often run side by side, and answer different questions:

In practice you want a pre-launch waitlist and a presale at the same time: the presale for the few ready to commit today, the waitlist for everyone who says "not yet."

Sell before you build: what a pre-sale proves and what it does not

Founders who say "sell before you build" mean it literally, so be clear what a sale proves. It proves that specific people will pay a specific price for a specific promise. It does not prove they will use the product every week, renew or tell anyone: only the working product answers that, so treat a pre-sale as permission to build version one, not as product-market fit. And it fails for products people must touch before they trust them, where a weak result may say more about the format than the idea.

When pre-selling software makes sense, and when it does not

To pre-sell software before building it, you need buyers who can judge the outcome from a description and a mockup. That works best when:

• The problem is expensive and current. People already pay for a workaround: a contractor, a spreadsheet, a tool they dislike.
• Buyers are businesses. A company buying a $3,000 tool decides on a demo, a scope and a date, and may prefer to lock in a price.
• The scope is small and dated. A plugin, an integration, a reporting tool, an extension of a platform buyers already use.
• You can reach the buyers directly.

It works badly when the value is the feel of the product (consumer apps, games, design tools), when you cannot estimate the build, when the product only works at scale (a marketplace is worthless to its first buyer), or when health, finance or safety rules need more than a promise. Then a waitlist with a survey question is the better instrument, and a short paid beta once something works is the better pre-sale.

Real examples of software pre-sold before it was built

Ghost and Light Table: software funded on Kickstarter

In 2013 John O'Nolan put Ghost, an open-source blogging platform, on Kickstarter with a working prototype and a £25,000 goal; 5,236 backers pledged £196,362. The tiers named exactly what each backer got: £10 for a copy before anyone else, £25 for an early access copy plus three months free on a hosted service the team had not built yet. Delivery was estimated for August 2013, and Ghost launched privately to its backers about three weeks before its October 14, 2013 public release: about a month late, and delivered.

A year earlier, Chris Granger had a prototype of Light Table, a new kind of code editor, and wrote on its Kickstarter page that he could not build a full IDE alone. He asked for $200,000 to hire a team; 7,317 backers pledged $316,720, with licenses from $50 and Python support promised at $300,000.

The lesson: both made the funding goal the build budget and spelled out each reward. Light Table shows the risk too: every stretch goal is a new promise added to a date that was already a guess.

Bluetick: sales before code for a B2B email tool

Mike Taber, building Bluetick, an email follow-up tool, told Indie Hackers how he validated the idea with real customers and secured "thousands of dollars worth of sales before writing any code". No crowdfunding, no launch: a narrow problem he had himself, and conversations with people who had it too.

The lesson: a small B2B pre-sale does not need an audience. It needs a problem specific enough that the people who have it recognize themselves.

A $300,000 enterprise extension sold from an idea

Bryce Kaiser describes, in his newsletter Sell First Build Later, pre-selling an extension for an IT monitoring platform, for administrators of Cisco UCS servers. The build was estimated at about $30,000; the team gave itself three months to cover that in pre-orders or not build. Prospects applied, had a discovery interview and were asked, in effect, "If we build that, will you buy it?" The result: "$300k+ in preorders before writing a line of code."

The lesson: the threshold was set before selling started, which turned a hopeful pitch into a decision with a deadline.

Who to pre-sell to first

Your first buyers are the small group who feel the problem most and can pay without a committee. Look for people who:

1. Have the problem this month, not "sometimes."
2. Already spend on it: money, a contractor's hours or their own evenings.
3. Can say yes: a founder, a team lead with a budget, a solo professional.
4. Are reachable by you, directly.

This is the part of how to pre-sell a SaaS that most guides skip. Start with conversations, not a page: ten to twenty calls with people who match all four will give you the words they use for the problem, the price that makes them pause and the one feature they would pay for. That is the offer. Meanwhile a simple idea validation landing page gives everyone not ready to pay a place to land, and the channels that bring your first 100 waitlist signups bring your first buyers too.

Where to find your first ten buyers

You do not need an audience for ten buyers, you need a short list of names. Start with the people who already trust you or already have the problem in a place you can reach:

• Past clients and colleagues who have the problem, or know someone who does.
• Communities where you already answer questions, where a direct message reads as help, not a pitch.
• Users of the platform you extend: its forum, marketplace reviews and user groups.
• LinkedIn, searching by job title, with a short personal note.
• Your waitlist, starting with everyone who answered yes to a "would you pay" question.

Writing the offer: what exactly they buy

Vague offers ("early access to something great") get vague answers. A good offer answers five questions in plain words:

1. What they get. The specific outcome and the version-one feature list. Write what is out of scope, too.
2. When they get it. A date, or a month, that you believe with some margin. If the build takes eight weeks, sell twelve.
3. What it costs, and what happens after. The pre-sale price, whether it is a one-time payment or the first year of a subscription, and what the price becomes at renewal.
4. What happens if you miss the date. A full refund on request, and what you will tell them before the date passes.
5. What happens if you cancel. An automatic full refund within a stated number of days.

Add a cap ("the first 30 buyers") only if it is real, for example because you can only onboard so many people well. And do not sell a lifetime deal: it turns your most committed buyers into zero-revenue users and tells you nothing about recurring payment, which is the business you are testing.

Objections you will hear and how to answer them

• "It doesn't exist yet." Agree, then show what does: the mockup, the prototype, the date and the refund terms. You are selling a promise with a guarantee, so make the guarantee easy to see.
• "What if you disappear?" Point to the written refund policy, your real name and how to reach you, and the update you will send every two weeks. Offer a deposit instead of the full price if trust is the only thing missing.
• "I'll wait until it's live." That is a fair answer. Ask what would make them buy at launch, note it, and put them on your list.
• "Why pay now?" Because they get it first, at a lower price, and help shape version one. If none of that matters to them, they are a launch customer, not a pre-sale buyer.

Deposit, full price, annual prepay or a letter of intent

The commitment you ask for decides how much the result means. The more a buyer gives up, the fewer people say yes, and the more each yes tells you.

Here is what each option does for you, using one example throughout: a $6,000 out-of-pocket build for a tool planned at $39 a month, $468 a year.

All figures in the table are an example. Replace them with your own build cost and price.

Small deposits need many buyers and bring little cash; annual prepays and B2B contracts reach the build budget with a handful. For a solo founder selling to small businesses, an annual prepay at a pre-sale discount is usually the best fit. Choose a refundable deposit when the price is high, the date uncertain or the buyer needs approval to spend, and say how it is credited ("your $50 comes off your first invoice").

Letters of intent for B2B buyers

A letter of intent is a short document in which a company says it intends to buy, at roughly a stated price, if you deliver roughly a stated thing. In most commercial contexts LOIs are intended to be non-binding, Common Paper notes, often with a binding confidentiality clause, and investors give them less weight than a signed contract.

It is not always easier than an order: SK Murphy, a B2B consultant, writes that getting even a non-binding LOI signed "is often as onerous as pushing a real PO through." His alternative is a paid evaluation or pilot "where that payment is credited toward a full purchase." So before you send an LOI, offer a small credited pilot fee. A yes is revenue; a no tells you how serious the LOI would have been.

Pricing the pre-sale

Keep pricing to what the pre-sale needs:

• Anchor on the real price. Show it next to the pre-sale price ("$468 a year at launch, $290 if you buy now"). Pre-selling at a price you never intend to charge validates the wrong business.
• Make the discount a reward for risk, and say how long it lasts and what happens at renewal. In our example, $290 instead of $468 is about 38% off the first year.
• Do the revenue math once with the pre-launch MRR calculator, and see how long the cash lets you build with the startup runway calculator.

For a lasting discount for early buyers, our guide to running an early access program covers founding member pricing.

How many pre-sales to validate an idea

There is no universal number, so write your own before you sell; a threshold set after the results moves to fit them. Use two floors and take the higher:

1. The signal floor. Enough paying strangers to see a pattern, not a coincidence. For a first product, 10 strangers is a sensible floor; friends do not count.
2. The money floor. Your out-of-pocket build cost (contractors, design help, paid tools until launch) divided by your pre-sale price. Cover it and the build is funded even if nobody else buys.

Then set a window, usually two to six weeks of active selling. Noah Kagan's shortcut is stricter: validation is complete if within 48 hours you can get 3 paying customers. That is a good first test, not a reason to commit months of work.

A worked example

Illustrative numbers: you are building scheduling software for physiotherapy clinics. The build will cost $6,000 out of pocket (a contract developer for the calendar sync, plus tools). The plan is $39 a month after launch, and the pre-sale is a year upfront for $290.

Twenty-five is above 21, so you build. The 25% rates are assumptions, not benchmarks; the point is that you know before opening how many yeses you need, and the survey question tells you whether that is realistic. Decide in advance what each result means:

• At or above the threshold: build, and tell every buyer the date again.
• Between the signal floor and the threshold: the demand is real and the money is not there yet. Cut scope until the build cost fits, or extend the window once, by a fixed time.
• Below the signal floor: do not build this version. Refund anything conditional and ask the people who said no what was missing.

The pre-sale page checklist

The page repeats the deal in writing. It needs all of this, and nothing that pretends the product exists:

• A headline that names the outcome, in the buyer's words from your calls.
• A plain statement that it is not built yet: "We are building this now. Pre-order to get it first."
• What version one does, as a short list, and what it does not do yet.
• Mockups or a short demo of the prototype, labeled as such.
• The delivery date, or month, and how you will keep buyers updated.
• The price, the post-launch price and what renews, with the exact discount and how long it lasts.
• The cap, if there is one, and only if it is real.
• The refund policy in full, not just a link.
• Who you are: your name, a photo and how to reach you.
• One payment button that goes to your checkout.
• A second, lighter option for people not ready to pay: "Not ready? Join the list and we'll email you when it ships."
• No invented proof: no fake testimonials or made-up logos.

If you want a starting layout, the pre-order waitlist landing page template is built around one product, one date and one button.

Payment mechanics: how to get pre-orders before launch

There are four common ways to get pre-orders before launch, and they differ in when money actually moves.

The key fact: in Stripe's documentation, an authorization for an online card payment is usually valid for 7 days, so "we'll only charge you when it ships" is not possible with a simple hold. Stripe's guide to pre-order payments describes saving the payment method and charging at fulfillment (customers may have to authenticate again), and recommends partial payments upfront, a cap on orders, realistic delivery dates and enough cash on hand for refunds and disputes. That last one matters: Stripe does not return its processing fees on a refund, and refunds draw on your available Stripe balance, so treat pre-sale cash as refundable until you deliver.

Which tool to use:

• Stripe Payment Links for most pre-sales: a hosted checkout with no code for a one-time product or a subscription, with promotion codes, a limit on the number of purchases and refunds from the dashboard.
• Stripe Invoicing for B2B: per the same page, invoices go to a named customer, can be split into partial payments and can start as a quote.
• Lemon Squeezy if you sell to consumers in many countries: it acts as the merchant of record, so you don't have to worry about collecting and remitting sales tax.

Whichever you use, put the delivery date and the refund terms on the checkout page or in the receipt email, not only on your site.

What you may promise: refunds and consumer rules

Promise only what you would sign, put it in writing and refund without argument. The rules underneath depend on where you and your buyers are; this is general information, not legal advice.

United States. The FTC's Mail, Internet, or Telephone Order Merchandise Rule covers most goods ordered online. You need a reasonable basis for any shipping time you state, or for shipping within 30 days if you state none; if you will be late, buyers must be able to accept the delay or cancel for a prompt refund, and card refunds are due within seven working days. The FTC's guide says the rule does not cover services and does not address digital products, so a SaaS subscription is likely outside it. It is still a good model, and a pre-sale of anything physical is inside it. If the pre-sale becomes an auto-renewing subscription, show the renewal price and how to cancel before checkout; California has its own click-to-cancel rule for consumer subscriptions.

European Union. Consumers who buy online can usually cancel within 14 days without giving a reason; for a service, the 14 days run from the day the contract is agreed.

Business buyers. Consumer rules mostly do not protect companies, so B2B pre-sales run on contracts: put the scope, date, price and refund terms in the order form.

A pre-sale refund policy template

Copy this, fill in the brackets and have it checked for the countries you sell in. It is a starting point, not legal advice.

Pre-sale terms for [Product name]

What you are buying
[Product name] is not built yet. You are paying [price] for
[one year of access / a license / your first year at the pre-sale price],
starting when version one is delivered. Version one includes:
[feature 1], [feature 2], [feature 3].

Delivery
We plan to deliver by [date]. We will email you an update at least
every [two weeks] until then.

If we are late
If we cannot deliver by [date], we will email you before that date with
a new date and the reason. You can then choose a full refund or to wait.
We will only continue with your order if you reply that you want to wait.

If we cancel
If we decide not to build [Product name], we will refund every pre-sale
in full within [7] days and tell you why.

Refunds for any reason
You can ask for a full refund at any time before delivery, and within
[30] days after delivery, by emailing [email]. We send refunds within
[7] days. Your bank may take a few more days to show it.

After the first [year]
[Your subscription renews at [price] per [period] unless you cancel.
We will email you [14] days before it renews.]

Questions: [your name], [email]

How to pre-sell a SaaS in conversations: the email and the LOI

The page is where people pay; the conversation is where they decide to. Send this email first to the people who said yes to your survey question, a day before everyone else: plain text, from you, one link. For the rest of your list's emails, these waitlist email templates cover welcome and launch messages.

Subject: [Product name] pre-sale is open (first [30] only)

Hi [first name],

When you signed up, you said you'd pay [price] to get [Product name]
first. The pre-sale is open today, and you're hearing before the rest
of the list.

What you get: [one sentence outcome]. Version one does [feature 1],
[feature 2] and [feature 3]. It doesn't do [out-of-scope thing] yet.

When: I'm building it now and plan to deliver by [date]. You'll get an
update from me every two weeks.

Price: [pre-sale price] for your first year, instead of [launch price].
After that it's [renewal price] a year, and you can cancel any time.

If I'm late or cancel, you get your money back. Full terms are on the
page: [link]

Pre-order here: [link]

If it's not right for you yet, just reply and tell me what's missing.
That helps me as much as a yes.

[Your name]

The LOI is for a company that wants the product but cannot pay before it exists. Ask about a paid pilot first.

Letter of intent

[Company name] ("the Customer") intends to buy [Product name] from
[Your company] ("the Provider") once version one is delivered.

1. Scope: [requirement 1], [requirement 2], [requirement 3].
   Accepted when [for example "a 14-day trial with our own data"].
2. Expected delivery: [date].
3. Expected terms: [number] seats at [price] per year, first term
   [12] months from acceptance. [Optional: pilot fee of [amount],
   credited against the first invoice.]
4. Non-binding: this letter records intent only and obliges neither
   party to buy or sell, except that both keep each other's
   confidential information confidential.

Customer: [name, role, email]  Signed: ____________  Date: ______
Provider: [name, email]        Signed: ____________  Date: ______

When an LOI comes back signed, put the week you deliver in your calendar and turn it into an invoice then.

What to do with "maybe" and "not yet"

Most people will not pay before the product exists, and that is not the same as "no." Sort the answers:

• "Not for me." Ask what would make it for them, then let them go. Their answer is research.
• "Maybe, I need to see it." Your launch customers. Tag them "maybe" with the reason and offer the product again when you have a demo.
• "Not yet, ask me in [month]." Note the month and the reason (budget cycle, current contract) and contact them then.

A pre-sale with 21 buyers and 150 "maybes" has produced two assets, and the second is your launch list (keep it somewhere built for it, such as SaaS waitlist software). The guide on how to convert a waitlist into paying customers covers the emails that follow.

Delivering on time: updates, delays and refunds if you cancel

Once you have taken the money, your job is keeping a promise in public.

Send an update every two weeks, even with little to show: what you built, what is next, whether the date holds. A public build in public changelog does this for everyone and doubles as proof for people who have not bought.

Give buyers something early: a rough login, a call, a vote on the next feature. Letting them in early, in small groups, is what early access means in practice, and turns buyers into design partners.

If you will miss the date, say so before it passes.

Decide a week ahead, then email every buyer the new date and the honest reason, offer a full refund one reply away, and ask for a clear yes to wait (under the FTC rule for goods, silence counts only for a first short delay). Send refunds within days.

If you cancel, refund everyone automatically, then send a short email explaining why. Founders who cancel cleanly keep their reputation.

When you deliver, launch to everyone else. A SaaS launch checklist keeps launch week from eating the time you promised your first buyers.

Mistakes that sink a software pre-sale

• Counting friends. They pay to be kind; count only strangers.
• A date with no margin. An eight-week build sold as eight weeks will be late.
• Scope that grows with every call. Write version one down and sell the rest as "later."
• Spending the money before delivery.
• Going quiet after the sale. Silence is how a buyer turns into a dispute.

Running the interest side of a pre-sale with LaunchList

LaunchList does not take payments, process pre-orders or hold deposits: the money goes through your own checkout, such as Stripe or Lemon Squeezy. It is pre-launch waitlist software for founders, and it handles what surrounds the payment: the people not ready yet, finding the ones who are, and telling them when the pre-sale opens.

• A page for everyone who is not ready to pay. A hosted waitlist page written from one sentence and edited block by block, live at a launchlist.page address, or a form embedded on your own site.
• A survey question that finds your buyers. Signup forms can ask screening questions as dropdowns, single or multiple choice, or long text on every plan, so "Would you pay $290 now to get it first?" sits right in the waitlist signup form. A hidden field can record where each person came from (a link ending in ?source=reddit), also on every plan.
• Send the yeses to your checkout. After someone signs up, a form can show a message, their status page or a page of your own, so the people who just said yes can go straight to your Stripe Payment Link.
• Pick the likeliest buyers. Tags work on every plan, so you can mark people "paid," "maybe" or "ask in March." Building your own segments, for example everyone who answered "yes, now," is on the Launch plan and the Grow plan; waitlist segments shows how they work.
• Email the list when the pre-sale opens. From the Collect plan you can email your waitlist with a broadcast, first to the yeses and then to everyone, and send the updates every two weeks the same way. Details of each plan are on pricing.

The pre-sale proves people will pay. The list keeps everyone else close until the product is real, and it is the first place to look for launch customers.