SaaS Stack

Roadmap

What is coming to SaaS Stack

The next features, in the order they will ship. Each one lands with docs, tests and upgrade notes, and founders get every one of them.

v2.3.0 shipped October 26, 2026. See what is included.

  1. 01Polar payments

    Shipped
    • Polar or Stripe, chosen with one setting; plans stay declared once in the contracts
    • Plans synced to Polar, with flat or per-seat pricing
    • Checkout and the customer portal through Polar
    • Idempotent webhook handling, writing the same subscription records as Stripe's
    • Plan-gated features unchanged in the API, the web app and the mobile app
    • Run against Polar's sandbox, then live
  2. 02Usage-based billing

    Shipped
    • Metered prices declared on a plan in the contracts: an allowance, then a price per unit
    • Usage recorded with one call from any module, through the job queue so none is lost
    • Reported to Stripe's meters or Polar's, whichever provider is set
    • Usage against the allowance this period, in the web app and the mobile app
    • The AI assistant metered per message, as the example
  3. 03API keys

    Shipped
    • Keys owned by a workspace, with a role, a name and an optional expiry
    • Created, listed and revoked by admins in the workspace's settings, each shown once
    • Stored as a hash, recognisable by a short prefix, with the time each was last used
    • Accepted by every workspace route as Authorization: Bearer, under the same role and plan checks as a session
    • A rate limit per key, an audit entry for each one created or revoked, and API calls countable as usage
  4. 04Observability

    Shipped
    • Traces across the API, the job queue and the database, through OpenTelemetry
    • Metrics: request rates and latency, job throughput and failures, queue depth
    • Sent to any OpenTelemetry backend with one variable, and off when it is not set
  5. 05Product analytics

    Shipped
    • Events named once in the contracts, sent from the API, the web app and the mobile app
    • People identified on sign-in and grouped by workspace
    • One provider wired, and an interface for others; off when no key is set
  6. 06Error reporting

    Shipped
    • Unhandled errors from the API, the web app and the mobile app, with the user and the request
    • Source maps and releases, so errors point at the real line in the version that threw them
    • Off when no key is set; errors never include passwords, tokens or cookies
  7. 07Prisma and TypeORM

    Shipped
    • Drizzle, Prisma or TypeORM, chosen once with one setting; Drizzle stays the default
    • The kit's modules read and write through a repository interface, with an implementation per ORM, as billing does through PaymentProvider
    • Transactions that every module joins without being handed them, in place of tx options
    • Tables declared for each ORM, checked against each other in CI so they cannot drift apart
    • Migrations made by the ORM that is set, and applied in production without its CLI, safe for a running production as they are now
    • Better Auth, the job queue and the audit log unchanged with each
    • The whole API test suite run against all three in CI
    • The skills and docs write new resources and migrations for the ORM that is set
  8. 08Redis

    Shipped
    • Redis as a service: in Docker Compose locally, on Railway in production, and checked by the health check and deploy:check
    • The job queue on BullMQ, with defineJob, @OnJob, @Scheduled and enqueue unchanged for the code that uses them
    • Jobs still queued only when their transaction commits, and still once per key
    • Jobs waiting in the Postgres queue moved across on upgrade, so none is lost
    • WebSockets that work across any number of API instances, through Redis streams: events from the server or a client reach every connected client
    • The assistant's answers kept in a Redis stream as they arrive, so a closed tab or a dropped connection picks the conversation back up
    • Rate limits shared by every instance of the API
    • A cache ready for your own features, with keys scoped to the workspace so one can never read another's
  9. 09Notifications

    Shipped
    • Notifications for one person, from any module with one call: stored, so nothing is missed while they are away
    • A bell in the web app and a list in the mobile app, with unread counts, marking as read, and a link to what each is about
    • Each one also sent to their phone or by email when it should be, and a page where people choose which they get where
    • System events for one person: not shown or stored, sent to their open apps only, for "look again" or "your export is ready"
    • Delivered live across every instance of the API, through the realtime connection that exists
    • Tests, browser journeys and docs, as for every milestone
  10. 10PostHog

    Shipped
    • PostHog as a second analytics provider beside Mixpanel, chosen with one setting: the same events, named once in the contracts
    • In the API, the web app and the mobile app, each behind the wrapper that exists, so no feature changes
    • US or EU cloud, or your own PostHog, by its address
    • Events filed under the workspace, as with Mixpanel, for group analytics
    • Tests and docs, and a page on choosing between the two
  11. 11Deploy anywhere

    Shipped
    • Railway stays the default; the deploy described once, apart from any host: the images, the services, the variables, migrations and health checks
    • AWS from one command: ECS on Fargate behind a load balancer, RDS for Postgres, ElastiCache for Redis, declared as code
    • Secrets and variables from each host's own store, checked by deploy:check before anything is deployed
    • Migrations on deploy and health checks on every host, safe for a running production as they are now
    • A guide for adding another host, and a skill that follows it

Hear when each one ships

A short email when a milestone lands, with what changed and how to take it into your product.

The same posts as the updates page. Unsubscribe with one click.