Why the SaaS layer becomes its own product

Every SaaS product starts with a product idea, and every SaaS team eventually discovers it is building a second product it never planned: the platform layer.

It starts small. Sign-in, a users table, a role column. Then the first real customer asks for teams. Then the second asks for an audit log. A year in, the "boring" parts of the codebase look like this:

• Auth flows that outgrew sign-in: invites, password resets, sessions, SSO asks, machine credentials.
• A roles table that mutated into orgs, tenants, groups, scoped assignments, explicit denies, temporary access, and approval workflows.
• Deployment infrastructure that needs tenant awareness: which customer runs where, what version, how to update or tear down safely, and what to do when a big customer wants your stack in their cloud.
• Webhooks that need signing, retries, delivery history, subscription management, and protection from calling into private networks.
• An admin UI your support team lives in — and embedded management components your customers keep asking to have inside the product.

None of this is your product. All of it is expected of your product.

The trap

Teams handle this three ways, and two of them hurt.

Some build it all by hand from cloud primitives. Total control, maximum flexibility — and months of engineering on infrastructure users never see, followed by permanent maintenance.

Some assemble a patchwork of hosted vendors: one for auth, one for authorization, one for webhooks. Each one adds a network hop, a data model, a billing meter, and a place where your tenant model doesn't quite fit.

The third way is to admit the SaaS layer is a real product domain — with its own design constraints, like keeping authorization checks off the network hot path — and adopt it as deployable infrastructure inside your own cloud account, rather than rebuilding it or renting fragments of it.

What we're building

SaaSLayer is that third way for AWS-backed products: a user service, an IAM-style RBAC engine, tenant-aware deployment orchestration, event delivery, and embeddable admin surfaces — shipped as modules that deploy into SaaSLayer-managed or customer-owned AWS accounts.

The docs walk through the pieces. The RBAC overview is the deepest module today, and the rest of this blog will dig into the design decisions module by module.