B2B SaaS OS

Production-ready infrastructure for B2B SaaS

Visit Website

September 5, 2026 I kept rebuilding the same B2B SaaS infrastructure

Every time I started building a B2B SaaS, I kept running into the same problem.

The product itself was usually the interesting part.

Then came everything underneath it:

Authentication
Organizations and multi-tenancy
RBAC
Team invitations
Billing
API keys
Usage limits
Audit logs
PostgreSQL RLS

I ended up rebuilding the same foundation over and over.

So I decided to build it once properly and turn it into a reusable foundation.

That's how B2B SaaS OS started.

It's built with Next.js, Supabase and Stripe, with the goal of letting developers spend more time building the actual product instead of rebuilding the infrastructure around it.

I'm now at the point where the product is finished and I'm starting to put it in front of other developers.

I'm particularly interested in one question:

What's the piece of B2B SaaS infrastructure you hate rebuilding the most?

wendel

4 Likes

17 Comments

Say something nice…

Post Comment

1

But, nowdays everyone can build a template just with a subscription with AI, so, why buying this?

ggmaldo

·
4 hours ago
·
Reply
1. 1
  
  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.
  
  wendel
  
  ·
  3 hours ago
  ·
  Reply
1

The "$249 vs. a week of my time" calculation silently assumes builders are measuring the same dimension. But they're often measuring different things. One builder measures calendar-time-to-feature-one and sees "$249 = 2 hours saved." Another measures engineering-hours-spent-on-RBAC and sees "$249 = 0 because I already know how." I'd ask early users to estimate three things: their salary per hour, how many hours multi-tenancy+auth+RBAC took last time, and what % of that time was "annoying" vs "this is where security breaks." The ones where you can point to a prior incident usually have the clearest buy/build boundary.

Omri Ben-Shoham

·
18 hours ago
·
Reply
1. 1
  
  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.
  
  wendel
  
  ·
  12 hours ago
  ·
  Reply
1

Billing is the one I’d probe after the happy path. Stripe checkout is straightforward; the hard part is reconciling webhooks, plan changes, failed renewals, refunds/chargebacks, entitlements, and the ledger. I’d ask prospects to describe their last billing incident and what needed manual cleanup. Repeated exception patterns could reveal a sharper paid wedge than generic billing.

Jaymi Books

·
21 hours ago
·
Reply
1. 1
  
  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.
  
  wendel
  
  ·
  12 hours ago
  ·
  Reply
  1. 1
    
    Exactly, and there's a useful split even within the exception patterns: some are one-off (a card decline, a weird prorate) versus ones that recur every cycle (the same failed-renewal retry logic breaking, or entitlements not rolling back after a downgrade). The recurring ones are where sellers actually change behavior and pay for a fix, because it's not a one-time cleanup, it's a monthly tax on their time.
    
    Jaymi Books
    
    ·
    8 hours ago
    ·
    Reply
    1. 1
      
      Yeah, I think that's the key distinction. A one-off billing edge case is annoying, but a recurring failure becomes part of the cost of running the product. That's a much stronger signal for me than simply asking whether developers “like” having billing handled. I'm going to start paying more attention to those recurring exception patterns as I get this in front of more builders.
      
      wendel
      
      ·
      8 hours ago
      ·
      Reply
      1. 1
        
        That framing (recurring exception = monthly tax on time) is a good filter for prioritizing what to build vs what to just document. Cheap way to validate it before building: tag every support ticket or manual fix as one-off vs repeat for a couple weeks in a spreadsheet. The repeats surface fast, and you'll know exactly which exception patterns are worth automating first.
        
        Jaymi Books
        
        ·
        13 minutes ago
        ·
        Reply
1

You’ve proven the pain exists for you. What have early users said is painful enough that they’d actually pay to avoid rebuilding it themselves?

Aryan Sinh

·
a day ago
·
Reply
1. 1
  
  That's exactly what I'm trying to validate now. The biggest pain point I've personally seen is the combination of multi-tenancy, RBAC, and billing — especially getting the authorization boundaries right as the app grows.
  I've built those pieces into the current version, but I don't want to assume that what was painful for me is automatically painful enough for other developers to pay for.
  That's why I'm putting it in front of builders now and trying to learn which parts they actually value enough to buy rather than rebuild.
  
  wendel
  
  ·
  a day ago
  ·
  Reply
  1. 1
    
    That’s the right uncertainty to test. Of those three, which one do builders actually describe as painful enough to pay for rather than just annoying to implement?
    
    Aryan Sinh
    
    ·
    a day ago
    ·
    Reply
    1. 1
      
      Honestly, I don't have enough external validation yet to claim one is clearly the winner. My current hypothesis is multi-tenancy + authorization because mistakes there can become security problems, not just implementation annoyances. Billing feels more directly tied to money, but Stripe makes the basic implementation relatively accessible. So that's actually one of the things I'm trying to validate now: which problem makes a developer think “I'd rather pay $249 than spend another week building this myself”?
      
      wendel
      
      ·
      a day ago
      ·
      Reply
      1. 1
        
        That $249 threshold makes the test much clearer. What are builders actually doing when they see it — asking for access, comparing it to building themselves, or just saying it sounds useful?
        
        Aryan Sinh
        
        ·
        13 hours ago
        ·
        Reply
        
        1
        
        Honestly, I'm still collecting that signal. So far the strongest response has been people digging into the specific infrastructure problems rather than immediately asking for access, which tells me I still need to turn the conversation into actual buying behavior. My next test is pretty simple: get the product in front of developers who are actively building B2B SaaS, show them the $249 price, and see who actually clicks through, asks questions, starts comparing it to their own build time, or buys. “Sounds useful” isn't enough validation for me. I want to see what people actually do when there's a price attached.
        
        wendel
        
        ·
        12 hours ago
        ·
        Reply
        
        1
        
        That’s the right test. The behavior once the $249 price is in front of them should tell you much more than the conversations so far.
        
        Aryan Sinh
        
        ·
        12 hours ago
        ·
        Reply
        
        1
        
        Exactly. That's the signal I'm looking for now. Conversations are useful for figuring out what to test, but the $249 price is where I find out whether the problem is actually valuable enough to pay to avoid.
        
        wendel
        
        ·
        10 hours ago
        ·
        Reply

B2B SaaS OS

About

People