Organisations, members and roles
The schema is an afternoon. The part that takes the month is every query afterwards remembering to filter by organisation, and the day you find one that did not.
How it works here Compare
Build it yourself, or start from this
The question is not whether you could write all of this. You could. The question is what the first month costs you, and whether the thing you build in it is the thing anyone is paying you for. Here is the work, when doing it yourself is the right call, and what you give up by taking a copy instead.
The platform work, and the part people underestimate
None of this is hard. All of it is slow, and none of it is your product.
Sign-in
One provider is a morning. Then you want a second, and email links for people without either, and API keys for scripts, and sessions you can revoke.
How it works hereInvitations and an admin area
Invite, accept, expire, resend, and what happens when someone accepts an invitation for an email that already has an account. Nobody plans for that one.
How it works hereBackground work
A queue is easy until a message is poison and retries forever, or a job runs twice because nothing claimed it.
How it works hereAn AI layer that is not a demo
Streaming a reply is a day. Persisting it, keeping a thread inside a context window, letting an agent stop and ask a person, knowing what it all cost, and knowing whether this week’s prompt is worse than last week’s, is not.
How it works hereDashboards
The first chart is quick. The tenth is a reporting system, and by then the same measure is defined three times and disagrees with itself.
How it works hereConnecting a customer’s Microsoft 365
Admin consent is a redirect. Keeping a change token per calendar, backing off when Microsoft throttles you, starting over when a token expires, and making sure nobody reads a colleague’s calendar — that is the quarter.
How it works here Be honest with yourself
When writing it yourself is the right call
- Your product is not shaped like organisations with members. A consumer app, a marketplace, a single-user tool: the model here will fight you.
- You have a stack you are fast in and no appetite for Cloudflare Workers, Hono or Drizzle. Being fast in your own tools beats any head start.
- You need one or two of these parts, not all of them. A starter kit is a poor way to get an auth page.
- The platform work is the interesting bit for you. That is a real reason and there is nothing wrong with it.
If two of those are true, close this page and go and build. A starter kit you spend a week fighting has cost you more than it saved.
Three things that are different here
Most SaaS starter kits are a Next.js app with a hosted auth vendor and Stripe already wired in. They are good at what they do. These are the places this one diverges.
Multi-tenancy is the foundation, not a feature
Most kits add organisations on top of a single-user app. Here every row belongs to one, a single setting switches between one organisation and a thousand with no migration, and a test fails if a query forgets. The isolation is enforced rather than remembered.
The AI layer is built in and works with no key
Chat, agents that can stop and ask a person, and search over your own documents are part of the kit rather than a tutorial. On a fresh copy they run on Workers AI with nothing configured, and you can point them at your own provider later.
A copy keeps a link home
You delete the kit’s history on the first day, so there is nothing to merge and no upstream to fight. What stays is a small file saying which version you came from. When the kit gains a release, one command ports it into your renamed app and skips anything you deleted. Starting from a template does not have to mean falling behind it.
Side by side
| Topic | Writing it yourself | Starting from Rocketflare |
|---|---|---|
| Time before your first real feature | Weeks, and the boring weeks | About two minutes to a running app |
| Multi-tenancy | Yours to design, and to keep right in every query | Built in, with a test that fails when a query forgets |
| AI over your own documents | A project of its own | Built in, no key needed to try it |
| Knowing whether the AI got worse | Try a few questions after each change and hope | Eval suites with baselines and a regression check |
| Single sign-on with a company’s identity provider | An OIDC client, token checks and account linking of your own | Any OIDC issuer — Okta, Entra ID, Keycloak, Auth0 — from a few settings |
| Your customers’ Microsoft 365 | An app registration, a consent flow and a sync engine of your own | Two plugins: one admin consent, then directory and calendars sync by delta |
| Billing and subscriptions | Yours, whenever you want it | Not included. Add Stripe yourself |
| Stack choice | Anything you like | Cloudflare Workers, Hono, React, Postgres |
| Who owns the decisions | You, all of them | You inherit a few hundred, written down so you can reverse them |
What you give up
Three of them, stated plainly, because you will meet all three.
-
Someone else's decisions
You inherit a few hundred choices you did not make. They are written down with the reasoning, one page per part of the app, so you can disagree on purpose rather than by accident. But they are there on day one.
-
A stack you may not have picked
One Cloudflare Worker over Postgres, with Hono and React. If you want to run this on a Node server in a container, this is the wrong starting point and there is no second target for it.
-
Reading code you did not write
A copy is yours from the first commit, which also means every bug in it is yours. The tests and the written reasoning exist to make that survivable, and it is still real work.