Use case · SaaS
Production-grade B2B SaaS, out of the box.
Multi-tenant auth, billing, an operator console, and the jobs and observability behind it. The four sub-systems a SaaS needs are wired into the registry before your first commit.
What's in the box
The four sub-systems every SaaS needs.
Twelve capabilities grouped by the buyer-side question they answer. Pick a cluster, read what you actually get, and ship it.
Auth & identity
Who signs up, who pays, who is who. The four walls your customer data lives inside.
Workspace creation
The signup form captures the workspace name, not just the user. Email verification uses the same provider the rest of your app already talks to, so a stray typo never opens a tenant in your org. Welcome mail sends before the dashboard renders, with the right slug pre-filled.
Multi-tenant by default
Every session is scoped to a workspace. Switching workspaces doesn't sign the user out — it filters what they see. Org-level roles travel with the workspace, not the user, so a freelancer leaving the team doesn't take the customer list with them.
Magic links + OAuth
Better Auth under the hood, with magic links, email+password, and six OAuth providers pre-wired. The proxy verifies email at signup so your Enterprise tier isn't selling to fake at gmail.
auth-identity
- Workspace createdacme.deessejs.app
- Verify your emailToken sent to ops@acme.com
- Invite your teamalice@…bob@…carol@…
Billing & growth
How the money comes in, how the customer stays. The plumbing that pays for the rest.
Subscriptions that scale
Stripe subscriptions with plans, proration, and dunning wired against the same contract your database reads. Customer portal is generated, not built — your users see invoices and change plans without a support ticket.
Usage metering
Charge per API call, per seat, per GB — whatever your product actually sells. The metering shape matches the contract your app code reads, so you never reconcile two sources of truth at month end.
Customer notifications
Receipts, renewal warnings, and dunning sequences run on the same mail and queue layer as the rest of your app. No second vendor, no second dashboard to monitor.
billing-growth
Pro Plan$49/mo
74%
7,423 / 10,000MRR $1,127
Operator console
What you see of your users — the surface that keeps the team out of the database.
Admin dashboard
MRR, active users, churn at a glance. The user table is filtered by role and shows last-seen. Bulk actions hit the same RPC the customer API uses, so the operator console and the customer surface never drift.
Audit trail
Every cross-org call is recorded with the actor, the action, and the resource. Buyers in regulated verticals audit this in the first call; you don't have to explain what 'comprehensive logging' looks like.
Domain data + search
The CRUD layer on top of your Drizzle schema, with search and CSV export. Operators do not poke the database to find a customer; they use the same surface your support team uses.
operator-console
MRR$11,270+8.2%
Active users1,420+112 / wk
Churn1.4%-0.3 pt
Users5 rows
- Ssarah@acme.ioownernow
- Eeric@acme.ioadmin2m ago
- Ddidier@acme.iomember12m ago
- Llena@acme.ioadmin1h ago
- Aandreas@acme.iomemberyesterday
Background work
The work your users never see — but that holds the product together when it scales.
Background jobs
Queues and retries wired against the same contract the rest of the app uses. Failed jobs are visible in the same dashboard; retries are typed, not free-form shell scripts.
Observability
OpenTelemetry waterfall shows every job, every RPC call, every email send, on the same dashboard as your HTTP routes. Errors are tagged with the tool name and the call site, so a 500 in production has a runtime.
Scheduled tasks
Cron-style tasks live in the same registry as the rest of your code. They read the same schema, log to the same trace, fail with the same retry policy.
background-work
Queue · 3 workersrecent
- j_8a3fsend_welcome_email×1ok 182ms
- j_8b2csync_stripe_customer×1ok 412ms
- j_8c11issue_invite_token×1···
- j_8d4erender_invoice_pdf×2retry
- j_8f9apurge_old_sessions×1ok 71ms
Stack
What runs on day one.
Next.js
Better Auth
Drizzle
Postgres
Stripe
Resend
Process
How a SaaS ships.
- Step 01
Scaffold the stack
Run the CLI. The contracts are wired before the first file is generated. Multi-tenant boundaries, rate limiting, and transactional email come preconfigured.
- Step 02
Wire your domain
Replace the placeholder with the product. The eight capabilities stay stable, so the surface you ship to customers is the only thing that changes.
- Step 03
Ship to your first customer
Auth, billing, jobs, and observability are already in place. Your time goes into the part of the product that customers actually see.
Built on this
Four templates, each on its own surface.
Production-ready starter templates, each deployed at its own URL. Used as the reference set for what the registry can ship.
Explore
Related use cases.
Related
Internal tools
Operator consoles that work behind SSO, on the same auth and contracts as your customer app.
Read more
Related
API backends
Service-only backends with type-safe RPC and zero frontend overhead.
Read more
Related
AI products
RAG, chat, and agents wired against the same contracts your app uses.
Read more
Two doors
Use it yourself, or have us ship it for you.
Self-serve gives you the registry and the templates. Engagement gives you the team that built it. Pick the door that fits the timeline.