I finally finished the B2B SaaS foundation I kept rebuilding
After rebuilding the same pieces across multiple B2B SaaS projects, I decided to stop starting from scratch.
I spent the last phase turning that foundation into a complete, reusable codebase.
The current version includes:
Next.js 15 + React 19
Supabase Auth + SSR
Google and GitHub OAuth
Multi-tenant organizations
Owner / Admin / Member RBAC
Secure team invitations
Stripe subscriptions, Checkout + Customer Portal
Stripe webhook synchronization
API keys with hashed secrets
Usage tracking and plan-based limits
Audit logs and notifications
Feature flags
PostgreSQL RLS
Projects and settings
The part I'm most interested in isn't the feature list, though.
It's whether having all of this already implemented actually changes the build decision for someone starting a B2B SaaS.
So I've finished the product and I'm putting it in front of developers now.
If you were starting a B2B SaaS this week, which of these would you most want already solved?
Foundations are easy to keep polishing because each missing piece feels urgent. I’d define one customer workflow end-to-end and tie every foundation task to a measurable outcome—time-to-first-value, support minutes, or conversion. After 3–5 real customers, freeze the schema for a cycle and prioritize the workflow that gets used weekly; that keeps infrastructure from becoming a second product.
I like the idea of tying infrastructure work to an actual customer workflow. That's probably the best way to avoid turning the foundation itself into the product.
I'm at that point now — the foundation is built, so the next phase is seeing which parts actually matter once real developers use it. The 3–5 customer checkpoint is a good rule for deciding what deserves another iteration.
Team invitations and roles for me. In B2B, the person trialling the product may not be the eventual admin or the person paying for it. Having those people join the same workspace without starting over would make the foundation valuable.
That's a really good point. The trial user and eventual buyer being different people is exactly where team invitations and roles become important.
Have you run into situations where the workspace had to be recreated or ownership/permissions became messy when that transition happened?
You’ve proven the infrastructure saves you from rebuilding it. The real validation now is whether developers will pay to skip that work on their next SaaS—have any shown that intent yet?
The boring-but-painful pieces are the real win here: tenant isolation, RLS, and Stripe webhook sync. I’d probably prioritize those over feature flags when choosing a starting point, then test the setup with a tiny two-tenant app before committing. That’s where a reusable foundation either earns its keep or exposes sharp edges.
Exactly. Those are the pieces that aren't particularly exciting to build, but they become expensive when you get them wrong.
The Stripe webhook side especially is easy to underestimate — the happy path works quickly, but keeping subscription state, entitlements, and usage limits consistent when things change is where the complexity shows up.
That's a big part of why I wanted these things solved together rather than treating them as separate starter features.
The rebuild trap is real — spent 6 months on v2 of our foundation before realizing v1 was fine for the first 50 users. Shipping beats perfect infrastructure every time.
That's a trap I think a lot of developers fall into — building the foundation for the product they might have instead of the product they actually have.
That's also why I tried to keep this focused on the infrastructure a B2B SaaS needs from the beginning: auth, tenancy, permissions, billing, security and the surrounding edge cases.
At some point you have to stop improving the foundation and actually build on top of it.