How Zapier Sold Beta Access Before Its Product Was Ready
Short answer: Sell a paid beta before the product is finished when you can deliver one valuable outcome safely, state the limitations clearly and support each buyer personally. Find prospects already describing the problem, ask them to pay a modest but real price, and use the first 10 sales to compare urgency, delivery effort and repeat use. Do not charge for a promise you cannot fulfil or call unpaid interest customer validation.
A free beta tests whether people will try something. A paid beta tests whether the problem matters enough to exchange money, but only if the buyer understands what is incomplete and still receives the agreed value.
Zapier's founders launched their integration service as a nights-and-weekends project. Zapier's own account says it sold the first beta invitation to Andrew Warner for $100 on 30 November 2011 and sold about a dozen more within a week. The founders found people discussing specific integration problems in public forums, contacted them and helped them through a rough product. Zapier describes the first sale here, and its first-year review records the early sales, pricing tests and product changes.
The public story does not disclose a complete prospect funnel or early support cost. A useful teardown should preserve those gaps instead of converting a memorable first sale into a universal formula.
Use the Paid Beta Prospect Loop
The Paid Beta Prospect Loop turns each early sale into evidence through five linked steps.
| Step | Founder action | Evidence captured | |---|---|---| | Problem trace | Find a recent, specific complaint or workaround | Urgency in the prospect's own words | | Narrow offer | Promise one defined outcome | Whether the buyer understands the value | | Real payment | Charge under clear beta terms | Willingness to commit | | Close delivery | Onboard and support directly | Actual labour, failures and use | | Next prospect | Refine who and what to approach | Repeatability beyond one buyer |
My position is that an early software or service beta should usually charge from the first external customer. Free access produces more users, but more noise as well. The exception is when payment would create disproportionate regulation, procurement or implementation friction before the core behaviour can be observed. Even then, require a meaningful action and set a date for a paid test.
Find problem traces, not generic audiences
Look for people already attempting the job: asking in a specialist forum, comparing workarounds, hiring manual help or complaining about a failed process. A problem trace is stronger than a profile such as "small-business owner" because it includes a recent event.
Write down the exact task, current workaround, consequence and applications or people involved. Contact the prospect personally and refer to the trace. Do not scrape private groups, ignore community rules or send automated messages at scale. The early objective is ten relevant conversations, not a large list.
Use [a list of your first 50 prospects](/sales-and-marketing/build-a-list-of-your-first-50-prospects/) to structure outreach, but prioritise evidence of current pain over demographic similarity.
Sell the outcome and disclose the beta
State what works now, what does not, the support arrangement, price, cancellation or refund terms, data handling and expected changes. A beta label does not remove consumer, privacy, security or contractual duties.
The paid outcome must be narrower than the future vision. Zapier's early appeal was not every possible automation. It was getting a particular pair of services to pass information without the customer building the integration.
Offer one price for a defined period or task. You may test different prices across prospects, but keep written records and do not create false scarcity or misleading comparisons. Early pricing tests should reveal whether buyers value the result, not how much confusion they will tolerate.
Software handling customer data, payments, health information or regulated decisions requires controls appropriate to the risk. Requirements vary by country and sector. Obtain qualified legal, security and compliance advice before admitting data you cannot protect.
Count founder support as delivery cost
Paid betas often look profitable because founder time is recorded as learning rather than cost. Track minutes spent selling, configuring, fixing, explaining and monitoring each account.
Use:
beta contribution = price minus payment fees, variable infrastructure, third-party charges, refunds and founder delivery time
Value founder time at the rate required to hire a competent replacement. Negative contribution can be acceptable for a deliberately limited learning phase, but name the subsidy and cap it.
If customer ten still needs the same three hours as customer one, you have a bespoke service, not yet a scalable product. That can still be a good business, but price and describe it accordingly.
Worked example: LinkBridge Software
LinkBridge connects a small agency's website enquiries with its project system. It sells a four-week beta for £120. Payment cost is £3.60 and third-party infrastructure costs £6 per account.
The first customer requires 3.5 founder hours. At £30 an hour, delivery time costs £105. Contribution is £120 - £3.60 - £6 - £105 = £5.40.
After improving onboarding, customer ten requires 70 minutes, or 1.17 hours. Founder time costs 1.17 x £30 = £35.10. Contribution becomes £120 - £3.60 - £6 - £35.10 = £75.30.
| Beta measure | Customer 1 | Customer 10 | |---|---:|---:| | Price | £120 | £120 | | Founder time | 3.5 hours | 1.17 hours | | Total variable cost | £114.60 | £44.70 | | Contribution | £5.40 | £75.30 |
Across ten customers, assume average founder time is two hours. Total revenue is 10 x £120 = £1,200. Founder time is 20 x £30 = £600, while payment and infrastructure cost 10 x £9.60 = £96. Beta contribution is £1,200 - £600 - £96 = £504 before overhead and tax.
LinkBridge has evidence that delivery is becoming repeatable. It should not infer retention from a four-week beta. It should offer a clearly priced continuation and measure how many customers renew. These figures are illustrative, not SaaS benchmarks.
Use each sale to tighten the next one
After delivery, ask what event caused the search, why the workaround was insufficient, what almost prevented purchase and what result justified the price. Compare answers across buyers.
Do not build every request. Mark whether a request is essential to the promised outcome, repeated by the target segment and likely to reduce delivery cost or increase willingness to pay. A feature that serves one prestigious customer can divert the beta into consultancy.
Zapier's first-year account says a redesigned interface nearly tripled engagement among beta customers. That is the kind of behavioural change worth measuring. Engagement alone still needs a paid continuation or retention test before it proves the business.
Know when the beta is ready to open
Move beyond founder-selected customers when ten or more suitable buyers can reach the promised outcome, delivery time is falling, failures are understood, and a meaningful share chooses the paid continuation. Set your own thresholds before selling.
Do not stay in private beta because close support feels productive. A controlled public launch tests whether the message and onboarding work without founder context. Conversely, do not open simply to celebrate a date if support or security cannot handle it.
Sell the first loop this week
Within two days, find 20 current problem traces. Contact ten people with a narrow, honest offer and request a short conversation. By day five, present a paid beta with written boundaries to the best fits. Aim for the first three sales, deliver them closely and log every minute and failure. After ten customers, compare contribution, repeated requests and continuation. Then improve, reposition or stop. Do not replace this evidence with a launch audience that has never paid.
Related guides
Frequently asked questions
Is it legal to charge for unfinished software?
It can be, provided you describe the product and limitations truthfully, agree clear terms, protect data, fulfil what was promised and comply with applicable consumer or business law. Calling something a beta does not waive statutory rights or excuse unsafe handling. Rules differ by country, customer type and sector. Explain availability, support, changes, cancellation and refunds before payment. For regulated data or material customer operations, obtain qualified legal and security advice. Do not sell access when known failures could cause harm you cannot contain.
How much should I charge for a paid beta?
Charge enough to require a real decision but not as though the product already offers mature reliability. Work backwards from the value of the narrow outcome, delivery cost and future pricing. A large discount can attract buyers who will never accept the intended price, so record it explicitly and test continuation at a sustainable rate. Avoid lifetime deals before you understand support and infrastructure liability. There is no universal percentage. Compare buyer behaviour at two or three clear prices while keeping the promised outcome consistent.
Should early customers receive a permanent discount?
Usually no. A time-limited founding rate or account credit is easier to cost than an unlimited promise. Permanent discounts compound as service, infrastructure and scope grow, and they can make unprofitable accounts difficult to change. Reward early customers through close support, influence over priorities or a defined period at the beta price. State the future price or review date before purchase. If you do promise a lasting term, model its lifetime cost and document exactly what product and usage it covers.
What if nobody agrees to pay before launch?
Diagnose the rejection before building more. Prospects may lack the problem, distrust the unfinished product, dislike the offer, lack authority or face unacceptable switching risk. Ask what they do now and what evidence would permit payment. Test a smaller paid outcome, such as setup or a manual service, if it still proves the same need. Do not assume a free beta will later convert. If 20 well-selected prospects reject a clear low-risk offer for the same reason, treat that as evidence and reconsider the segment or problem.
How many beta customers are enough?
Ten paid customers can expose repeated delivery and positioning problems, but it is not proof of a scalable market. Continue until patterns recur across buyers who are not all from one network or channel. For low-value software, 20 to 30 may provide a firmer view of activation and continuation. For complex business software, fewer accounts can generate deeper evidence, but one large buyer should not dictate the product. Decide using repeated outcomes, falling support effort and paid retention, not a ceremonial customer count.
Should I build requested features during the beta?
Build only when a request is necessary for the promised outcome, repeats across suitable customers, or materially lowers delivery effort. Record requests before responding so urgency from one vocal buyer does not become the roadmap. Ask what the customer cannot do without it and whether a manual workaround works during the test. Price bespoke work separately if it serves one account. The beta exists to identify a repeatable product, not to make every early buyer's internal process your permanent responsibility.
Comments (0)