I kept rebuilding the same B2B SaaS infrastructure

This is a really good distinction. I agree that “we wrote the RLS policies for you” is only valuable up to a point. The more interesting problem is keeping tenant isolation correct as the application evolves. The schema-change example is especially useful — a new join table or feature gets added, everything works normally, but the security model quietly becomes incomplete. That’s something I hadn’t been thinking about enough as a product problem. Rather than just making RLS easy to set up, the bigger opportunity may be making it harder to accidentally regress. If you were building that today, would you want it to be primarily a test suite that runs against the schema, or something that actively checks migrations/PRs for potential RLS gaps?

That's exactly where I think the foundation needs to stay opinionated without becoming restrictive. B2B SaaS OS currently ships with Owner/Admin/Member RBAC, but the underlying authorization is server-side, so custom permissions can be extended without replacing the whole model. For billing, it's built around Stripe subscriptions, webhooks, plan/entitlement state and usage limits, so you're not locked into a single pricing model. Usage-based pricing beyond the included limits would still require extending the metering/billing logic for the specific product. I deliberately didn't try to make it a universal permissions/billing engine — the goal is to give you a solid foundation that you can extend when the product's requirements get more specific.

That's fair. AI makes it much easier to generate a basic SaaS template now. The reason I don't see B2B SaaS OS as competing with “generate me a template” is that the value isn't the initial code generation. It's having the harder infrastructure already implemented and working together — multi-tenancy, RLS, RBAC, invitations, Stripe webhooks, entitlements, API keys, usage limits, audit logs, etc. You can absolutely generate those pieces with AI. The question I'm testing is whether some developers would rather start from a codebase where those systems have already been designed, integrated, and tested instead of spending the time getting all the pieces to work correctly together. If AI can get someone there faster, that's great. I'd just want to know whether the remaining integration/debugging/security work is still enough of a pain to justify $249.

That's a good distinction. I think the “security breaks” part is probably the strongest signal for me too. Saving a few hours is easy to rationalize away; having to debug a tenant-isolation or authorization issue in production is a very different calculation. I also like measuring what percentage of the previous implementation was actual product work versus infrastructure/edge cases. That seems like a much better way to understand whether a boilerplate is genuinely saving someone time or just saving them from writing familiar code. That's something I'll start asking developers about as I get the product in front of more people.

Yeah, that's exactly the distinction. The happy path is easy; keeping Stripe state and application state consistent when things go wrong is where the real complexity starts. That's why I included webhook synchronization, subscription state, Checkout, Customer Portal, and usage/plan enforcement rather than treating billing as just “add Stripe Checkout.” The exception-pattern question is especially useful. If multiple developers are describing the same billing failures and manual cleanup, that's a much stronger signal than simply saying “billing is annoying.