SaaS Founder's Guide

The launch tooling stack

Chapter — the operations tooling a SaaS needs on day one, what to get free or open-source, and what to skip until it hurts.

Ship the product, then get hit by questions you have no tools for: where do feature requests go? where do bugs go? how does a user reach a human? You don't need a big stack — you need one analytics tool that does five jobs, a human-monitored inbox, and a place where bugs are written down.

The principle: integrated while small, standalone when it hurts

Early on, every tool is a surface to configure and a bill to remember. Favor one provider covering many jobs while volume is low, and keep exactly one thing standalone: the support inbox (a human reading mail — no SaaS needed). Graduate to dedicated tools only when a capability outgrows the bundle — and let usage data, not tool envy, make that call.

The checklist

#CapabilityWhy it matters on day oneFree / low-cost pickIntegrate or standalone
1Product + web analyticsKnow which pages convert and which features get usedPostHog free tier (1M events/mo)Integrated (SDK)
2Session replaySee the bug the user described in their wordsPostHog replay (5k sessions/mo free, hard-stopped)Integrated (same SDK)
3Error / exception trackingUsers often won't report crashes; they just leaveClient: PostHog exception events + Error tracking. Server: your host's runtime logs; add Sentry free tier when volume justifiesIntegrated (client); standalone (server, later)
4Surveys — NPS / CSATThe only honest "would you pay / would you recommend" signalPostHog surveys (free)Integrated (same SDK)
5Feature request boardTurns "you should..." into a ranked list you can point atPostHog hosted-link survey — no code at all. Alternatives: Featurebase free tier, Fider (self-host OSS), Canny ($$$)Standalone URL (footer link)
6Help desk / reach a humanOne unanswerable email to a real address burns more trust than ten bugsShared inbox on your domain via email routing (Cloudflare/Resend) — $0. Add Crisp (free live chat) or Chatwoot (self-host OSS) when volume demandsStandalone by design
7Knowledge base / docsDeflects tickets before they exist; also your SEO surfaceFumadocs / Nextra / Docusaurus — static, self-hosted, $0 hostingIntegrated (own Next.js)
8Transactional emailSignup, password reset, billing receipts must arriveResend free tier (3k emails/mo)Integrated (API)
9Lifecycle / onboarding emailTrials die quietly without nudges; winbacks recover themSame provider as #8 + a cronIntegrated
10Billing & subscriptionsThe product must be able to chargeClerk Billing (Stripe-powered) or Stripe + a meterIntegrated
11Internal bug/task trackingBugs that aren't written down are wished awayGitHub Issues + Projects (free with the repo) or Linear free tierStandalone (your repo)
12Feature flags / A-B testsShip dark, flip gradually, roll back without a deployPostHog feature flags (free)Integrated (same SDK)
13Uptime monitoring + status pageYou learn about downtime from users — or from a monitorUptimeRobot / Better Stack free monitors; hosted status page free tiersStandalone
14Public changelog / announcements"We ship every week" is retention; silence reads as abandonmentFeaturebase free tier (also folds in #5), or a changelog route you ownStandalone or integrated route
15Live chat widgetHuman answer in 30 seconds converts trialsCrisp free / Chatwoot OSSStandalone snippet
16AI observability (if AI features)LLM cost + latency + quality are invisible otherwiseLangfuse free tier / OSSIntegrated (API)
17Community homeWhere your ten first users talk to each otherSkool / Discord / r/YourSaaSStandalone

What we'd do in order (and did)

  1. Analytics first — one PostHog project covers #1, 2, 3-client, 4, 5, 12. Install once; every later decision gets evidence.
  2. The inbox and docs — costs $0 and answers 80% of day-one friction.
  3. Lifecycle email — set up before launch traffic, not after trials start dying.
  4. Only then dedicated tools — a status page when you have uptime worth reporting, a changelog when you have ships worth announcing, live chat when the inbox can't keep up.

Survey targeting: the gotcha that bites everyone

Surveys run per person, and a visitor on your marketing site is usually a different person than the same human logged into your app (anonymous ID vs. identified ID). Scope satisfaction surveys to the app host only via a URL condition — you want sentiment from activated users, not drive-by traffic — or your NPS popup will chase anonymous visitors around the marketing pages forever.

Where this ties into the product

This checklist is what SaaS Founder OS operationalizes: experiments and decisions logged with rationale (#11's discipline), economics that tell you when a paid tool earns its keep, and the playbook stage that forces the "go-to-market" answer before you build. The tooling is cheap; the habit of reading what it tells you is the product.