Architecture

Nine production systems with clear boundaries, one default provider per category, and documented swap paths. Built for scaling and replaceability — no hidden coupling, no lock-in.

Default stack

We ship one recommended default per system so you get a working, production-ready setup out of the box. Each is behind an interface so you can swap when your needs or compliance require it.

  • Identity & Access: Better Auth — sessions, RBAC, workspace and team management
  • Revenue & Billing: Dodo Payments — subscriptions, metered usage, ledger, webhooks
  • Notification Delivery: Resend for email; abstracted SMS and in-app
  • Workflow Engine: Trigger.dev — background jobs, retries, idempotency, dashboard
  • Observability & Monitoring: PostHog for product analytics, Sentry for errors and performance
  • Marketing and SEO: FumaDocs — docs and blog from MD/MDX
  • Media Storage: ImageKit — upload, storage, delivery, optional transforms
  • Testing: Playwright E2E — auth, billing, tenant isolation coverage
  • Operational Safety Layer: Feature flags, circuit breakers, runbooks, impersonation, audit log

System diagram

How the nine production systems relate. Data flows and APIs are defined at boundaries; each box can be scaled or replaced independently.

Identity & Access
Revenue & Billing
Notification Delivery
Workflow Engine
Observability & Monitoring
Marketing and SEO
Media Storage
Testing
Operational Safety Layer

Nine production systems. Each box is a clear boundary with a documented swap path.

Boundaries

Each system exposes a well-defined API and owns its data. Cross-system calls go through these boundaries — no hidden coupling. You can reason about failure domains, scale hot paths (e.g. workflow workers or notification senders), and replace one system without rewriting the rest.

  • Identity: sessions, roles, tenant context, usage tracking for billing
  • Billing: state machine, subscriptions, usage, ledger, grace periods, threshold alerts
  • Notifications: email, SMS, in-app; templates, delivery state, preferences
  • Workflows: job queue, retries, dead-letter, idempotency
  • Observability: logs, metrics, traces; PostHog and Sentry correlated by user/session
  • Marketing and SEO: docs, blog, landing pages, meta and sitemap
  • Media: upload, storage, delivery, tenant-scoped paths
  • Testing: E2E, billing and isolation tests, mocking patterns
  • Operational safety: kill switches, circuit breakers, runbooks, impersonation, audit, export and deletion

Scaling strategy

We scale by system. Stateless APIs scale horizontally; queues and workers (e.g. Trigger.dev) scale by throughput. Database access is scoped per tenant so multi-tenancy stays safe. The architecture avoids single bottlenecks and allows you to scale what's hot (e.g. workflow workers or notification senders) without rewriting the rest.

Replaceability and removal strategy

Every system is built so it can be swapped or removed without taking down the rest. Boundaries are contracts: implement the same interface elsewhere and you can migrate. We document removal and migration paths so you're not locked in — and so you can evolve one system at a time.

Go deeper
Each system has its own page with implementation details, state machines, and failure modes.
View all systems
xs