Enterprise features are a tax. We paid it once, in the open.

Bastien GUILLAUME — Wed, 16 Sep 2026 14:27:50 +0000

Every B2B product hits the same wall. A prospect's IT team asks for SSO through their identity provider. Then for SCIM, so accounts appear and disappear with their HR system. Then for an audit log they can hand to a compliance officer, and a rule that says "everyone in our domain must log in through our IdP, no exceptions". None of it makes the product better for the people who use it every day. All of it is table stakes for the contract.

We run eight products. Seven of them authenticate with better-auth, each with its own copy of the same setup, its own database and its own Stripe account. Building that wall seven times was never going to happen. Buying it per connection from a US vendor didn't fit either. So we built it once, as a package every product embeds, and we published it.

@alphabros/enterprise is on npm, MIT-licensed, version 0.1.0.
Source: github.com/ShipFast-Syndicate/enterprise.

What you get

One package, four entry points, no framework-specific server code:

/server — a preset of better-auth plugins: organizations with teams and roles, SSO (SAML 2.0 and OIDC) with DNS domain verification and just-in-time provisioning, SCIM 2.0 provisioning for Users and Groups, two-factor, passkeys, API keys, and two of our own: a hash-chained audit log and an organization policy engine (require 2FA, enforce SSO with a break-glass owner, session lifetime, allowed sign-in methods, group-to-role mapping).
/schema — the Drizzle tables, a plain SQL migration, and a CLI: ab-enterprise migrate copies the migration into your project, ab-enterprise verify checks the live database has every table and column (migrations that never reached production are a real failure mode; we check after every deploy), ab-enterprise audit-verify recomputes an organization's audit chain.
/client — the matching client plugins, plus discoverHomeRealm(email): the "email first, then route to your IdP" step every enterprise login page needs.
/portal — seven Web Components (Lit) that make the whole thing self-serve for a customer's IT admin: members, an SSO wizard (paste IdP metadata, verify the domain by DNS TXT, do a mandatory test login, then enforce), SCIM tokens, security policy, API keys, and an audit viewer with CSV export and chain verification. They work unchanged in SvelteKit, Astro, Next and plain HTML, and they ship no colours, fonts or spacing of their own — you map your design tokens onto --ab-* variables.

The one thing the package does not decide is who pays for what. You pass a resolveEntitlements(orgId) function that reads your own billing plan and returns the features that organization has. Every portal endpoint answers 403 without the feature. Entitlements stay in your product; the package only enforces them.

Five minutes to a working setup

// auth.ts
import { betterAuth } from "better-auth";
import { enterprisePreset } from "@alphabros/enterprise/server";

export const auth = betterAuth({
  database: drizzleAdapter(db, { provider: "sqlite" }),
  plugins: [
    ...enterprisePreset({
      product: "myapp",
      secretsKey: process.env.ENTERPRISE_SECRETS_KEY!, // ≥ 32 chars, from your secret store
      resolveEntitlements: async (orgId) => planFeatures(await getPlan(orgId)),
    }),
  ],
});

npx ab-enterprise migrate --out drizzle   # drops the SQL migration into your folder
npx ab-enterprise verify                  # against TURSO_DATABASE_URL after deploy

<ab-security-settings org-id="org_123"></ab-security-settings>

That's the whole integration. The SSO wizard, SCIM endpoints and audit log are live behind your existing /api/auth handler.

Design choices, and why

Embedded, not central. We deliberately did not build an identity service. Each product keeps its own users, its own database and its own IdP connections. A central identity plane is a single point of failure and a user migration; we'll get there later, and the data model already leaves room for it (studio_ref columns, per-organization SSO config), but not as the first step.

Built on better-auth's own plugins where they exist. organization, sso, scim, admin, twoFactor, passkey and apiKey are upstream. We added what upstream lacks: SCIM Groups on the 1.6 line (mapped onto organization teams, with a role-mapping table), the audit chain, the policy engine, the entitlement gate, the portal, and the secrets wrapper that encrypts IdP client secrets at rest with your key (AES-256-GCM, bound to the provider row).

It runs on Cloudflare Workers. Four of our products deploy there. SAML on workerd was the open question; we proved samlify's signing and verification, encrypted assertions included, under nodejs_compat before writing a line of the package.

Tamper-evident audit log. Each organization's events form a hash chain. verify recomputes it; retention works by compaction with a chained anchor rather than deletion, so a year-old log still verifies. It's honest about its limit: someone with write access to your database can rewrite the chain, which is why the CLI exists and why we recommend exporting checkpoints.

