███████╗ ██████╗ ███╗   ██╗██████╗ ███████╗██████╗ ██╗███████╗
██╔════╝██╔═══██╗████╗  ██║██╔══██╗██╔════╝██╔══██╗██║██╔════╝
█████╗  ██║   ██║██╔██╗ ██║██║  ██║█████╗  ██████╔╝██║█████╗
██╔══╝  ██║   ██║██║╚██╗██║██║  ██║██╔══╝  ██╔══██╗██║██╔══╝
██║     ╚██████╔╝██║ ╚████║██████╔╝███████╗██║  ██║██║███████╗
╚═╝      ╚═════╝ ╚═╝  ╚═══╝╚═════╝ ╚══════╝╚═╝  ╚═╝╚═╝╚══════╝

Every SaaS rebuilds the same infrastructure — auth, billing, teams, permissions, messaging. AI just made it faster, and less consistent. Ask an LLM to build it and you get a different version every session: different security calls, nothing audited, thousands of tokens spent on boilerplate instead of your product.

Fonderie is the standard that ends the re-derivation. Each piece — auth, workspaces, billing, messaging, permissions, events — is an audited, reviewable brick that snaps into @fonderie/core and runs in your process against your database. Install it and any assistant (Claude Code, Cursor, Codex, Gemini CLI) builds on a backend it already knows — the same way, every time.

It's the bet HTTP made: standardize the boring parts. The web has GET, POST, and a 404 nobody re-argues. The SaaS backend never got its equivalent — so twenty years of engineers keep re-deriving auth and re-shipping the same flaws, and LLMs just do it faster. Fonderie is the missing standard, so you spend your time on the only part that's actually yours.

The wedge is the first five systems. The market is the entire infrastructure budget of every AI-built company. We start where every SaaS starts — auth and billing — and the same control layer extends to notifications, permissions, mobile, and everything the AI builds next.

No LLM required: it's plain TypeScript. Take one brick or the whole set. No seats, no rent. MIT.

This repo ships a Claude Code skill that teaches an assistant to reach for @fonderie/* bricks instead of hand-writing auth, billing, or permissions. It loads automatically — say "add subscriptions" and the assistant wires @fonderie/billing instead of improvising Stripe glue.

Three files, with a strict generated/curated split:

import { FonderieApp, defineConfig } from '@fonderie/core';
import { AuthModule } from '@fonderie/auth';
import { WorkspacesModule } from '@fonderie/workspaces';

const app = await new FonderieApp(defineConfig({ basePath: '/v1' }))
  .register(new AuthModule())
  .register(new WorkspacesModule())
  .boot();

app.listen(3000, { name: 'my-api' });

Already on Express, Hono, or Koa? The adapter bricks (adapter-express, adapter-hono, adapter-koa) mount Fonderie inside your existing app instead.

New here? The Getting started guide walks through install, booting an app, and adding bricks step by step.

Prefer to read code? The examples/ folder has minimal, deploy-ready apps for Hono, Express, and Koa.

The standard doesn't stop at the API — Fonderie is end-to-end. Every capability ships headless bindings (React hooks, Vue composables, React Native hooks — thin layers over @fonderie/client) and a matching set of prebuilt screens. So the same assistant that wires @fonderie/billing on the backend drops in a working subscription UI on the frontend, on whatever framework you ship. Take the hooks and build your own UI, or take the screens and ship today.

Security is the whole reason a standard beats regenerated boilerplate: the audited path is the default path. None of this is opt-in, and every claim is in the source — read SECURITY.md and the package tests.

• Auth fails closed. A weak or placeholder JWT secret is fatal in production; the app refuses to boot rather than sign forgeable tokens.
• Credentials done right. bcrypt password hashing, TOTP MFA with secrets encrypted at rest (AES-256-GCM), and every session revoked on password change.
• Least privilege by default. Workspace-scoped RBAC with parameterized, tenant-isolated queries; rate limiting on by default in front of login, registration, reset, and MFA.
• Tamper-evident audit trail. The event log carries a keyed per-event HMAC — altered or forged history is detectable.
• Privacy built in. Per-user data export (SAR) and configurable retention / erasure for events and deleted accounts.
• Hardened transport & supply chain. HSTS and secure-by-default response headers; CI fails on high-severity advisories; releases publish over OIDC with signed provenance — no long-lived tokens.

We don't just claim it — we benchmarked it. Thresholds locked before any data, then the same growing app (auth → billing → teams → a security pass) built three ways, three times each, on claude-opus-4-8. 36 sessions.

• Fewer holes, less code. From-scratch builds shipped a hard-coded secret in 2 of 3 runs; the Fonderie builds, zero — the audited brick reads it from the environment and throws if it's missing. And in roughly ⅓ the code.
• The SDK earns its context. The project brain loads only what a task touches, so the model spends its budget on your product, not re-reading the SDK — a 0.383 context ratio vs. the full skill (fair, resident-after-read accounting). Full derivation: BATCH-RESULTS.md.

Harness and raw runs are all in experiments/phase41-2026-07/. Re-run it and check — that's the point.

npm install
npm run build              # build all workspaces
npm test                   # run all tests
npm run docs:signatures    # regenerate the skill's API reference from source

Changed any package's public surface? (new export, endpoint, config field, constructor parameter) — run npm run docs:signatures and commit the updated .claude/skills/fonderie/SIGNATURES.md + signatures/ alongside your change. The generator extracts signatures from src/ with the TypeScript checker and its output is deterministic, so CI can enforce freshness:

npm run docs:signatures && git diff --exit-code .claude/skills/fonderie/SIGNATURES.md .claude/skills/fonderie/signatures

Route tables and the wiring example in API.md are curated by hand — update them when a module gains or changes an endpoint.

Work flows through dev and is promoted to main, which is the only branch that publishes:

feature/*  ──PR──▶  dev   (CI runs; peer review)
dev        ──PR──▶  main  (CI runs; final review)
merge to main  ──▶  automated npm publish

• Add a changeset on your feature branch for any user-facing change: npx changeset (pick the packages and bump levels). It rides through dev to main.
• CI (.github/workflows/ci.yml) runs on every PR targeting main or dev, and on pushes to main: build, typecheck, tests (including the real Postgres + Redis concurrency tests for @fonderie/rate-limit), the docs:signatures freshness gate, and the validation audit.
• Release (.github/workflows/release.yml) runs only on push to main. It opens a "Version Packages" PR consuming pending changesets; merging that PR publishes to npm over OIDC Trusted Publishing with signed provenance. Nothing on dev (or any other branch) can publish.
• main should be a protected branch (require PRs + a green CI check, no direct pushes) so "only main publishes" is enforced, not just conventional.

To publish manually instead (e.g. before CI is set up): npx changeset version then npx changeset publish.

fonderiejs.com · follow @fonderiejs

MIT © Fonderie, Inc.