On September 1st, 2025, I made a commit in a private repository. The message was "First commit." The FastAPI app was titled "Multitenant (no ORM)." No product name, no roadmap. Just a suspicion that enterprise identity should be simpler than the available options made it.
Seven months and 933 commits later, that experiment is now WeftID: an open source identity federation platform. It aggregates multiple identity providers into a single interface for your applications. You integrate once with WeftID. When you add, remove, or swap identity providers behind it, your applications don't change.
It ships as a Docker Compose stack, MIT licensed. I built it on evenings and weekends, working with Claude. The feature set is complete for the scope I defined, and the API contract is stable. On March 20th I made the repository public.
The problem
A parent company acquires a subsidiary running Okta while the parent runs Entra ID. A contractor workforce authenticates through a separate system. Two companies merge and need unified access before they can consolidate infrastructure. Every one of these situations means someone has to integrate multiple identity sources into multiple applications, usually by wiring each combination individually. That wiring becomes the thing that breaks when anything changes.
WeftID sits in the middle. Identity providers connect on one side, applications on the other. The complexity stays inside WeftID, and everything on either side stays simple.
It also works as a standalone identity provider with built-in authentication, TOTP, email verification, password breach detection, and dormancy management. The full feature list is on the product page.
Design decisions
Row Level Security. WeftID enforces tenant isolation through PostgreSQL Row-Level Security. Every query is tenant-scoped at the database level, and a compliance checker verifies scoping on every database call in CI.
SPs and IdPs are fully independent. Each Service Provider gets its own signing certificate and its own metadata endpoint. Certificate rotation includes a grace period where both old and new certificates are valid, so federation trust doesn't break during transitions. Identity Providers are configured independently with their own metadata URLs and certificates. Nothing is shared between any of them. You can add, remove, or reconfigure any provider without touching the others. The consequence is that a WeftID tenant looks like a wholly separate entity to every SP and IdP attached to it — less standard than a shared-trust topology, but the reason to do it is pluggability, and pluggability is the whole point.
DAG-based groups. Groups form a Directed Acyclic Graph, not a tree, so a group can belong to multiple parents. This models real organizational structures where a team reports into more than one division, or where merged entities need to appear in multiple hierarchies simultaneously. The group graph is rendered in the admin UI with Cytoscape.js, where you can see and manipulate the hierarchy directly.
Server-rendered HTML. The frontend is server-side rendered with standard components. No SPA framework, no build step for the admin UI. The trade is that you can't build the kind of real-time, highly interactive UI that a heavy JavaScript stack makes easy. This isn't that kind of app. What you get instead is a small JavaScript footprint and an uncomplicated frontend that is straightforward to audit.
Strong API coverage. A compliance test verifies that every service layer module is exposed both to the UI and to
the API. The API uses standard OAuth2, with both individual user tokens and client_credentials for B2B automation,
and is fully OpenAPI/Swagger compliant.
Your infra, your data
WeftID deploys as a Docker Compose stack with automatic HTTPS via Caddy. No external dependencies, no telemetry. Your identity data stays on your infrastructure.
Self-hosting means taking on operational responsibility: updates, database maintenance, infrastructure monitoring. That's a real tradeoff. A hosted WeftID offering would serve organizations that want the platform without the ops burden. But for those who need control over their identity data, a self-hosted MIT-licensed system is a strong starting point. The license means the code is yours regardless of what happens to the project.
The default stack is small (FastAPI, PostgreSQL, Caddy), which makes it easy to swap pieces out. Run it on Kubernetes, point it at managed Postgres like AWS Aurora, deploy across regions. None of that requires changes to WeftID itself.
That simplicity didn't happen by accident. It came from how the project was built.
Built with Claude
For the first three and a half months I made 63 commits. The foundation was solid (authentication, MFA, tenant management, an API layer) but the pace was what you'd expect from one person with a day job.
On December 19th, 2025, I committed "Add development workflow agents and architecture documentation." This introduced
the first two Claude skills: /dev for implementing backlog items and /test for test coverage analysis. Eventually
there were ten: /pm for product planning, /compliance for architectural enforcement, /security for OWASP
assessment, /refactor, /deps, /changelog, /tech-writer, /dependabot-merger.
"I used AI to write code" is true but misleading. Each skill has a narrow mandate and is fairly good at sticking to that mandate alone. Time spent sharpening a skill almost always pays back. A more precise mandate produces a more precise implementation. I made every architectural call. I approved every plan. The AI operated within constraints I defined.
Every time Claude makes a flawed assumption (about the architecture, a library, what I actually asked for), I log it in
a THOUGHT_ERRORS.md file, and the lesson feeds back into the skill prompts so the same mistake doesn't recur.
Around the same time, I doubled down on the project. The pace increased substantially, though that probably owes more to the increased time investment than to any single factor.
When you work with an AI that produces code at speed, the question shifts from "can we build this?" to "how do we know
it works?" The answer is the same as it's always been:
small pieces, conceptual clarity, understood before built, verified by tests you don't skip. The /compliance skill
enforces architectural rules on every change, and a compliance checker script verifies the entire codebase in seconds.
Both run in CI. Together they're the guardrails that keep generated code from drifting, over-engineering, or quietly
breaking.
If your process is sloppy, you will get slop. If your process is disciplined, the output reflects that discipline. But there are categories of bugs (concurrency edge cases, subtle cryptographic misuse, security logic errors) that neither disciplined process nor AI reliably catches alone. WeftID mitigates this by delegating all cryptography to audited libraries (no hand-rolled primitives), enforcing architectural rules through a compliance checker that runs in CI, and using defusedxml for all XML parsing. What it doesn't have yet is formal pen testing, fuzzing, or the kind of adversarial review that comes from a second maintainer. That's the honest gap.
Back to foundations
Pageloom rests on foundations I wrote before the first line of WeftID — three pillars covering purpose, craft, and the business. They were written as principles. WeftID was the first chance to find out whether they could survive being lived inside.
So far, they have. Every part of the project — the architectural rules, the compliance checker, the test suite, the
THOUGHT_ERRORS.md log, the ten constrained Claude skills, the MIT license, the self-hosted deployment, the absence of
telemetry — exists because one of the principles required it. The principles weren't applied to the code; they were
encoded into how the code gets written and how the system gets shipped.
After seven months of building this way, I believe in the foundations more than when I wrote them. They haven't yet met a co-maintainer with different taste, a disagreeing customer, or a production incident under deadline pressure. Seven months of solo development is the easy phase. But the constraints held through every decision I did face, and I'm betting they'll hold through the harder ones.
WeftID is Pageloom's first product, and proof that this way of building produces things worth building. I also built it because it was genuinely fun, and because I want to use it myself in whatever comes next. Software built to outlive us starts somewhere.