Production-ready vs demo-ready: the 7 systems every SaaS needs before launch

There's a version of your SaaS that works in a demo. It handles the happy path. It looks good in a screen recording. It's enough to close early customers — and that's valuable. But between 'works in a demo' and 'runs a business' there's a substantial gap, and it's filled by infrastructure that most developers don't think about until something breaks in production.

1. Auth — beyond username and password

Production auth means: JWT with proper refresh token rotation, social login (Google, GitHub at minimum), MFA via TOTP or SMS, session management with device tracking, and role-based access control that can be extended without a schema change. A login form is not auth.

2. Billing — Stripe is not enough

The Stripe integration is the easy part. The hard part is webhook handling — idempotent processing, signature verification, retry handling. Failed payment recovery with grace periods and dunning. Proration when customers change plans mid-cycle. Subscription state that stays in sync with your database when webhooks arrive out of order.

3. Background jobs — the outbox pattern

Any task that shouldn't block an HTTP response — sending email, processing a file, calling a third-party API — belongs in a background job. The critical detail: the job must be enqueued in the same database transaction as the event that triggered it (the outbox pattern), or you'll have silent data loss when things fail between the commit and the enqueue.

4. Email — delivery is not guaranteed

Template rendering that works consistently across email clients. Delivery via a real transactional provider (SendGrid, SES, Postmark) with bounce and complaint handling. Fallback SMTP for development. Unsubscribe handling that keeps you CAN-SPAM and GDPR compliant.

5. Feature flags — deploy without releasing

Feature flags let you deploy code to production without activating it for users. This decouples deployment from release, which is fundamental to a low-risk deployment pipeline. You need rollout percentages, per-user targeting, and a global kill switch.

6. Audit logs — who did what and when

Enterprise customers will ask for this. Compliance frameworks require it. An immutable log of significant actions (who created, modified, or deleted what) with timestamps, IP addresses, and user agents. Build it in from the start — retrofitting it is painful.

7. Observability — knowing when things break

Structured logging (not Console.WriteLine), error tracking with stack traces and context (Sentry, Bugsnag), and performance monitoring with enough detail to diagnose a slow query at 2am. Without observability, you're flying blind in production.

Related posts

Apr 2026

Why your Lovable MVP will need a rebuild (and how to avoid it)

Read →

Mar 2026

Multi-tenancy in .NET: what it actually takes to do it right

Read →

Feb 2026

How we load-tested to 458 req/s on a €20/month VPS

Read →