I built a SaaS backend, then shipped 4 paying products on it before letting anyone else touch it replaced Clerk + Stripe + Lago + Knock
I spent the last few months building BuildBase, and instead of shipping a demo and calling it proof, I built four real, paying products on top of it first. Next month I'm opening it to other builders, and IH felt like the right place to do it honestly.
What it is
The operational backend for an AI SaaS, delivered as one React/Next SDK + a hosted dashboard. It's the stuff every SaaS rebuilds from scratch and usually stitches together from five different vendors:
- Auth (hosted login, email/password, magic link, Google, Microsoft)
- Multi-tenant workspaces + RBAC — one toggle flips the whole app between B2C and B2B mode, enforced at the API level
- Stripe billing — subscriptions, trials, seats, plan versioning that auto-grandfathers customers, and the part everyone underestimates: usage-based / metered billing with overages, multi-currency, and real quota gates. Not just metering — actual enforcement.
- A full email + push engine — campaigns, open-tracking, drip workflows, all pre-wired to billing events
- Feature flags, CRM/audiences, analytics, full i18n (8 locales)
- A headless API-key layer so you can run it as pure infra behind your own UI
The one-liner: stop duct-taping Clerk + Stripe + Lago + Knock + a flags tool. One SDK, one dashboard, one bill.
Why I'm posting instead of just dropping a link
It's all running in production on my own products, taking money today — not slideware:
- PlugNode (plugnode.ai) — product photos into AI video ads, images & voiceovers. Runs the hardest case: metered flow-run billing with overages, multi-currency, team workspaces.
- AgentCenter (agentcenter.cloud) — mission control for AI agents; tiered plans, trials, affiliates.
- RemoteWait (remotewait.com) — virtual-queue SaaS for salons & clinics; SMS, real-time dashboard.
- LinkTracer — link tracking for YouTube creators; team RBAC, analytics.
Four very different products, one backend. That was the whole bet — if it could carry all four, it's real.
The honest part
Because I'd want this if I were reading:
- It's early. v0.0.x, small team.
- React / Next-only right now. No Vue/Svelte/vanilla yet.
- Not a 5-minute drop-in like Clerk — you wire up a few backend endpoints, realistically an afternoon. There's a template that pre-wires most of it.
- The metered-billing engine (the genuinely hard part) is the most battle-tested piece. The newer stuff is newer.
On money
Free during beta. Pricing comes later, and there's no revenue tax — you bring your own Stripe, so I never touch a cent you make. I charge for the platform, not a slice of your revenue.
What I'm after
A handful of people genuinely building a monetized AI or SaaS product — especially anything with usage- or credit-based pricing — who'll use it for real and tell me exactly where it breaks. Direct line to me, fast fixes. Not vanity signups.
If that's you, email dharmendra@jagodana.org with one line on what you're building and I'll get you in.
One question for the IH crowd, since you've all priced products: I'm leaning toward charging per application (each app = its own isolated DB + cluster, which is my real cost), free until you hit real revenue, flat tiers after — explicitly avoiding per-MAU and any % of revenue. Does that pricing shape make sense to you, or would it put you off? Genuinely want the pushback before I lock it in.
This is a strong wedge because you are not selling another auth wrapper or billing dashboard. The real value is reducing the operational drag that every monetized SaaS rebuilds before it can actually grow.
The proof point that makes this credible is not the feature list. It is that four different products with different pricing, teams, metering, billing, and notification needs are already running on the same backend. That gives BuildBase a much better story than “Clerk + Stripe + Lago + Knock in one.”
One thing I’d pressure-test before opening this wider is the name. BuildBase is clear, but it may make the product sound like a generic starter kit or boilerplate base. What you are describing feels more like an operating layer for monetized SaaS: billing enforcement, workspaces, usage gates, CRM, notifications, analytics, and API-key infrastructure.
A broader name like Xevoa .com could give the same product a cleaner platform frame without changing what you built. It sounds less like a base template and more like the execution layer behind serious SaaS products.
The product is already stronger than the “base” framing suggests. If you are about to invite real builders in, the name is probably worth pressure-testing before early users, docs, and examples lock around it.
Will think...
That is the right way to treat it.
I would not rename just for the sake of renaming. The question is whether BuildBase still fits if the product becomes more than a backend starter kit.
If the direction is really “the operating layer behind monetized SaaS products,” then the name has to carry more platform weight before docs, examples, and early users lock around the current frame.
Xevoa.com came to mind because it gives the product a cleaner SaaS infrastructure/platform feel without boxing it into “base” or boilerplate.
If it feels like a serious option, worth discussing privately before you make the public rollout too permanent.