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?

5 Comments

  1. 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.
  2. 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?
    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.

      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?
        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”?

About

I kept rebuilding the same SaaS infrastructure every time I started a B2B SaaS project. I wanted a reusable foundation that handled authentication, multi-tenancy, RBAC, billing, API keys, usage limits, audit logs, and se