SaaS Product Launch: From MVP and Soft Launch to Feature Launches
A SaaS product launch guide: launching an MVP, running a soft launch, feature flags to separate deploy from release, sizing feature launches, B2B launches.
SaaS Product Launch: From MVP and Soft Launch to Feature Launches
Quick answer: A SaaS product launch is a sequence: an MVP for a few users you recruit, a quiet soft launch to fix onboarding and billing, a general-availability launch, then ongoing feature launches sized by impact. Deploy ahead of time behind feature flags so launch day is a switch, not a deploy. For B2B, prepare a self-serve trial, security and legal documents, and tell existing customers first.
A SaaS product launch isn't one event. It's a series of releases, from MVP to soft launch to general availability to every feature launch after that, and the teams that launch well treat each one as a different kind of release with different rules.
This guide breaks the SaaS launch into those stages, explains how to separate deploying code from releasing it, and covers what changes when you sell to businesses instead of individual developers. It's for technical founders who own both the product and the launch.
The five kinds of SaaS launch
Most launch confusion comes from treating a feature update like a product debut, or an MVP like a finished product. Name the stage first:
| Stage | Who sees it | Goal | Public announcement? |
|---|---|---|---|
| MVP launch | A small group who opted in | Prove one workflow solves a real problem | No, or a quiet post to a niche community |
| Soft launch | Anyone who finds it, but you don't promote it | Find bugs, onboarding gaps and pricing objections at low volume | No; a public URL, but no campaign |
| General availability (GA) | Everyone | Acquire users at scale | Yes: the full launch |
| Feature launch | Existing users first, then the market | Retention and a reason to talk about the product again | Sized by impact |
| Relaunch | Everyone again | Reintroduce a substantially changed product | Yes, if the change is real |
Each stage needs less polish than the next. An MVP can have manual steps behind the scenes. A soft launch needs working billing. GA needs docs, support and the infrastructure to absorb a spike.
Say publicly what each label means
"Beta" means different things to different teams, and B2B buyers will ask. Large platforms write their definitions down. Google Cloud's product launch stages say Preview offerings "are not necessarily feature-complete", come with no SLAs or technical support commitments, and are intended for test environments unless Google says otherwise. General Availability products are "open to all customers, ready for production use" and covered by an SLA where applicable.
You don't need a legal page, but we'd suggest a short paragraph in your docs or pricing FAQ that answers three questions for each label you use: can I run this in production, will it change without notice, and what support do I get? Put the label next to the feature in the UI and the docs, not just in the launch post. When a feature moves from preview to GA, that move is itself a small feature launch.
Launch an MVP to learn, not to announce
The point of an MVP launch is to watch real users try one workflow end to end. Keep the audience small enough that you can talk to every user.
- Pick one job. The MVP should do one thing well enough that someone would be annoyed if you took it away.
- Recruit users directly. Invite people from your waitlist, your network or communities where you already participate. Ten engaged users beat a thousand signups who never log in.
- Instrument the activation path. Track each step from signup to first useful result, so you can see where people stop.
- Charge early if you can. Even a small price tells you more about demand than a free beta.
Don't post an MVP to big launch channels unless it already works without hand-holding. You usually get one good shot at each audience, and Product Hunt, for example, asks makers to wait at least two months between posts for the same product and requires a significant update to relaunch.
Example: a long preview before a paid GA
GitHub Copilot is a well-documented case of a limited preview turning into a paid launch. GitHub announced it on June 29, 2021 as a technical preview with a limited number of spots. The GA announcement came on June 21, 2022: $10 a month or $100 a year, free for verified students and open-source maintainers, after more than 1.2 million developers had used the preview over 12 months.
The lesson for a small SaaS isn't the scale. It's the sequence: the preview had a clear name and limited access, the GA launch came with a price and a free tier for the communities that matter to developer tools, and the announcement could point to a year of real usage. Your MVP and soft launch exist to give your GA post that kind of evidence, even if it's "40 teams used it for three months" rather than a million developers.
Soft launch: make the product public, quietly
A product soft launch puts the product at a public URL with self-serve signup, but without a campaign. People find it through search, your content and word of mouth, at a volume you can handle.
Use the soft launch to fix the things a big launch would expose all at once:
- Signup and onboarding friction that your early users learned to work around.
- Billing edge cases: failed cards, upgrades mid-cycle, refunds, tax.
- Questions that keep repeating, which become your FAQ and docs.
- Performance problems under real, messy usage rather than test data.
This is also the time to get your public surface in order: a pricing page, a changelog, a status page and listings on discovery platforms. You can list a product on TechLogHub during a soft launch and post each improvement to the releases feed, so the product builds a visible history before the big day. Check every page's title and description with a meta tag generator and give each a social preview using the OG tag generator.
Separate deploying code from releasing features
The biggest technical change in a mature SaaS launch process is that launch day stops being deploy day. Martin Fowler's article on feature toggles describes release toggles that let "incomplete and un-tested codepaths" ship to production as latent code, separating feature release from code deployment. The same article notes product managers can use them to hold back finished features until a launch tied to a marketing campaign.
In practice:
- Deploy days or weeks ahead behind a flag that's off for everyone.
- Enable it for your team, then a small cohort. Fowler's article walks through rolling a change out to roughly 1% of users before everyone.
- Flip the flag on launch day. If something breaks, turn it off instead of rolling back a deploy.
- Remove the flag afterwards. The article says release toggles should generally be short-lived, removed within a week or two.
Supabase describes a version of this in how it runs launch weeks: features ship when they're ready and are promoted again during a launch week, because many people miss the first announcement. The team also stopped shipping to production on launch day itself. Both ideas apply to small teams: ship early, announce later, and keep launch day free for replies and monitoring.
Canary the risky parts
Flags control who sees a feature. Canaries control how much risk a deploy carries. Google's SRE workbook chapter on canarying releases defines a canary as "a partial and time-limited deployment of a change in a service and its evaluation." Its advice translates well to small teams:
- Watch few metrics. The chapter suggests no more than about a dozen, starting from user-visible signals such as request failures and latency rather than CPU.
- Pick metrics the change can actually move. If an unrelated process can change the number, it can't tell you whether the release is healthy.
- Cover peak traffic. Some defects only show up under load, so a canary that runs only at 3 a.m. proves little.
- Run one canary at a time. Overlapping canaries make it impossible to tell which change caused a problem.
For a launch, apply this to whatever changed in the infrastructure: a new database index, a new queue worker, a new region. Canary those deploys in the week before launch, so launch day only flips flags on code that has already handled real traffic.
Keep flags from turning into debt
Release flags pile up quickly around a launch. Some rules we'd suggest: give every flag an owner and a removal date when you create it, name it after the feature rather than the ticket (billing-annual-plans, not PROJ-412), and add removing launch flags to the week-two runbook. If you're choosing tooling, OpenFeature is "an open specification that offers a vendor-agnostic, community-driven API for feature flagging" and became a CNCF incubating project in December 2023. Coding against a standard API means you can start with a simple in-house provider and switch to a hosted one later without rewriting every flag check.
Feature launches: size them honestly
After GA, most of your launches will be feature launches. They're how existing users notice progress and how new users hear about you again. They also tempt teams to oversell.
| Feature size | Example | Where to announce |
|---|---|---|
| Major | New product area, self-hosted edition, new platform | Launch post, email, social, communities; possibly a relaunch |
| Medium | Important integration, new API, pricing change | Changelog, email to affected users, social thread |
| Minor | Fixes, UI polish, small options | Changelog and release notes |
Platforms enforce this distinction. Hacker News' Show HN guidelines say new features and upgrades generally aren't substantive enough for Show HN. Product Hunt's relaunch policy says new UIs and pricing plan changes aren't considered significant updates. A medium feature belongs in your own channels, not on a launch platform.
Write the changelog entry for every feature launch, even small ones. Converting it to a page with a Markdown to HTML converter takes seconds, and a steady changelog is the cheapest evidence that a SaaS product is alive.
Pricing, billing and tax before GA
The soft launch is where billing bugs should surface, at a volume where you can refund by hand. By GA, the paths below should work without a founder stepping in. This list is our advice on what to test, not an exhaustive spec:
| Billing path | What to test before GA | Why it matters on launch day |
|---|---|---|
| New subscription | Card, 3-D Secure challenge, declined card, coupon | A spike of signups exposes every payment edge case at once |
| Upgrade and downgrade | Mid-cycle changes, proration, seat changes | Teams that like the product upgrade within days |
| Trial end | Reminder email, conversion, what happens to data if they don't pay | Trials started on launch day all end on the same day |
| Cancellation and refund | Self-serve cancel, refund flow, final invoice | A clear exit builds trust; a hidden one becomes a public complaint |
| Invoices | Company name, tax ID field, billing address, PDF download | B2B customers can't expense a payment without a proper invoice |
Tax is the item founders most often leave too late. Rules depend on where you're based and where customers are, so get advice for your situation. One example of why it matters early: the EU's VAT One Stop Shop has a non-Union scheme for businesses established outside the EU with no EU fixed establishment that sell services to EU consumers, letting them register in one EU country and file a quarterly VAT return there. If your SaaS sells self-serve plans to individuals worldwide, a launch can create obligations like this from the first EU sale.
Publish the pricing page before launch day too. A launch post that says "pricing coming soon" turns interested visitors into people waiting for a second announcement that most of them won't see.
What changes in a B2B product launch
A B2B product launch has more stakeholders and a longer path from interest to payment. The person who finds you on launch day is rarely the person who signs the contract.
| Need | What to prepare before GA |
|---|---|
| Evaluation | A free trial or sandbox that works without a sales call, plus clear pricing or a starting price |
| Security review | A security page covering data handling, hosting region, access controls and how to report vulnerabilities |
| Procurement | Terms of service, privacy policy and a data processing agreement ready to send |
| Internal champion | A one-page summary your user can forward to their manager |
| Existing customers | Advance notice of the launch, early access and a direct line for questions |
A security page that answers the first questionnaire
Security reviewers usually start with the same questions. A security page that answers them saves a round of email for every deal. Suggested sections: where data is hosted and in which region, what's encrypted in transit and at rest, who on your team can access customer data and how that's logged, how backups work and how often you test a restore, which subprocessors you use, and how to report a vulnerability.
For that last item, publish a security.txt file. RFC 9116 says it must be placed under the /.well-known/ path, and only two fields are required: Contact and Expires. A minimal file is two lines: Contact: mailto:[email protected] and an Expires: date. Put a calendar reminder before the expiry date; an expired file tells researchers nobody is watching.
Be precise about compliance. If you're working towards an audit, say so and give the stage; don't put a certification badge on the page before you have the report. Buyers check.
Tell existing customers before the public. In B2B, a surprised customer is a support escalation; a customer who got early access is a reference.
Measure B2B launches over a longer window. Trials started this week may not convert for a month or more, so judge the launch on qualified trials, activation within accounts and pipeline created, not day-one signups.
Metrics for each launch stage
Each stage answers a different question, so judging an MVP by signups or a GA launch by individual interviews gives the wrong answer. These are the metrics we'd suggest, with definitions you can log:
| Stage | Primary metric | How to define it |
|---|---|---|
| MVP | Weekly active use of the core workflow | Users who completed the one job at least once in a given week ÷ users invited |
| Soft launch | Activation rate | New signups who reach the first useful result within 7 days ÷ new signups |
| Soft launch | Unassisted onboarding | Activated users who never contacted support or a founder ÷ activated users |
| GA | Qualified signups and trial-to-paid | Signups matching your target user; paid conversions ÷ trials that ended in the period |
| Feature launch | Adoption among existing users | Active accounts that used the feature within 30 days ÷ active accounts |
| B2B GA | Pipeline created | Accounts with an active trial and a named contact who asked about pricing, security or procurement |
Pick the definition of "first useful result" once and keep it fixed across stages; otherwise activation improves on paper whenever someone redefines it. Track time to first useful result too. If activation holds steady but takes twice as long after GA, the new audience is less familiar with the problem, and your onboarding needs to explain more.
Set a review date before launch. A week after GA, look at activation and support volume. A month after, look at trial-to-paid and retention of the first cohort. Write down what you'd change for the next launch while it's fresh.
A launch-day runbook for SaaS
- T−1 week: Deploy everything behind flags. Run billing, signup and the main workflow on production with test accounts.
- T−1 day: Enable flags for internal users. Confirm alerts reach the person on call. Email existing customers.
- Hour 0: Flip the flags. Publish the launch post. Post on your primary channel. See our product launch strategy for channel selection and timing.
- Day 0: Watch error rates, signup completion and activation. Reply to every comment. No unrelated deploys.
- Week 1–2: Remove release flags, ship one fix users asked for, and post it on the releases feed.
Decide rollback triggers in advance
Launch-day decisions are worse than T−1 week decisions, because everyone is tired and watching comments. Write the triggers down beforehand. The thresholds are yours to set; this table shows the shape we'd suggest:
| Symptom | First action | Then |
|---|---|---|
| Error rate on the new feature well above your normal baseline | Turn the feature flag off | Post a short status update; fix behind the flag; re-enable for a small cohort first |
| Signup or checkout failing | Pause the launch post promotion; switch to a fallback (waitlist form or manual invoice) | Fix, test with a real card, resume |
| Database or queue saturated | Rate-limit the heaviest endpoint; scale the resource | Reply to commenters that you're handling load, with an honest ETA |
| A bug in already-deployed code unrelated to the launch | Leave it unless it blocks signup or data integrity | Fix after the launch window; no unrelated deploys on day 0 |
Assign one person to make the call. On a two-person team, that means one founder watches dashboards and decides, while the other answers comments. Swapping roles every few hours is fine; both doing both is how a broken checkout goes unnoticed for an hour.
If you're planning the announcement side of the day as well, the sibling guides on a Product Hunt launch and a product launch website cover channel timing and the page itself.
FAQ
What is a SaaS product launch?
It's the process of releasing a software-as-a-service product to users. In practice it's a series of releases: an MVP for a small group, a soft launch, general availability, and ongoing feature launches, each with different goals and announcement levels.
What is a product soft launch?
A soft launch makes the product publicly available with self-serve signup but without a promotional campaign. It lets you fix onboarding, billing and performance problems at low volume before a full launch.
How should I launch an MVP?
Launch it to a small group you recruit directly, focus on one workflow, track every step to activation, and talk to every user. Avoid big launch platforms until the product works without your help.
How do feature flags help a SaaS launch?
Release toggles let you deploy code before launch with the feature switched off, enable it for a small cohort first, and turn it on for everyone on launch day. If something breaks, you switch it off instead of rolling back.
Can I relaunch on Product Hunt after a big feature update?
Product Hunt asks makers to wait at least two months between posts for the same product and requires a significant update. It says new UIs and pricing changes don't count. Earlier relaunches need a reviewed request.
How is a B2B product launch different?
B2B buyers need a self-serve trial, clear pricing, a security page, legal documents for procurement and something a champion can forward internally. Tell existing customers first, and measure results over weeks, not days.
Ship code early, flip the switch on launch day, and keep launch platforms for changes big enough to deserve them.