What we did about security before publishing

We ran two audits before the first publish, one on the repository and supply chain, one on the code, and a whole-branch review after the fixes. They found real things: an audit-log injection across tenants, a role recompute that could demote an organization owner through a SCIM group change, a retention purge that broke the chain, an unused encryption key. All of it is fixed, each with a regression test that reproduces the original exploit. The production dependency tree is a single package (zod). Releases are published from CI through npm Trusted Publishing with provenance; there is no long-lived publish token. The one accepted advisory on the 1.6 line is documented in docs/security.md, with the mitigation and the test that guards it.

What it is not, yet

Pilot-grade. 0.1.0 has 397 tests and no production tenant yet. Two of our products go first; expect breaking changes before 1.0.
Pinned to better-auth 1.6.33. The SSO and SCIM plugins for 1.7 are a breaking peer change; we stay on 1.6 until the fleet moves, and the package moves with it.
Your billing, your rules. No Stripe integration, no pricing page. One function.
No central login across products. Each app is its own tenant boundary.

Contributing

Issues are open on the repository; that's the intake for now, and every issue becomes a tracked task on our side. Security findings go through GitHub's private vulnerability reporting, not a public issue. Pull requests from outside the organization aren't accepted yet; we'll open that up once the pilots are through.

If your product has been putting off the enterprise tier because it's a tax with no upside for your users, this is the tax paid once. Use it.

Alpha Bros is a studio building small B2B products from Paris. The enterprise layer is the first piece of our platform we've published; more will follow as they prove themselves in our own products.

Building an AI first Startup Studio

Bastien GUILLAUME — Tue, 23 Jun 2026 13:58:25 +0000

This post was NOT generated by AI 🤖.

Our first post was a little over two months ago. About 50 billion tokens later, we're due for an update (and we feel they were well spent).

Basically, we've spent those two months rebuilding ourselves thanks to the lessons learned from Klar launch so this post is mainly going to be technical.

Let's start with some number :

The team grew 📈 — we welcomed Spirit (Taking care of strategy and ops) and Claude (Infra), so the agent team is now 8.
We added one startup to our catalogue — Nomi, a payroll & HR solution for SMBs (an interesting one to build, because it runs straight into legislation) (coming soon to the studio landing page).
We moved from 10 projects to 30 (mainly our internals that we have been rebuilding and are finally tracking) Studio corpus today: ~1,633 tasks (~1,465 done) across those projects, an 850-feature / 83-epic / 92-defect QA tree, and ~200 decision records (50 ADRs + FDR/PRD/RFC).

We moved a lot technically :

We are nearly fully IaC: ~92% IaC-covered — ~1443 managed resources (our gap is mostly managed SaaS - Turso's DBs plus a handful of click-ops items like R2/tunnels/B2/OVH/Tailscale).
We are K8s ready (but not using it yet):
- We have containerized all our projects
- We have Kustomize manifests for all our projects
We have a full fledged deployment control plane (including an ODE)
We have continuous deployment through our entreprise bus — merge to main → event bus → the fleet reconciles and deploys.
We have continous integration : automated code review + merge across multiple orgs.
High Availability everywhere / ~120 self-healing units / 35+ scheduled jobs / a sourceS-of-truth control plane with drift detection / mostly self-hosted infra (~70% of our infra plane / 80% of our always on runtime / 100% of our compute).

We moved also product wise :

We closed ~2500 PRs (merged ~2200). Most of them (~1500) were internals (chore / fix / ci / etc.) but we have been moving on features also (384 PRs).
We have a content pipeline that produces posts and articles weekly, per project, ready to publish to X, LinkedIn, Dev.to and a custom blog — with a human in the loop when we want one (or not, of course).
We have a product pipeline constantly looking for improvements, whether in UI/UX or new features (without forgetting the bug chasing).

In the last few days the gaps have closed and everything converged where we wanted it. We're about to un-gate the main producer we paused while rebuilding — so hopefully our next post will be a launch 🚀.

Last but not least — cost: everything we've produced so far is still under the thousand-euro barrier (we only use plans for AI and we size our VMs carefully).

Bastien, for the team.

Disclaimer: this post was NOT generated by AI — but everything else was.

Test from Publishr

Bastien GUILLAUME — Fri, 03 Apr 2026 11:03:30 +0000

Test content #test

DEV Community: Bastien GUILLAUME