# Soft Launch vs Beta Launch: Which Should an Indie Maker Choose?

> Soft launch vs beta launch: compare access, audience size, support load and exit criteria, then pick the release stage that fits your product.

- Canonical: https://zeroraised.com/blog/soft-launch-vs-beta-launch
- Published: 2026-10-19
- Updated: 2026-10-19
- Author: Jay Mokashi (https://zeroraised.com/blog/authors/jaymokashi)
- Publisher: ZeroRaised (https://zeroraised.com/)
- Section: Growth
- Tags: launch-strategy, pre-launch, launch-checklist, bootstrapping

Soft launch vs beta launch comes down to the promise you make to the people who get in. A beta launch gives a chosen or open group an unfinished product in exchange for feedback, with a plain warning that it may break. A soft launch releases the real product, at its real price, to anyone who finds it, but with little or no promotion, so you can test support, billing and demand before a full launch.

**Disclosure:** ZeroRaised publishes this guide and appears in the final section. The stage definitions are editorial guidance built from the linked platform documentation, and this guide makes no promise of traffic, sign-ups or revenue from any launch stage or listing.

## TL;DR

A beta tests the product. A soft launch tests the business around it: whether strangers can sign up without help, whether payment and refunds work and whether the support inbox stays manageable. In a beta you can still say *this bit is broken, sorry*. In a soft launch you are selling the thing, so people judge it as the thing.

A full launch is the loud part. A dark launch is new back-end code running in production that users cannot see: an engineering check, not a marketing stage.

Apple’s phased release and Google Play’s staged rollouts are for updates only, so if you want to limit who gets a first app release, use the beta tracks.

Pick the stage by the question you still need answered, and write down the conditions for leaving it before you let anyone in.

| Stage | Who can get in | What you promise | Main thing you learn | Signal to move on |
|---|---|---|---|---|
| Private beta | Invited people only | Unfinished, may break, feedback wanted | Whether the core job works for the right users | Serious defects fixed, feedback themes repeat |
| Open beta | Anyone who opts in | Unfinished but usable, feedback wanted | Whether it holds up with strangers and more devices | Support questions are answered by docs, stability holds |
| Soft launch | Anyone who finds it, little promotion | Finished product at its real price | Whether billing, onboarding and support hold up with paying customers | Payments, refunds and support run without firefighting |
| Full launch | Everyone you can reach | Finished product, actively promoted | Whether demand scales through your channels | Ongoing iteration (no exit) |
| Dark launch | No visible change for users | Nothing; users cannot tell | Load and performance of new back-end code | Capacity confirmed, feature can be switched on |

## A current maker’s reminder: twelve years of private use before a help center

On 15 Oct 2026, calyhre posted a Show HN for Forwarder.cc, a service that takes the HTML forms on static websites, sends each submission to an email inbox and charges per message ([Show HN post](https://news.ycombinator.com/item?id=50108386), checked 18 Oct 2026). The post opens: “12 years ago I built a service that forwards simple HTML forms to an email address. I've been procrastinating on finishing it ever since, until today.”

The detail that matters here is how finished it already was. “By 2016 I had done about 90% of what I'm showing you today,” calyhre writes. “Everything was ready: backend, frontend, hosting, Stripe, landing page.” Another of their projects took off and absorbed their attention, and Forwarder.cc kept running, upgraded and maintained for years “(again, for my own use only).” It was a working product used only by its maker.

Then comes the honest bit: “The only thing that ever held me back from launching it was a missing help center, and, more honestly, the fear of putting it in front of people.” And the release line: “So today's the day: after 12 years of procrastination, I finally finished the help center.”

The blocker was not the engine, billing or design. It was a support item, plus nerves, and nothing said *when the help center exists, we go*, so the gap had no deadline. When it did go out, it went straight to a public, priced release: the [Forwarder.cc site](https://forwarder.cc) offers to “Start now with 50 free credits” and states “1 credit = 1 message”, with packs listed at “500 credits for 5 €” and “1,500 credits for 12 €” (checked 18 Oct 2026).

The same day, Vitko, Inc. took the opposite route and named its stage out loud. [Vitko’s announcement](https://vitko.inc/news/vitko-runners-private-beta) says “Today we're opening the private beta of Vitko Runners” and, a few paragraphs on, “The private beta is open today: $0.002 a minute, with 2,000 free minutes every month.” (checked 18 Oct 2026). A small company put a beta label, a public price and a join button on the product from the first hour.

Two products in one week is not a pattern. The transferable lesson is narrower: decide in advance what each stage has to prove, and what will move you to the next one.

## Soft launch vs beta launch: what each stage promises users

A beta is an explicit contract. The product is unfinished, it may be unstable, and in return for putting up with that, you want to hear what goes wrong. GitHub makes the label literal. Its release form has a “This is a pre-release” option to “notify users that the release is not ready for production and may be unstable”, and you can later change whether a release is a pre-release or the latest one ([GitHub Docs on managing releases](https://docs.github.com/en/repositories/releasing-projects-on-github/managing-releases-in-a-repository), checked 18 Oct 2026).

A soft launch makes no such excuse. The product is out, at its real price, on its real terms, and anyone who finds it can buy it. The only thing missing is the noise: few enough people arrive that you can watch each one. They do not know they are early, so they forgive far less.

That difference in label changes four practical things:

- **Price expectations.** A beta invites questions about whether you should pay at all; a soft launch assumes you will.
- **Bug tolerance.** Beta users report a broken export. Soft launch customers ask for a refund.
- **How failure travels.** A rough beta is expected. A rough public product gets described as rough by the people who bought it.
- **What you owe in support.** A beta group is small and high touch. A soft launch needs written answers for strangers.

Beta does not mean free, either. Google Play states plainly that “Testers must purchase paid apps when participating in open or closed tests.” ([Google Play testing tracks](https://support.google.com/googleplay/android-developer/answer/9845334?hl=en), checked 18 Oct 2026). Vitko charges in its private beta. Price is a choice you make at every stage, not part of the definition.

Where to announce each stage is a separate question, covered in [Product Hunt vs BetaList](https://zeroraised.com/blog/product-hunt-vs-betalist). This guide is about who gets access and on what terms.

| Dimension | Beta launch | Soft launch |
|---|---|---|
| Access | Invite list or opt-in programme | Public; anyone who finds it |
| Product state | Unfinished, labelled as such | Finished enough to sell without caveats |
| Price | Free, discounted or real (your choice) | Real price and real terms |
| Promotion | Recruited testers, targeted asks | Little or none |
| Feedback | Actively requested and expected | Gathered from support, usage and cancellations |
| What users forgive | Bugs, gaps, rough edges | Much less; it is the product |
| Support load | Small, high touch | Real customer support, smaller volume |
| Exit | Into soft launch or full launch | Into full launch |

## Map the access models before you choose a label

The platforms you ship through have actual switches, and they do not always line up with the words.

### Beta tracks for a first release

[Apple TestFlight](https://developer.apple.com/testflight/) lets you add up to 100 members of your own team as internal testers, and says “You can also invite up to 10,000 external testers to join your beta program.” (checked 18 Oct 2026). It also supports public links, so “you don't need to have anyone's contact information to invite them.” A public link posted somewhere visible starts to behave like a quiet public release.

[Apple’s external tester guide](https://developer.apple.com/help/app-store-connect/test-a-beta-version/invite-external-testers/) adds two details worth planning around (checked 18 Oct 2026). A public link can “set tester criteria, such as device and OS requirements”, which is a cheap way to keep the group to the devices you have actually tested. And “The first build you submit requires a full review, but later builds for the same version might not.” Put review time into the beta schedule.

[Google Play’s testing tracks](https://support.google.com/googleplay/android-developer/answer/9845334?hl=en) are more granular (checked 18 Oct 2026). Internal testing lets you “quickly distribute your app to up to 100 testers for initial quality assurance checks.” Closed testing lets you “create up to 200 lists, and each list can contain up to 2,000 users.” Open testing is the interesting one: “Anyone can join an open testing program and submit private feedback”, and users can find the open test “through search on Google Play”. An open test on Play is already semi-public. Strangers can discover it, so get your help pages ready first.

### Gradual rollouts are for updates, not first releases

[Apple’s phased release](https://developer.apple.com/help/app-store-connect/update-your-app/release-a-version-update-in-phases/) lets you “release your app's update gradually over 7 days”, rising from 1% on day one through 2%, 5%, 10%, 20% and 50% to 100% on day seven (checked 18 Oct 2026). You can pause “for up to 30 days, with no limit on the number of pauses”. Updates in phased release “can be manually downloaded from the App Store by anyone at any time.”

[Google Play’s staged rollouts](https://support.google.com/googleplay/android-developer/answer/6346149?hl=en) work the same way in spirit, and the documentation is blunt: “Staged rollouts can only be used for app updates, not when publishing an app for the first time.” It also notes that “Users won't be notified if they receive a version of your app in a staged rollout.” (checked 18 Oct 2026).

For web apps and SaaS, the equivalent is a feature flag. [LaunchDarkly’s progressive rollouts](https://launchdarkly.com/docs/home/releases/progressive-rollouts) serve a variation to a percentage of contexts and raise it over time, with an example going from “5% up to 100% in a series of steps over 24 hours” (checked 18 Oct 2026). The same page says “Progressive rollouts do not include metric monitoring”, so you still watch errors and support yourself. A flag in your own database does the same job for a small product.

| Mechanism | Audience limit as documented | Visible to the public? | Works for a first release? | Source |
|---|---|---|---|---|
| TestFlight internal testing | Up to 100 team members | No | Yes | Apple TestFlight |
| TestFlight external testing | Up to 10,000 testers per app, public link optional | Only via your link | Yes (first build needs full review) | Apple external testers |
| Play internal testing | Up to 100 testers | No | Yes | Play testing tracks |
| Play closed testing | Up to 200 lists of up to 2,000 users | No | Yes | Play testing tracks |
| Play open testing | Anyone can join | Yes, findable in Play search | Yes | Play testing tracks |
| Apple phased release | 1% rising to 100% over 7 days | Yes, manual download open to all | No, updates only | Apple phased release |
| Play staged rollout | A percentage you raise over time | Yes | No, updates only | Play staged rollouts |
| Feature-flag progressive rollout | A percentage of contexts, raised in steps | Only to the chosen share | Yes for web features | LaunchDarkly |
| GitHub pre-release | Anyone who views the repo | Yes, labelled unstable | Yes | GitHub Docs |

## Dark launch vs soft launch, and other labels people mix up

Most of the confusion goes away once you ask: who can see it, and what have you promised them?

### Dark launch vs soft launch

[Martin Fowler’s note on dark launching](https://martinfowler.com/bliki/DarkLaunching.html) describes it as “taking a new or changed back-end behavior and calling it from existing users without the users being able to tell” (checked 18 Oct 2026). The note adds that “It's done to assess the additional load and performance impacts”. The key word is existing. A dark launch needs traffic that is already there, so a brand new product cannot dark launch itself. You can, though, dark launch a new back end behind an old one, such as a new search index compared against the current one.

A soft launch is visible to anyone who lands on the page. The quietness is in promotion, not in the code.

### Soft launch vs full launch (and soft launch vs hard launch)

Soft launch vs full launch is the same product with a different volume of announcement. You have not changed the price or the features; you have started telling people. “Hard launch” is used for the loud, all-at-once version with a fixed date, and in practice it means a full launch where everything lands together. The real risk in the jump is volume: more sign-ups, support mail and load in one afternoon than in the whole soft launch. Read [how to handle traffic spikes](https://zeroraised.com/blog/how-to-handle-traffic-spikes) before you pick a date.

### Pre launch vs soft launch

Pre launch vs soft launch is easier. In pre launch there is nothing to use yet, only a landing page, a promise and a list of people who want to hear more. In a soft launch the product works and takes money. The guide on [how to build a waitlist before launch](https://zeroraised.com/blog/how-to-build-a-waitlist-before-launch) covers the first of those. The list is where your private beta invites come from; invite first the people who replied with a real problem.

## Choose by audience size, support load and feedback goal

The choice is mostly about what you do not yet know. Answer these in writing:

- Has the core job worked for someone who is not you, on their data, without you sitting next to them?
- Could you answer every support request this week inside the hours you actually have?
- Does billing work end to end, including a refund, a failed card and a cancellation?
- Do you need structured feedback on the product, or just proof that people will pay for it?
- How bad is a public failure for this audience? A broken payments tool costs customers money; a broken colour picker costs them a minute.

As editorial guidance: the less certain the product, the smaller and more explicit the group. The less certain the business around it, the more you need paying users, which means a soft launch. A private beta cannot tell you whether people will pay, because you chose them and they know it. A soft launch hides a broken core flow, because people who hit it quietly leave.

Audience size follows. A private beta is people you can name. An open beta is for breadth: odd devices and setups you would never have tested. A soft launch is for whoever turns up through search or your own site.

Support load is the constraint indie makers underestimate. In a beta you answer everything personally. In a soft launch the same question arrives repeatedly, and you end up writing the help page you should have written before.

Forwarder.cc is a useful illustration here, not a verdict. Years of solo use answered *does this work for me?* many times over. It never answered *can I support strangers?*, which is the question the missing help center stood for. A short private beta with outside users would have surfaced that gap sooner; whether it would have changed the timing, nobody can say.

| If this is true | Pick | Why |
|---|---|---|
| The core job has only been tested by you | Private beta | You need outsiders before you need a price test |
| The product works but you expect many device or setup combinations | Open beta | Breadth of environments matters more than depth of feedback |
| The product is finished but billing, onboarding and support are untested with strangers | Soft launch | Only paying users exercise the whole path |
| You are shipping new back-end behaviour under an existing product | Dark launch or progressive rollout | Users should not notice; you are testing load |
| Support, billing and capacity have held up for a few weeks | Full launch | Promotion is now the constraint, not the product |
| You have nothing usable yet | Pre launch (landing page and waitlist) | There is nothing to test with users |

## Write exit criteria before you open access

The GOV.UK Service Manual gives a ready-made gate system. [How the beta phase works](https://www.gov.uk/service-manual/agile-delivery/how-the-beta-phase-works) says “You'll start in private beta by inviting a limited number of people to use your service.” and “Once you've improved the service and you're confident you can run it at scale, you take a beta assessment to move into public beta.” (checked 18 Oct 2026). [How the live phase works](https://www.gov.uk/service-manual/agile-delivery/how-the-live-phase-works) then describes live as “supporting the service in a sustainable way, and continuing to iterate and make improvements.”

Each move is a decision against stated conditions, not a feeling. A solo maker needs no assessment panel, just a short written list, made before the first invite goes out, covering:

- the defect level you will accept;
- the feedback themes that must be resolved;
- billing tested with a charge, a refund and a failed card;
- help pages for the questions you already know people will ask;
- a support response time you can keep;
- a way to roll back a bad build.

Add a date. On that date you either move on or write down which criterion failed and what you will do about it. That one line is the cure for open-ended private use.

For the full pre-launch list, use the [product launch checklist for bootstrapped makers](https://zeroraised.com/blog/product-launch-checklist-for-bootstrapped-makers). To tell beta users what changed between builds, see [how to write release notes](https://zeroraised.com/blog/how-to-write-release-notes).

| Move | Exit criterion | Evidence to check |
|---|---|---|
| Private beta to open beta | No known defect blocks the core job | Bug list, session notes from invited users |
| Private beta to open beta | The same feedback themes keep recurring rather than new ones | Grouped feedback notes |
| Open beta to soft launch | Help docs answer the most common questions | Support inbox, repeat questions |
| Open beta to soft launch | Payment, refund and failed-card paths tested | Test transactions in your billing provider |
| Soft launch to full launch | Support volume fits your available hours | Response times over recent weeks |
| Soft launch to full launch | Capacity checked for a traffic spike | Load test or hosting limits reviewed |

## Move between stages without losing trust

When the beta label comes off, tell the people who were there what changes: the price, whether their data carries over, and what support they can now expect. Thanking them, or keeping an early price for them, is your choice. Silence is the one option that costs goodwill.

Keep a reverse gear once you are public. On GitHub a pre-release can later be marked as the latest release. Apple lets you pause a phased update, and Google Play notes that a halted staged rollout, once resumed, goes to “the same set of users”.

Listing sites also treat the stages separately. [BetaList’s criteria](https://betalist.com/criteria) accept a “Private beta accessible by invitation only” and say “Each startup gets two opportunities to be featured. Once pre-launch, and once during launch.” (checked 18 Oct 2026). Decide which moment each listing belongs to before you spend it.

## When to skip the beta and soft launch directly

Jesse Gamble’s DEV post [I Launched the Idea That Started All of This](https://dev.to/eternaclarity/i-launched-the-idea-that-started-all-of-this-56ec) (16 Oct 2026, checked 18 Oct 2026) describes a bounded hold rather than an open one. “I could have launched roughly a month earlier,” Gamble writes. “I didn't think the core alone was the product I wanted customers to receive.” And then: “So I held the release instead of giving myself an earlier launch announcement. On October 4, I finally shipped it.” A month, with a stated reason, is a very different thing from twelve years.

Skipping a formal beta is reasonable for a small, low-risk tool, for a narrow audience you already talk to, or where a real payment is the only test that means anything. For the wider sequence, see [how to launch a bootstrapped app](https://zeroraised.com/blog/how-to-launch-a-bootstrapped-app).

## Where a launch listing fits after a soft launch

A soft launch gives you better material for a full launch: onboarding strangers have used, billing that has taken real money and help pages that answer real questions. It does not guarantee anyone will turn up.

[ZeroRaised](https://zeroraised.com/) is a free launch site for bootstrapped makers whose products have no institutional VC or accelerator equity. If your public product fits and the soft launch has held up, you can [submit it for review](https://zeroraised.com/submit). The [maker perks page](https://zeroraised.com/perks) is a separate resource for eligible makers; neither replaces exit criteria or support work.

The practical answer to soft launch vs beta launch is to pick the stage that answers your next unknown, and leave it when its exit criteria are met.

## Frequently asked questions

### What is the difference between a soft launch and a beta launch?

A beta launch gives a chosen or open group access to an unfinished product in exchange for feedback, with a clear warning that it may be unstable. A soft launch releases the finished product publicly at its real price but with little or no promotion, so you can test support, billing and demand quietly.

### Is a soft launch the same as a full launch?

No. Both are public, but a soft launch keeps promotion low so problems surface with a small number of real customers. A full launch adds announcements, launch listings and outreach once the product and support process have held up.

### What is a dark launch?

A dark launch ships new back-end behaviour to production and calls it from existing traffic without users being able to tell, mainly to test load and performance. A soft launch, by contrast, is visible to anyone who finds the product.

### Can you soft launch an app on the App Store or Google Play?

You can publish quietly without promotion, but the gradual release tools do not cover a first release. Apple phased release and Google Play staged rollouts apply to updates of a published app, so use TestFlight external testing or Google Play internal, closed or open testing to limit who gets a first version.

### How do you know when a beta is ready to become a launch?

Set exit criteria before the beta opens, such as no unresolved serious defects, repeated feedback themes addressed, billing tested end to end, help documentation written and a support load you can sustain. Move on when those conditions are met rather than when the product feels perfect.