B2B SaaS without orgs is a toy store with one cash register.
Organizations, members, invites, and role gates so Harbor-style auth can grow into workspace tenancy.
~713 words · field guide
If everyone is an admin, no one is an admin — they’re just loud.
Single-tenant lies
- One big user table forever.
- Invites via Slack DMs.
- Admin who is also every customer.
The shape of the solution
Org store with invite/accept/require_role. In-memory first; Postgres later.
- Create org
- Invites
- Accept + roles
- FastAPI routes
What's in the download
- orgs.py
- app.py
- verify
- LICENSE
What Multi-Tenant Orgs Kit is for (and what it isn’t)
Multi-Tenant Orgs Kit lives in the SaaS · orgs lane. It’s a downloadable workshop folder — code you unzip, run in mock mode, and adapt — not a hosted product with seats, SLAs, or a customer success manager named Chad.
In plain terms: Org store with invite/accept/require_role. In-memory first; Postgres later.
If you came here for a soft-focus brand story about ‘empowering data journeys,’ you’re in the wrong harbor. This is notes from people who got tired of rebuilding the same bridge on every engagement.
The Tuesday-afternoon version of the problem
These kits start on a Tuesday afternoon. Someone asks for a ‘thin wrapper’ or a ‘quick sync.’ Three weeks later you’re debugging pagination while Slack blinks like a smoke alarm.
For this one, the pain usually shows up as: (1) One big user table forever. (2) Invites via Slack DMs. (3) Admin who is also every customer.
If everyone is an admin, no one is an admin — they’re just loud.
Tenancy is a product
Workspaces aren’t a nice-to-have for B2B. They’re the product.
Invite flows age well
You’ll rewrite UI. Keep the org model boring.
How to evaluate it without vibes
Open the README. Copy .env.example. Run the verify script or mock path. You want a boring green signal that the contract works. Flashy demos that only run on the author’s laptop are how ‘kits’ earned a bad name.
Then read the modules like a colleague’s PR. If the structure looks reusable, keep going. If it feels like generated goo, close the tab — life’s short.
You’ll see pieces aimed at: Create org; Invites; Accept + roles; FastAPI routes.
A realistic first week (no hero montage)
Day 0: unzip, skim the license, run verify/mock. Day 1: point env vars at non-prod credentials if you have them. Day 2: hang it behind ADF, your app, or cron — depending on what this kit is — and watch one happy path.
Day 3 is when you stop treating it like a demo: logging, retries, secrets in a real secret store, and the inevitable ‘can we also support X?’ You own the code. Extend it. That’s the whole point of a workshop asset versus renting another logo.
If your process requires a design doc before a Dockerfile, paste the architecture from this page into the doc and skip inventing folklore from Slack threads.
Where the jokes stop
Humor is here so the page isn’t a funeral. It is not a substitute for signature checks, pagination, role gates, or private networks. If you smirked and skipped verify, that’s on both of us.
Checklist: secrets out of git, mock before prod, verify in CI if you can. The ZIP is the workshop. This page is the field notes.
Dark Lighthouse is a consulting alias with a product habit — reusable bridges because rewriting them from scratch was getting old.
Where it fits
Multi-Tenant Orgs Kit is aimed at data, platform, or SaaS engineers who recognize the pain bullets above and want a deployable starting point instead of a six-week inventing contest.
It won’t replace a fully managed sync, a white-glove marketplace app, or a promise that vendors never change APIs. Sharp tools, not frozen oceans.
Wrap-up
That’s the field notes for Multi-Tenant Orgs Kit. Next step is the ZIP and the verify script — not another meeting. Questions: admin@darklighthousesolutions.com.
More bridges in the same style live on the kit guides index.
FAQ
Auth provider?
Bring sessions; we model tenancy.
SSO?
Later — start with the data model.
Download on Polar if you want the ZIP · All guides