u/dharmendra_jagodana

Every time I launch a side project, the same thing happens: week 1 is auth, multi-tenancy, and billing setup. Week 2 is the actual product. It's brutal.

So with a few co-founders, we pulled the infrastructure from our own paid products and turned it into a React SDK. Auth, orgs, RBAC, usage limits, billing, notifications, workflows, feature flags, analytics — it's all there.

The goal: ship your actual idea in week 1 instead of building the foundation.

It's in beta, free tier exists, and it's React/Next.js native. If you've felt this pain, I'd love your take on whether this scratches the itch.

Disclosure: I built this (BuildBase), so I'm not neutral. Posting because the docs/site just went live and I want real feedback, not upvotes.

The idea is simple: stop rebuilding the same SaaS plumbing every project. Auth, billing, emails, workflows, user management — all in one React/Next.js SDK, so you spend your time on the part that's actually your product.

What's actually in it (real list, no buzzwords):

• Auth — OAuth (Google, LinkedIn), magic links, sessions, API tokens
• Billing — Stripe subs, usage-based billing with credits, quotas + overages, trials, plan versioning
• Emails — templates, campaigns, tracking, unsubscribe
• Workflows — visual builder, triggers/conditions/actions
• Multi-tenant workspaces + RBAC
• Feature flags, forms, webhooks (70+ events), short links, CMS

The piece I care most about is usage-based billing — metering, credits, quotas, overages done properly, which is the part most auth tools and templates leave you to build yourself.

Honest about where it is: young (v0.0.x), React/Next.js only. The proof isn't a logo wall — it's that the same SDK runs all four of my own paid products in production. If it breaks, my revenue breaks first.

What I'd genuinely like feedback on:

1. Does the docs site actually make it clear how to get started, or is it confusing?
2. Of that feature list, what's the one thing that'd make you try it — and what's noise?
3. If you've used Clerk/Stripe/Stigg/etc — what would make you switch, or not?

(Site + docs in my profile / first comment — keeping links out of the body.)

