Building the Boring Part as My Use Case
Every app I want to build needs user management. So I decided to build it properly — once — before building anything else.
There's a moment early in every software project where you have to decide how much to invest in the foundation. You know the one. You're excited about the product, you can see what it should do, and then you realise: before any of that happens, you need authentication. You need multi-tenancy. You need roles, permissions, tenant isolation, SSO. The unglamorous stuff that nobody talks about at demo day.
I've had a bit more time on my hands this year, and I've been using it in the way that feels most natural: helping people out with their ideas and experimenting with some of my own. Consulting on an early-stage product here, prototyping a concept there. And in almost every case, the same thing happens. You get past the exciting part — the thing the product actually does — and you hit the boring part. User management. Authentication. Multi-tenancy. Roles and permissions. The stuff that every application needs but nobody's idea starts with.
Most founders make the pragmatic choice. They reach for an off-the-shelf service — Auth0, Cognito, Clerk, WorkOS, one of the many options available now. And there are good options. Solutions like Clerk and WorkOS offer proper multi-tenant organisation models, RBAC, enterprise SSO, the works. If you want to buy rather than build, you genuinely can.
But here's the thing that's changed: with AI-assisted development, building your own is no longer the enormous undertaking it used to be. The "buy vs build" calculation has shifted. You're no longer choosing between weeks of custom development and an off-the-shelf service that gets you moving in an afternoon. The gap has narrowed — and when you build your own, you own it completely. No per-seat pricing tiers, no feature gates, no dependency on someone else's roadmap.
Over my career I've seen many different flavours of user management across different applications. Some have been done well — clean separation of concerns, sensible permission models, proper tenant isolation. Others, less so. What I wanted was to take the best of what I've seen — the use cases and patterns that actually work in production — and build them into a reusable component. Not a theoretical ideal, but something practical, informed by years of seeing what holds up and what doesn't, that any of these projects could plug into.
That felt like the right bet. And it also felt like an ideal opportunity to write about the process — which is how this blog started.
So I made a different bet: build user management as a proper common component — a standalone service with its own API, its own data model, its own deployment pipeline — and treat it as the first real deliverable.
What Porth actually is
Porth is a multi-tenant user management service. It handles organisations, tenants, users, roles, permissions, and the claim-based authentication that ties them together. It's designed to be cloud-agnostic — any application can integrate with it through a standard API and event-driven replication, regardless of where it's hosted.
The name comes from the Welsh word for "portal" — and from my perspective it just makes a really good project codename.
At the time of writing, Porth has 41 API endpoints across seven resource domains, over 1,500 passing tests, a fully automated CI/CD pipeline, and infrastructure-as-code for everything. It supports multiple identity providers (Auth0, Google Workspace, Microsoft Entra, any OIDC-compliant provider) through a custom authorizer that handles multi-IDP JWT validation with pre-compiled claim mappings.
That last sentence probably sounds like a lot. It is. And that's kind of the point.
The building block mindset
The decision to build Porth properly wasn't just about avoiding rework. It was about recognising that some pieces of software are genuinely reusable if you invest in making them so.
Multi-tenant user management is one of those pieces. Every SaaS application needs it. The requirements are well-understood. The edge cases are well-documented. And the consequences of getting it wrong — data leaking between tenants, permissions that don't quite work, authentication flows that break when you add a second IdP — are severe enough that it's worth doing carefully.
By treating Porth as a first-class project — with a proper PRD, architecture decisions documented as ADRs, sprint planning, QA reviews, the works — I'm building something that can serve as the foundation for multiple products. But I'm also building something that demonstrates a way of working that I think is becoming increasingly viable for solo founders and small teams.
An opportunity to show the work
Here's the other reason I'm writing about this: building Porth has been an education. Not just in the technical architecture, but in how to run a full engineering process — from PRD to deployment — with AI agents handling most of the execution.
I'll write more about that in future posts. But the short version is: Porth is being built by one person (me) with AI agents orchestrated through Claude Cowork, connected to Jira, Confluence, GitHub, and AWS via MCP (Model Context Protocol). The agents handle sprint planning, code generation, test writing, PR creation, and documentation. I handle the architecture decisions, the product direction, and the quality review.
That's a way of working that didn't exist two years ago. It's worth documenting — not as a sales pitch, but as an honest account of what works, what doesn't, and what the limits are.
Publishing the architecture documentation is a freebie for the community. Anyone building multi-tenant systems can learn from the patterns and the trade-offs. The founder diary is the human story behind it — the decisions, the mistakes, and the process of building something at a scale that used to require a team.
What's coming next
This is the first in a series. Here's roughly what to expect:
Architecture deep dives — Starting with how multi-IDP authentication works (supporting multiple identity providers, pre-compiled claim mappings, and why they matter). Then data modelling for multi-tenant RBAC, event-driven replication, and the security model.
Ways of working — How the toolchain is set up, how MCP connects everything, what it actually looks like when an AI agent picks up a Jira ticket and delivers a PR. The honest version, including the parts that are harder than they look.
The build diary — Regular updates on what's happening with Porth. What shipped, what got stuck, what I learned that week. No production value, just notes from the trenches.
All the architecture documentation will live in a public GitHub repository alongside this blog. The code itself stays private — this is about sharing the thinking, not the implementation.
If you're a founder building multi-tenant applications, or you're curious about what agent-driven development looks like in practice, I think you'll find something useful here.