I rebuilt the same SaaS backend five times. So I turned it into one SDK.
I build SaaS products with my brother. After shipping five of them, I realized I'd rebuilt the exact same backend (auth, Stripe, multi-tenancy, workflows, email, webhooks) five separate times. So I extracted it into one SDK for React/Next.js. It now runs all five products in production. This is the honest version, including what it still can't do. The fifth time I sat down to write sign-up and login, I stopped. It wasn't hard. That was the problem. I'd done it four times already, and I could see
I build SaaS products with my brother. After shipping five of them, I realized I'd rebuilt the exact same backend (auth, Stripe, multi-tenancy, workflows, email, webhooks) five separate times. So I extracted it into one SDK for React/Next.js. It now runs all five products in production. This is the honest version, including what it still can't do.
The fifth time I sat down to write sign-up and login, I stopped.
It wasn't hard. That was the problem. I'd done it four times already, and I could see the next three weeks laid out in front of me like a checklist I'd memorized: auth, then Stripe, then workspaces, then roles and permissions, then usage limits, then transactional emails, then webhooks. Weeks of plumbing before I could touch the one feature that was the actual reason I started the project.
I build software with my brother. Five of our products are live right now:
- Imejis - a template-based image-generation API
- AgentCenter - mission control for AI agents
- PlugNode - a visual AI workflow builder
- RemoteWait - a virtual queue system
- LinkTracer - creator analytics
Five completely different products. Every single one needed the exact same backend before it could do anything interesting.
The backend tax
There's a tax you pay on every SaaS product before you write a single line of the thing that makes it special.
Users, so you build auth - and not just email/password, but social login, magic links, sessions, resets. Revenue, so you wire up Stripe, including a whole metering layer if you're doing anything usage-based. Teams, so you build workspaces, roles, invitations. Then email. Then feature flags. Then webhooks.
None of it is novel. All of it is necessary. And all of it stands between you and the actual idea.
The first time, it's fun, you're learning. By the third time, you're copy-pasting from your last repo and quietly resenting it. By the fifth, you're maintaining five slightly different versions of the same bugs.
The first rebuild feels like progress. The fifth one feels like a warning.
From copy-paste to a platform
After the third product, I stopped copy-pasting and started extracting - pulling the shared pieces into their own package with a hard boundary between what was truly generic and what was product-specific.
After the fourth, the package had opinions. It knew how billing should attach to a workspace. It knew each org should get its own physically isolated database. It had a workflow engine, because I was tired of gluing cron jobs and automation tools together just to send a welcome sequence.
After the fifth, it wasn't a package anymore. It was a platform, running all five products in production every day.
That's BuildBase.
What it is
The whole SaaS backend for React and Next.js, in one SDK.
npm install @buildbase/sdk
Enter fullscreen mode Exit fullscreen mode
Not just auth. Nineteen integrated modules that actually talk to each other, because they were built together for real products rather than stitched together from a marketplace of disconnected services:
- Auth - email/password, magic link, passkeys (WebAuthn), Google, GitHub, Microsoft, LinkedIn, plus a full OAuth 2.0 authorization server so your app can become an identity provider
- Billing - Stripe with your own account, usage-based metering, quota enforcement, credits, seats, multi-currency
- Multi-tenancy - an isolated workspace and isolated database per org, with RBAC
- Workflows - a real event-driven engine (triggers, actions, conditions), queue-backed
- Communication - email through your own sender (SMTP, Google, Microsoft, Mailgun) plus event-driven Slack alerts
- Growth - feature flags, audience/CRM, short links, webhooks, analytics
- Global - i18n across 8 locales and 22 currencies
- Headless - an API layer, so you can use any of it without our UI
The point isn't the length of the list. It's that these pieces work as one system. Billing knows about your workspaces. Workflows can read your audience. Feature flags can target a plan. That coherence is the part you can't copy-paste from five different vendors.
How it actually runs
Under the hood it's MongoDB + Redis + Docker. The defining architectural choice is a physically isolated database per organization - not a shared table with a tenant_id column, but real per-org isolation. That's the single biggest cost driver, which is also why the pricing is per-app rather than per-seat (more on that below).
Being honest about the tradeoff: per-org isolation is great for data separation and terrible if you pretend it scales infinitely. It doesn't yet. There's a known connection-pool ceiling I'm not going to hand-wave past, so I'm not making big scale claims.
The three decisions I care most about
A feature list tells you what a product does. These tell you what it believes.
1. Bring your own Stripe, and I take 0% of it. Your customers pay you, directly, into your own Stripe account. I never sit in the middle of your revenue. The norm in this space is that your bill climbs as you grow. I built the opposite on purpose, because I've been the founder watching that line item climb.
2. You own your data, three ways to run it. Shared (isolated DB per app on our infra), Dedicated (dedicated infra per app), or Self-hosted (run our Docker images on your own servers with your own MongoDB and Redis). No lock-in by design.
3. Per-app pricing. One app = one org = one isolated database. You pay for what you actually run, not per-seat and not per-MAU. Three plans: Launch, Grow, Scale.
Let me be straight about where it stands
This is the part I'd want to read first, so here it is.
React and Next.js only, today. No Vue, Svelte, or native mobile SDK yet.
Not open source. I know this matters most to this crowd, so I'm not going to bury it. Self-hosting means running our compiled Docker images on your own infrastructure - you don't get the source code. What you get instead is no vendor lock-in: your infra, your database, your Stripe. I'm not going to dress up "self-hostable" as "open source," because it isn't, and you'd catch it in five minutes anyway.
Early and bootstrapped. It's me and my brother. The SDK is young (0.x). But it isn't a landing page with a waitlist - five real products depend on it in production every day. When something breaks, it breaks for me first.
Who it's for
Solo founders, indie hackers, and small teams building SaaS on React or Next.js who are sick of wiring the same backend together for the tenth time and want those weeks back for the product that actually matters.
Try it, or tear it apart
- Website: https://www.buildbase.app
- Live demo: https://demo.buildbase.app/
- Docs: https://docs.buildbase.app/introduction
- Self-host starter: https://github.com/buildbase-app/self-hosted-starter
The feedback I most want, especially from this audience: what would make you trust a backend SDK enough to build your next SaaS on it? And what's the one thing missing for your stack?
Reach me anytime at [email protected].
I built this because I got tired of paying the backend tax. If it saves you even one of those rebuilds, it did its job.
