Half of saas MVPs launch broken. Not because the code fails, but because billing was not wired, the privacy policy did not exist, monitoring was not set up, or no one was on call for the first 48 hours. The pattern is so consistent across agency and accelerator alumni networks that “launch readiness” has become its own discipline, separate from product development. The saas pre-launch checklist below is built around that discipline.
This guide covers 12 critical items across four categories (technical, compliance, commercial, operational), the 12-Point Launch Readiness Score that scores readiness on a 24-point scale, the 48-hour soft launch protocol that surfaces problems before public launch, and the corrective action when the score falls below 18/24. The complete saas pre-launch checklist runs as a downloadable template at the end of this article.
Five takeaways before reading on: the four readiness categories that decide whether a launch survives, the 12 items every saas pre-launch checklist must cover, the 18/24 threshold that separates “launch now” from “delay launch,” the 48-hour soft launch protocol, and the specific corrective actions when the score is too low. For the broader build framework that places this launch decision in context, see how to build a saas in 2026.
Why Most Saas Pre-Launch Checklist Items Get Skipped
Most saas teams treat launch readiness as a one-day task. The team finishes the build, declares it done, and announces. What they skip is everything that happens after the customer signs up: the billing webhook that fails silently, the password reset flow that does not exist, the audit log that has no retention policy, the support email that goes to a personal Gmail no one checks on weekends.
The reason these items get skipped is psychology, not capability. Building features feels like progress; setting up Sentry alerts does not. Writing a privacy policy feels boring; shipping a new feature feels like real work. The saas pre-launch checklist exists to force the team to do the unglamorous work that makes the launch survive contact with real customers.
Three patterns explain why teams under-invest in launch readiness. First, most founders have not seen what happens at the 48-hour mark when a billing webhook misfires for the first paying customer. Second, the cost of skipping each item feels small in isolation; the cost of skipping ten items is the same as launching broken. Third, the metrics that signal launch readiness (alerts wired, backups tested, dunning configured) do not show up in product demos or investor updates, so they get deprioritized.
The single most expensive launch mistake is the absence of a saas pre-launch checklist that scores readiness honestly before the launch button gets pressed. The taxonomy of mistakes that cause this is covered in depth at common saas mvp mistakes.
The Four Categories of the Saas Pre-Launch Checklist
The saas pre-launch checklist organizes 12 items into four categories of three items each. Each category covers a different failure mode that wrecks early-stage launches.
Category 1: Technical Readiness. Whether the application survives normal traffic and recovers from failure. Three items: monitoring and on-call rotation, backups and disaster recovery targets, and security baseline against OWASP Top 10.
Category 2: Compliance and Legal. Whether the customer can sign up without exposing the company to legal risk. Three items: privacy policy plus terms plus DPA, GDPR/HIPAA/SOC 2 posture check, cookie consent plus jurisdiction flags.
Category 3: Commercial Readiness. Whether the customer can actually pay and the payment can actually be collected. Three items: billing infrastructure and tax compliance, pricing page plus trial logic plus dunning, analytics and conversion instrumentation.
Category 4: Operational Readiness. Whether the team can support the customer after signup. Three items: support channel plus SLA plus playbook, customer onboarding and documentation, feedback loops and bug-triage process.
Each item in the saas pre-launch checklist is scored 0 (missing), 1 (partial), or 2 (complete). The total runs from 0 to 24. The launch threshold is 18/24, which gives the team room to launch with two or three known partials but blocks launch when more than half of the items are not in place.
The reason for category-based grouping rather than a flat 12-item list: launch failures cluster by category. A team that aces Technical and Commercial but skips Compliance and Operational launches into legal exposure and customer support chaos. Spreading effort across categories prevents the single-category blind spot that kills most launches.
Saas Pre-Launch Checklist Category 1: Technical Readiness
The technical readiness section of the saas pre-launch checklist covers the three items that determine whether the application survives the launch week.
Technical Item 1: Monitoring, Alerts, and On-Call Rotation
Monitoring is not optional for saas at launch. The minimum: error tracking through Sentry (free tier covers MVP-scale traffic), uptime monitoring through Better Stack or Pingdom (under $20 per month), application performance monitoring through Datadog, Highlight, or Honeybadger, all configured with alerts that route to a real human within five minutes of an incident.
The on-call rotation matters as much as the tooling. Founders who treat themselves as the only on-call person for the first month produce two outcomes: customer-visible incidents during family dinners and burnout by week four. The minimum on-call rotation at launch: two people sharing a 12-hour window each, with PagerDuty or OpsGenie routing alerts to the on-call human and escalating after five minutes if not acknowledged.
The launch-week pattern: monitor more aggressively than feels comfortable, including dashboards that the team checks every two hours during business hours. The first 72 hours of any launch surface the issues that will define customer trust for the first month.
Score: 0 if no monitoring, 1 if monitoring exists but no on-call rotation, 2 if both are configured and tested with a fake alert before launch.
Technical Item 2: Backups, Disaster Recovery, and RTO/RPO Targets
Backups are not the same as disaster recovery. A backup that has never been restored is not a backup; it is a hope. The launch-week minimum: automated daily backups of the primary database (managed cloud providers handle this by default), point-in-time recovery enabled, at least one full restore tested in a staging environment before launch, and documented Recovery Time Objective (RTO) and Recovery Point Objective (RPO) targets.
Reasonable RTO/RPO targets for early-stage saas: RTO under 4 hours (the saas can be back online within 4 hours of a catastrophic failure), RPO under 1 hour (no more than 1 hour of customer data is lost in a worst-case recovery). These targets get tighter as the saas grows; at launch, 4/1 is the floor.
The scenario the team should rehearse before launch: simulate a complete database loss, restore from backup, verify the application connects to the restored database, verify customer data is intact. Teams that skip this rehearsal discover during real incidents that their backup configuration was incomplete.
Score: 0 if no backups, 1 if backups exist but never restored, 2 if backups are tested and RTO/RPO targets are documented. The AWS Well-Architected review checklist covers the backup and recovery patterns in depth.
Technical Item 3: Security Baseline (OWASP Top 10, Dependency Audit)
The security baseline at launch covers the OWASP Top 10 vulnerabilities and a dependency audit of the application’s third-party packages. Skipping the security baseline is the single fastest path to a public security incident in the first 90 days.
The minimum security checks before launch: SQL injection prevention (parameterized queries everywhere, no string-concatenated SQL), XSS prevention (React and modern frameworks handle this by default, but custom HTML rendering needs review), authentication and session management (using a managed identity provider rather than custom auth), CSRF protection (token-based, enforced on every state-changing request), security headers (Content-Security-Policy, X-Frame-Options, Strict-Transport-Security), and dependency audit (npm audit or equivalent, no critical vulnerabilities at launch).
The OWASP Top 10 is the canonical reference, updated periodically. Teams without a security engineer should run a third-party security review or static analysis tool (Snyk, GitHub Advanced Security, Semgrep) before launch as an outside check on the team’s own work.
Score: 0 if no security review, 1 if dependency audit is clean but no application-level review, 2 if both are complete and documented.
Saas Pre-Launch Checklist Category 2: Compliance and Legal
The compliance and legal section of the saas pre-launch checklist covers the three items that determine whether the saas can collect customer signups without exposing the company to regulatory risk or customer-trust damage.
Compliance Item 1: Privacy Policy, Terms of Service, and Data Processing Agreement
The legal trio (privacy policy, terms of service, data processing agreement) is the minimum legal documentation a saas needs at launch. Each serves a distinct purpose.
Privacy policy explains what data the saas collects and how it is used, required by GDPR, CCPA, and most consumer protection regimes worldwide.
Terms of service define the contract between the saas and the user, including liability limitations, dispute resolution, and acceptable use. Without ToS, the saas has no enforceable agreement with users, which becomes a serious problem at the first dispute.
Data Processing Agreement (DPA) is the agreement between the saas (as data processor) and the customer (as data controller) that satisfies GDPR Article 28 requirements when the saas handles personal data on the customer’s behalf. B2B customers will ask for a DPA during procurement.
The right way to produce these documents: start from a reputable template (Termly, Iubenda, or law-firm templates), customize for the saas’s actual data practices, then have a qualified attorney review for the relevant jurisdictions. Templates without legal review are a starting point, not a finished product.
Score: 0 if any document is missing, 1 if templates exist but have not been customized or reviewed, 2 if all three are customized, attorney-reviewed, and linked from the saas signup flow and footer.
Compliance Item 2: GDPR / HIPAA / SOC 2 Posture Check
The compliance posture at launch depends on the saas’s customer base. GDPR is functionally non-optional for any saas with European users, which is almost all saas. HIPAA applies only when the saas processes Protected Health Information. SOC 2 Type II is a sales-cycle unlock for enterprise contracts above roughly $50K ARR; it does not need to be in place at launch unless an enterprise contract is already in negotiation.
The launch-week minimum: GDPR architecture in place (data residency, deletion-on-request, processing records), even if the formal compliance certification is not. HIPAA architecture in place if PHI is processed at any point. SOC 2 is deferred until customer contracts demand it; what should be in place at launch is the architectural foundation that lets SOC 2 be added later without rewriting (audit logs, encryption, tenant isolation).
The pragmatic interpretation for the saas pre-launch checklist: do not pursue formal certifications before launch unless contracts require them, but do put the architectural primitives in place so certifications are cheap to add later.
Score: 0 if regulatory posture is unaddressed, 1 if architecture supports compliance but documentation is incomplete, 2 if both architecture and documentation are complete for the saas’s actual customer base.
Compliance Item 3: Cookie Consent, Age Gating, and Jurisdiction Flags
The smaller compliance items that most teams skip and that quietly create regulatory exposure: cookie consent banners (required in EU and increasingly in US states), age gating (required for any saas that might serve minors, especially with new state-level child safety laws in 2024 to 2026), jurisdiction flags (the ability to detect a user’s likely jurisdiction and adjust available features, terms, or data handling accordingly).
The launch-week minimum: cookie consent banner that respects user choice and integrates with analytics tools (so users who reject tracking are not tracked), age gate at signup if the saas’s terms restrict use to adults, jurisdiction detection through IP geolocation or user-declared country selection. Tools like Cookiebot, OneTrust, or Iubenda handle the cookie consent surface affordably (under $50 per month at launch scale).
Score: 0 if these items are unaddressed, 1 if cookie consent is in place but age gating or jurisdiction flags are missing, 2 if all three are configured.
Saas Pre-Launch Checklist Category 3: Commercial Readiness
The commercial readiness section of the saas pre-launch checklist covers the three items that determine whether the saas can actually collect revenue from launch day onward.
Commercial Item 1: Billing Infrastructure and Tax Compliance
Billing is the item where most saas pre-launch checklist failures hide. The launch-week minimum: subscription billing through Stripe Billing, Paddle, or Chargebee (never custom-built), webhooks tested end-to-end (subscription created, payment succeeded, payment failed, subscription canceled, plan changed), tax handling configured for the saas’s actual sales jurisdictions (Stripe Tax for most US-and-EU saas, Paddle for cross-border simplicity).
The webhook test that catches most launch-week failures: trigger every relevant Stripe event in test mode, verify the application receives, processes, and records each event correctly, retry the events to confirm idempotency. Webhook reliability is where billing implementations break in production, and the failures often surface as quiet data inconsistency rather than loud errors.
The tax surface deserves its own attention on the saas pre-launch checklist. A saas selling in five US states needs sales tax collection in those five states; a saas selling cross-border into the EU needs VAT compliance for digital services. Stripe Tax handles most cases at $1 per transaction or 0.5 percent of revenue. Rolling tax compliance manually is the single fastest way to ship a launch that fails its first cross-border audit.
Score: 0 if billing is unconfigured or untested, 1 if billing works but tax is missing, 2 if billing is fully tested and tax is configured for actual sales jurisdictions. The Stripe Atlas launch guide covers the launch-day billing patterns in operational detail.
Commercial Item 2: Pricing Page, Trial Logic, and Dunning Flows
The pricing page is the highest-stakes single page on a saas website at launch. The launch-week minimum: pricing tiers clearly displayed, trial logic working (free trial duration, trial-to-paid conversion flow, trial expiration handling), dunning configured (Stripe Smart Retries plus an email sequence for failed payments).
Pricing tier conversion benchmarks for B2B saas: pricing-page-to-signup conversion runs 2 to 4 percent for sales-led, 0.5 to 1.5 percent for product-led growth. The middle tier captures the largest share of paid conversions when feature gating is right. Three-tier structures consistently outperform two-tier and four-tier structures.
Trial logic is where launch-week problems hide. Common failures: trial expiration that does not actually downgrade the user’s access, trial users who never see a billing prompt, trial-to-paid conversion that requires re-entering payment details (drops conversion by 30 to 50 percent), trial extensions that are not granted gracefully when customer service is asked.
Dunning is the silent revenue killer. Roughly 6 to 8 percent of recurring charges fail every month due to expired cards, insufficient funds, or fraud detection holds. Without a dunning workflow, those failures become churn. Stripe Smart Retries plus a 4-email sequence (notification, second attempt, grace period warning, cancellation notice) recovers 30 to 50 percent of failed payments.
Score: 0 if any commercial flow is broken, 1 if pricing and trial work but dunning is missing, 2 if all three are tested end-to-end before launch.
Commercial Item 3: Analytics, Attribution, and Conversion Instrumentation
The launch-week minimum for analytics: product analytics through PostHog, Mixpanel, or Amplitude (free tier covers MVP-scale traffic), attribution that tracks how users arrived (UTM parameters parsed and stored, source attribution preserved across sessions), conversion instrumentation on the key funnel events (landing page view, signup, trial start, paid conversion).
The attribution surface that most teams skip: storing the original UTM parameters on the user record at signup, not just in session storage. Without this, the team cannot answer “which channel produced our paying customers” three months after launch, which is the question that determines marketing budget allocation.
The funnel events that need instrumentation in the saas pre-launch checklist: hero CTA click, pricing page view, signup form view, signup completion, email verification, first meaningful action (often “first project created” or “first integration connected”), trial-to-paid conversion. Each event should fire reliably, with tenant_id and user_id attached, and should land in the analytics tool’s event stream.
Score: 0 if no analytics, 1 if analytics exist but attribution is incomplete, 2 if both analytics and attribution are wired with documented event names and properties.
Saas Pre-Launch Checklist Category 4: Operational Readiness
The operational readiness section of the saas pre-launch checklist covers the three items that determine whether the team can actually support customers after launch day.
Operational Item 1: Support Channel, SLAs, and Response Playbook
The support surface at launch needs three things in place: a single official support channel (email, in-app chat, or both, never personal Gmail), documented SLA targets that the team can actually meet, and a response playbook that defines what counts as critical, urgent, and routine.
The minimum support channel at launch: a dedicated support email (support@yoursaas.com) routing into a help desk tool (Front, Help Scout, Plain) or even a shared inbox tool (Gmail’s shared inbox features), with response time targets visible to the team.
Reasonable SLA targets for early-stage saas: 4-hour first response for critical issues during business hours, 24-hour first response for routine issues, 72-hour resolution for non-blocking bugs. These targets get tighter as the saas grows; at launch, they are the floor.
The response playbook addresses what happens when an incident arrives. Critical: production is down or data is at risk, page the on-call engineer, post status updates every 30 minutes. Urgent: customer cannot use a key feature, respond within 4 hours, escalate within 24. Routine: feature requests, configuration questions, low-priority bugs, respond within 24 hours, batch into product backlog.
Score: 0 if no support channel, 1 if a channel exists but no SLAs or playbook, 2 if all three are documented and the team has done a dry run.
Operational Item 2: Customer Onboarding and Documentation
The onboarding surface determines whether new customers reach activation. The launch-week minimum: an onboarding flow that walks the user through the first meaningful action (creating their first project, connecting their first integration, inviting their first teammate), in-product tooltips for key features, a documentation site (or even a Notion page) with answers to the most likely first-month questions.
Activation rate benchmarks: B2B saas at launch typically sees 40 to 60 percent of signups reach the first meaningful action. Below 40 percent, the onboarding is broken. Above 70 percent at launch is unusually good and usually means the activation event is set too low (e.g., counted as “logged in once” rather than a substantive action).
Documentation does not need to be exhaustive at launch. The minimum: 10 to 20 articles covering setup, the most-used features, common errors, and billing FAQs. Help-desk tools like Intercom, HelpScout, and Plain include knowledge base features that double as documentation.
Score: 0 if no onboarding flow or documentation, 1 if either exists, 2 if both are in place. The realistic week-by-week buildup of these surfaces alongside the saas pre-launch checklist work is covered at the saas mvp timeline.
Operational Item 3: Feedback Loops and Bug-Triage Process
The feedback loop catches problems before they become customer churn. The launch-week minimum: a feedback collection mechanism (in-product feedback widget, post-onboarding survey, or NPS prompt at the right moment), a bug-tracking system (Linear, GitHub Issues, Jira) connected to the support channel, and a weekly triage cadence where the team reviews incoming feedback and prioritizes responses.
The pattern that matters: every customer feedback item enters a single queue, gets categorized (bug, feature request, question, churn risk), and gets a response within the SLA. Items that are not bugs get a thoughtful response or a roadmap link; bugs get reproduced, prioritized, and assigned. Founders who skip this loop ship a launch that produces feedback the team never reads.
The bug-triage cadence at launch: daily during week 1, every other day during weeks 2 to 4, weekly thereafter. The first 30 days surface 80 percent of the bugs that will define customer experience for the first 6 months.
Score: 0 if no feedback mechanism, 1 if feedback is collected but not triaged, 2 if feedback flows into a tracked queue with documented triage cadence.
The 12-Point Launch Readiness Score: Your Saas Pre-Launch Checklist Framework
The 12-Point Launch Readiness Score is the framework that turns the saas pre-launch checklist from a list into a decision tool. Twelve items, scored 0/1/2, totaled out of 24.
The scoring rules:
0 (missing). The item is unaddressed. No monitoring exists, no privacy policy, no dunning workflow. Each missing item is a launch failure mode.
1 (partial). The item exists in some form but is incomplete. Monitoring is set up but no on-call rotation. Privacy policy exists but is not attorney-reviewed. Billing works but tax is not configured.
2 (complete). The item is in place, tested, and documented. Monitoring is wired with on-call. Privacy policy is reviewed and linked. Billing is fully tested with tax configured.
The 18/24 launch threshold is calibrated against observed launch outcomes: launches with scores below 18 produced customer-visible incidents in the first 30 days at roughly 3 times the rate of launches above 18. The threshold leaves room for two or three known partials (which is realistic for early-stage launches) but blocks launches with more than half of items unaddressed.
The team uses the saas pre-launch checklist Score in three ways. First, as a launch gate: do not press the launch button if the score is below 18. Second, as a triage tool: identify the lowest-scoring categories and direct effort there. Third, as a post-launch tracking tool: re-score after 30 days to identify items that drifted from “launch-ready” to “in need of attention” as the saas grows.
The downloadable Launch Readiness Score template is included at the end of this article, with worksheet rows for each of the 12 items, scoring guidance, and category-level rollups.
The 48-Hour Soft Launch Protocol After Your Saas Pre-Launch Checklist
A soft launch is the 48-hour period before public launch where the saas is opened to a small, controlled group of users (typically 10 to 50 invited beta users or pre-sell customers). The soft launch surfaces problems the saas pre-launch checklist could not predict, because real users find issues that internal testing misses.
The 48-hour soft launch protocol:
Hour 0 to 4 (controlled rollout). Open access to 5 to 10 users. The team monitors error rates, billing webhooks, signup completion, and first-action completion. The on-call engineer is fully attentive. Any non-critical issue gets logged but not necessarily fixed in real time.
Hour 4 to 12 (broaden to 25 users). Open to 25 users. Watch for patterns: the same error appearing across multiple users (architectural bug, fix immediately), feedback that the same step in onboarding is confusing (UX bug, fix in batch), single-user issues that look like one-offs (log and continue).
Hour 12 to 24 (broaden to 50 users). Open to the full soft-launch cohort. Continue watching the same patterns. The team should have at least one customer support response cycle complete by hour 24, with response times measured against SLA.
Hour 24 to 48 (stabilization). Fix the patterns surfaced in hours 0 to 24. Document the issues for post-launch retrospective. Re-run the saas pre-launch checklist scoring; the score should be the same or higher than at hour 0.
Hour 48 (decision). Public launch or delay. Public launch only if the soft launch produced no critical issues, billing webhooks fired correctly across at least 5 paying signups, support response times met SLA, and the Launch Readiness Score remains above 18/24.
The discipline of the soft launch is its constrained scale. A 50-user cohort lets the team observe patterns without being overwhelmed by support volume. Founders who skip the soft launch and go directly to public launch handle the same issues at 10 to 100 times the volume, often poorly.
What to Do If Your Saas Pre-Launch Checklist Score Falls Below 18/24
A score below 18/24 on the saas pre-launch checklist is a clear signal: delay the launch and address the gaps. The right response depends on which items are scoring low.
If Technical readiness is the gap (category total below 4/6): delay launch by 1 to 2 weeks while the team installs monitoring, tests backups, and runs a security review. Technical gaps are the cheapest to fix because they are mostly wiring work.
If Compliance is the gap: delay launch by 2 to 4 weeks while attorney review and architecture work complete. Compliance gaps are the most expensive to fix post-launch because they involve legal and regulatory risk.
If Commercial is the gap: delay launch by 1 to 3 weeks while billing, dunning, and analytics are wired. Commercial gaps directly affect revenue and are second only to compliance in importance.
If Operational is the gap: delay launch by 1 to 2 weeks while support, onboarding, and feedback loops are documented. Operational gaps produce customer-trust damage but are usually solvable with process work rather than engineering.
The corrective action that matters more than the delay: track the gap with a hard deadline and a named owner. “We will fix monitoring by next Friday” with a calendar invite, an owner, and a re-scoring meeting beats “we will fix monitoring soon” by the typical multi-week delay.
The honest counter-argument: some founders delay indefinitely, treating the saas pre-launch checklist as a perfectionism enabler. The right framing: 18/24 is the threshold to launch, not the score to optimize toward. A score of 19/24 with three known partials is a healthy launch; a score of 22/24 reached after 8 weeks of polish is over-investment that should have been invested in customer acquisition. For the broader build framework that places this trade-off in context, see how to build a saas in 2026. For the deeper post-launch question of when product-market fit is reached, see finding saas product-market fit.
Conclusion: Master the Saas Pre-Launch Checklist Before You Ship
The saas pre-launch checklist organizes 12 critical items into 4 categories, scored against a 24-point Launch Readiness Score. The 18/24 threshold separates “launch now” from “delay and fix.” The 48-hour soft launch protocol surfaces issues at controlled scale before public launch makes them expensive. The corrective actions when the score is low are concrete and time-bound, not vague.
The dominant pattern across saas launches in 2026: teams that score and address the saas pre-launch checklist disciplinedly produce launches that survive the first 30 days. Teams that skip the saas pre-launch checklist produce launches that consume the next 90 days in firefighting, customer-trust damage, and rework.
Saas Pre-Launch Checklist FAQ
1. How long should pre-launch QA take?
For an MVP scoped through the saas pre-launch checklist, dedicated QA before launch runs 1 to 2 weeks. The first week covers technical and commercial readiness (monitoring, backups, billing, dunning end-to-end testing). The second week covers compliance and operational readiness (legal review, support playbooks, onboarding walkthrough). Adding a 48-hour soft launch on top of that brings total pre-launch hardening to 2.5 to 3 weeks. Skipping this period is the most common cause of broken launches.
2. Do I need a legal review before launch?
Yes for the legal trio (privacy policy, terms of service, DPA). Templates without legal review are a starting point, not a finished product. Cost for an attorney review: $1,500 to $5,000 for US-only operation, $3,000 to $10,000 for cross-border. The cost of skipping the review is significantly higher when the first dispute, breach, or B2B customer asks for a customized DPA.
3. Should I launch with annual or monthly billing?
Both, but monthly is the default and annual is the upsell. The pricing page should display monthly prices prominently with an annual toggle that shows a 10 to 20 percent discount. Annual billing improves cash flow and reduces churn, but launching monthly-first lets early customers test the saas without large commitment, which improves trial-to-paid conversion at the launch stage.
4. What is the minimum monitoring setup on day 1?
Sentry for error tracking, Better Stack or Pingdom for uptime, plus alerts that route to the on-call engineer within 5 minutes. Total cost: under $50 per month at MVP scale. Skipping any one of these means the team learns about issues from customers rather than from monitoring, which damages trust and slows incident response.
5. How do I handle a critical bug in the first 48 hours?
Roll back if the bug affects all users. Communicate proactively to affected customers within 30 minutes of detection (status page update plus email). Fix as quickly as possible, with a post-mortem within 7 days. Critical bugs in the first 48 hours are common; how the team handles them defines customer trust for the first 6 months.
6. Soft launch or public launch first?
Always soft launch first. The soft launch with 10 to 50 invited users surfaces problems at a manageable scale; the public launch surfaces the same problems at 10 to 100 times the volume. Skipping the soft launch saves a few days and costs weeks of post-launch firefighting. The discipline is non-negotiable for any team that has not launched 3+ saas products before.