Been thinking about this after watching a few projects (mine and friends') die the same way.

Here's the trap almost every first SaaS falls into:

You have an idea. You're excited. So you start building. And because every SaaS needs the same foundation, you spend the first 2-3 weeks on auth, then billing, then multi-tenant workspaces, then RBAC, then notifications — before you've written a single line of the thing that's actually your idea.

Then you launch. And nobody comes.

Now do the honest accounting of what you lost. It's not the idea — ideas are free. It's the 2-3 weeks (or 6, or 10) you spent building plumbing for users who never showed up. At even a modest dev rate that's easily a few thousand dollars of your time sunk into auth flows and Stripe webhooks for a product the market just told you it didn't want. And you can't get it back.

That's the part nobody prices in. The cost of a failed idea isn't the failure itself — it's how much you built before you were allowed to fail.

The reframe I wish I'd had earlier: the plumbing is never the variable you're testing.

Every SaaS needs auth and billing. That part isn't your idea — it's table stakes, identical across every app. The only thing the market is actually judging is your unique 20%. So spending your scarcest resource (time, before validation) building the shared 80% is backwards. You're paying full price to build the one part that was never in question.

What's worked better for the people I've seen do this well:

• Get the idea-specific part in front of real users as fast as humanly possible, even ugly.
• Treat the foundation as something to borrow/scaffold/fake, not handcraft, until the idea proves out.
• Let yourself fail in days, not months. A killed idea after a weekend is a win. A killed idea after 3 weeks of plumbing is a loss you funded yourself.

Genuinely curious how people here handle it:

1. How much time did your first SaaS's "boring foundation" eat before you actually tested the idea?
2. Do you build the plumbing first, or hack the idea together and bolt on auth/billing later?
3. For those who've shipped a few — would shipping faster have changed which ideas you killed?

Been thinking about this after watching a few projects (mine and friends') die the same way.

Here's the trap almost every first SaaS falls into:

You have an idea. You're excited. So you start building. And because every SaaS needs the same foundation, you spend the first 2-3 weeks on auth, then billing, then multi-tenant workspaces, then RBAC, then notifications — before you've written a single line of the thing that's actually your idea.

Then you launch. And nobody comes.

Now do the honest accounting of what you lost. It's not the idea — ideas are free. It's the 2-3 weeks (or 6, or 10) you spent building plumbing for users who never showed up. At even a modest dev rate that's easily a few thousand dollars of your time sunk into auth flows and Stripe webhooks for a product the market just told you it didn't want. And you can't get it back.

That's the part nobody prices in. The cost of a failed idea isn't the failure itself — it's how much you built before you were allowed to fail.

The reframe I wish I'd had earlier: the plumbing is never the variable you're testing.

Every SaaS needs auth and billing. That part isn't your idea — it's table stakes, identical across every app. The only thing the market is actually judging is your unique 20%. So spending your scarcest resource (time, before validation) building the shared 80% is backwards. You're paying full price to build the one part that was never in question.

What's worked better for the people I've seen do this well:

• Get the idea-specific part in front of real users as fast as humanly possible, even ugly.
• Treat the foundation as something to borrow/scaffold/fake, not handcraft, until the idea proves out.
• Let yourself fail in days, not months. A killed idea after a weekend is a win. A killed idea after 3 weeks of plumbing is a loss you funded yourself.

Genuinely curious how people here handle it:

1. How much time did your first SaaS's "boring foundation" eat before you actually tested the idea?
2. Do you build the plumbing first, or hack the idea together and bolt on auth/billing later?
3. For those who've shipped a few — would shipping faster have changed which ideas you killed?

Been thinking about this after watching a few projects (mine and friends') die the same way.

Here's the trap almost every first SaaS falls into:

You have an idea. You're excited. So you start building. And because every SaaS needs the same foundation, you spend the first 2-3 weeks on auth, then billing, then multi-tenant workspaces, then RBAC, then notifications — before you've written a single line of the thing that's actually your idea.

Then you launch. And nobody comes.

Now do the honest accounting of what you lost. It's not the idea — ideas are free. It's the 2-3 weeks (or 6, or 10) you spent building plumbing for users who never showed up. At even a modest dev rate that's easily a few thousand dollars of your time sunk into auth flows and Stripe webhooks for a product the market just told you it didn't want. And you can't get it back.

That's the part nobody prices in. The cost of a failed idea isn't the failure itself — it's how much you built before you were allowed to fail.

The reframe I wish I'd had earlier: the plumbing is never the variable you're testing.

Every SaaS needs auth and billing. That part isn't your idea — it's table stakes, identical across every app. The only thing the market is actually judging is your unique 20%. So spending your scarcest resource (time, before validation) building the shared 80% is backwards. You're paying full price to build the one part that was never in question.

What's worked better for the people I've seen do this well:

• Get the idea-specific part in front of real users as fast as humanly possible, even ugly.
• Treat the foundation as something to borrow/scaffold/fake, not handcraft, until the idea proves out.
• Let yourself fail in days, not months. A killed idea after a weekend is a win. A killed idea after 3 weeks of plumbing is a loss you funded yourself.

Genuinely curious how people here handle it:

1. How much time did your first SaaS's "boring foundation" eat before you actually tested the idea?
2. Do you build the plumbing first, or hack the idea together and bolt on auth/billing later?
3. For those who've shipped a few — would shipping faster have changed which ideas you killed?

NOTE: Asking as I'm working on one solution to resolve all of it.

Been doing some math that surprised me. The operational layer every SaaS needs — auth, billing/entitlements, notifications, feature flags, lifecycle messaging — costs more than the product infra most of the time.

Priced with the popular best-in-class tools at a small-but-real scale:

• Auth (Clerk-tier) ~ $25/mo
• Entitlements (Stigg-tier) ~ $249/mo
• Notifications (Knock-tier) ~ $250/mo
• Feature flags (LaunchDarkly-tier) ~ $120/mo
• Lifecycle (Customer.io-tier) ~ $100/mo

≈ $744/mo, and those are starting figures — they climb with usage.

The part that bugs me more than the price is the integration tax: 5 dashboards, 5 SDKs, and the glue wiring them together — webhooks between your payment provider and your flags, syncing entitlements back to auth, keeping usage counts honest across systems that don't talk to each other. None of that shows up on an invoice.

Genuinely curious how people here handle it:

1. What's your real monthly backend cost — dollars and the time/glue?
2. Do you go best-of-breed (many tools) or try to bundle into fewer?
3. Has anyone actually rolled their own to avoid the per-tool fees — was it worth it?

Disclosure up front: I build a tool in this space, so I'm not neutral. But the math stands on its own and I think it's worth a discussion here.

I priced out the operational layer every SaaS needs — the stuff nobody signs up for — using the popular best-in-class tools, at a small-but-real scale:

• Clerk (auth) ~ $25/mo
• Stigg (entitlements) ~ $249/mo
• Knock (notifications) ~ $250/mo
• LaunchDarkly (flags) ~ $120/mo
• Customer io (lifecycle) ~ $100/mo

≈ $744/mo — and these are starting figures, they climb with usage.

But the sticker price isn't the real cost. The hidden one is the integration tax: 5 dashboards, 5 bills, 5 SDKs, and the glue wiring them together (webhooks between Stripe and your flags, syncing entitlements to auth, keeping usage counts honest across systems that don't know about each other). That part never hits an invoice — it hits your weekends.

I got tired of paying it, so I'm building a single SDK that bundles that layer (BuildBase) — but I'm genuinely more curious about the discussion than the plug:

1. What's your actual monthly backend stack cost — and does it feel worth it?
2. Do you bundle (one vendor) or best-of-breed (many)? Why?
3. Where does the glue code actually hurt most for you?

(Tool's in my profile if anyone wants it — keeping it out of the body.)

Been doing some math that surprised me. The operational layer every SaaS needs — auth, billing/entitlements, notifications, feature flags, lifecycle messaging — costs more than the product infra most of the time.

Priced with the popular best-in-class tools at a small-but-real scale:

• Auth (Clerk-tier) ~ $25/mo
• Entitlements (Stigg-tier) ~ $249/mo
• Notifications (Knock-tier) ~ $250/mo
• Feature flags (LaunchDarkly-tier) ~ $120/mo
• Lifecycle (Customer.io-tier) ~ $100/mo

≈ $744/mo, and those are starting figures — they climb with usage.

The part that bugs me more than the price is the integration tax: 5 dashboards, 5 SDKs, and the glue wiring them together — webhooks between your payment provider and your flags, syncing entitlements back to auth, keeping usage counts honest across systems that don't talk to each other. None of that shows up on an invoice.

Genuinely curious how people here handle it:

1. What's your real monthly backend cost — dollars and the time/glue?
2. Do you go best-of-breed (many tools) or try to bundle into fewer?
3. Has anyone actually rolled their own to avoid the per-tool fees — was it worth it?

Upfront: I built this, so this is a maker looking for feedback, not a neutral rec. Mods, happy to move it if it's the wrong place.

Every SaaS I've built needed the same plumbing before I could touch the actual product — auth, workspaces, billing, email, feature flags, notifications. I rebuilt it every time, and it was never the reason anyone signed up. So I turned it into one React/Next.js SDK (BuildBase) and, more usefully, a ready-made Next.js starter where it's already plugged in.

The starter is Next.js + TypeScript + Tailwind + shadcn/ui with the SDK wired in: auth, multi-tenant workspaces, RBAC, credit packages and feature gates already in place. You clone it, drop in your keys, and start writing your own app logic instead of standing up the boring 80% first.

Live demo (real running app, not a screenshot — go poke at it): (link in a comment below to keep it rule-friendly)

What's in the SDK behind it: subscriptions/trials, usage-based + seat-based billing, email campaigns with tracking, workspaces + RBAC, feature flags you flip without a deploy, push notifications, workflows, webhooks, forms, short links — 19 modules, one dashboard.

On pricing, since it always comes up: no per-user fees, no cut of your revenue. Build, launch, get your first real users — pay nothing. You only pay later if you grow into the heavy stuff (high email volume, workflows at scale, dedicated infra). For early builders right now it's just free, in exchange for honest feedback.

Honest state: it's early (v0.0.x) and React/Next.js only, and so far it's mostly validated by me running it on my own four products in production. That's exactly why I want eyes from people who aren't me.

What I'd genuinely love feedback on:

1. Does a "pre-wired starter" actually save you time, or do you prefer wiring your own stack so you understand it?
2. What's the one thing in that 19-module list you'd need on day one — and what's noise?
3. If you've shipped a SaaS before: how long did the plumbing actually cost you?

If you're building on React/Next.js and want a running foundation instead of a blank repo, happy to get you set up — comment or DM.

Upfront: I built this, so this is a maker looking for feedback, not a neutral rec. Mods, happy to move it if it's the wrong place.

Every SaaS I've built needed the same plumbing before I could touch the actual product — auth, workspaces, billing, email, feature flags, notifications. I rebuilt it every time, and it was never the reason anyone signed up. So I turned it into one React/Next.js SDK (BuildBase) and, more usefully, a ready-made Next.js starter where it's already plugged in.

The starter is Next.js + TypeScript + Tailwind + shadcn/ui with the SDK wired in: auth, multi-tenant workspaces, RBAC, credit packages and feature gates already in place. You clone it, drop in your keys, and start writing your own app logic instead of standing up the boring 80% first.

Live demo (real running app, not a screenshot — go poke at it): (link in a comment below to keep it rule-friendly)

What's in the SDK behind it: subscriptions/trials, usage-based + seat-based billing, email campaigns with tracking, workspaces + RBAC, feature flags you flip without a deploy, push notifications, workflows, webhooks, forms, short links — 19 modules, one dashboard.

On pricing, since it always comes up: no per-user fees, no cut of your revenue. Build, launch, get your first real users — pay nothing. You only pay later if you grow into the heavy stuff (high email volume, workflows at scale, dedicated infra). For early builders right now it's just free, in exchange for honest feedback.

Honest state: it's early (v0.0.x) and React/Next.js only, and so far it's mostly validated by me running it on my own four products in production. That's exactly why I want eyes from people who aren't me.

What I'd genuinely love feedback on:

1. Does a "pre-wired starter" actually save you time, or do you prefer wiring your own stack so you understand it?
2. What's the one thing in that 19-module list you'd need on day one — and what's noise?
3. If you've shipped a SaaS before: how long did the plumbing actually cost you?

If you're building on React/Next.js and want a running foundation instead of a blank repo, happy to get you set up — comment or DM.

Upfront: I built this, so this is a maker looking for feedback, not a neutral rec. Mods, happy to move it if it's the wrong spot.

Backstory — every SaaS I built needed the same plumbing, and I kept assembling the same stack: Clerk for auth, Stripe + a metered-billing tool for usage, something for notifications, a flags tool, i18n. Five dashboards, five bills, glue code in between. On the third project I gave up and built the layer myself as one SDK. It's called BuildBase (React/Next.js).

What it ended up covering:

• Auth + multi-tenant workspaces — email/password, magic link, Google/OAuth. One toggle flips the app between single-user (B2C) and team mode (B2B), enforced at the API so there's no conditional code.
• RBAC at two levels — roles for my own team, and roles for end-users inside their workspaces. Checked server-side, configured in a dashboard.
• Usage-based billing — quotas, overages, metered Stripe. Usage recorded client/server/batch, enforced at the API (so the paywall can't be flipped from the browser console), overages auto-billed.
• Non-destructive plan versioning — change pricing and old customers stay grandfathered on their version; new signups get the new one. No forced migrations.
• Notification engine — email + push + Slack with delivery gates + drip workflows, wired to billing events.
• Plus feature flags, i18n (8 locales, RTL, per-currency), outbound webhooks, and a headless API-key layer so you can pull your data out anytime. BYO Stripe + email sender, so no revenue cut.

Honest state: it's for React/Next.js only, and so far validated mostly by me running it on my own four products in production. That's the whole reason I'm here — I want feedback from people who aren't me.

What I'm actually unsure about:

1. Is bundling all of this into one SDK useful, or does it scare you (too much lock-in / too much in one basket)?
2. Where's the line — what would you still want to own/swap out yourself?
3. If you've assembled the 5-tool stack before: what did it actually cost you in time, and would you trade it for one vendor?

Not dropping a link in the body to keep it rule-friendly — happy to share if you want to poke at it.

If you're bootstrapped, every tool cost hurts.

Email is where people get bled dry: Mailgun ($0.50 per 1K messages) + Klaviyo ($100/mo minimum) + custom automation = $200+/mo before you have any real users.

What I do: use a tool that doesn't charge per email, integrates campaigns + tracking + automation in one place, and lets me bring my own sender (so Mailgun costs are just infrastructure, not vendor markup).

BuildBase is worth looking at. Free tier is actually free for transaction emails (not "free until 1K emails" with hidden paywalls). You only pay when you have real revenue. And because you bring your own sender, costs scale with your usage, not with the vendor's pricing model.

Free to test. Email dharmendra@jagodana.org.

Bootstrapping means you can't afford to overspend on infrastructure. Email is infrastructure.

Upfront disclosure: I built this, so this is a maker looking for feedback, not a neutral recommendation. Mods, happy to move it if it's the wrong place.

I've been building BuildBase App — a React/Next.js SDK + backend that handles the SaaS plumbing (auth, workspaces, usage-based billing, notifications) so you don't stitch together five vendors. The piece I just want feedback on today is the workflow engine, because I'm genuinely unsure if I over-built it.

The idea: event-triggered, time-aware automations — the Customer.IO / drip-campaign thing — but living inside the same system that already knows about your users, subscriptions and usage. So a workflow can react to product events, not just email opens.

What it does right now:

• 47 trigger events across users, workspaces, subscriptions, payments, quotas, forms, email and audience (e.g. subscription.trial_will_end, quota.limit_exceeded, user.registered, audience.added_to_list)
• 11 actions: delay, send email, send push, HTTP webhook, add/remove from lists, tag, update/get audience, transform data, and wait-for-event
• Branching + conditions: if/else, filters, and random split for A/B
• A typical flow looks like: audience added → wait 30 min → welcome email → wait 1 day → check if they've subscribed → branch
• Versioning, instance logs, a template library, and a dead-letter queue for failed runs

Why I bothered building it instead of telling people "just use Customer.io": when the automation lives in the same place as billing and auth, you can trigger off things an email tool can't see — like "trial ending in 3 days AND quota 80% used → send the upgrade nudge." That's the bet, anyway.

Honest state of things: it's young (v0.0.x), it's React/Next.js only, and it's mostly been validated by me running it on my own four products in production. That's exactly why I'm here — I want feedback from people who aren't me.

Questions I'd genuinely love answers to:

1. Is "workflows tied to billing/usage events" actually a pain you have, or a solution looking for a problem?
2. What's the one trigger or action that would make or break this for you?
3. If you already run drip/lifecycle automation — what tool, and what do you hate about it?

Not dropping a link in the body to respect the rules — it's in my profile, and happy to share if anyone wants to poke at it.