Building a Custom Admin Platform Instead of Buying One

The build-vs-buy question, answered honestly

An off-the-shelf admin tool gets you a working CRUD interface fast. What it doesn't get you is control over exactly how authorization, validation, and audit logging interact with the rest of your application -- and for anything handling real user data, that interaction is the part that actually matters.

We build the admin layer ourselves, on the same stack as the public site, using server-side actions instead of a separate API layer.

What that actually buys

Every admin write goes through a server action that runs the same authorization check, the same input validation, and the same audit-log call, in the same codebase as the feature it's modifying. There's no separate admin-tool permission model that has to be kept in sync with the database's own row-level security -- there's exactly one source of truth for "who can do what."

The failure mode this is designed around

The most serious version of this is what we'd call the lockout problem: an authorization system that protects against a stranger getting admin access, but not against an authorized admin accidentally locking themselves out. A UI that simply hides the "delete this account" button when you're looking at your own account isn't a real safeguard -- it's a missing safeguard with a UI patch over it. The actual protection has to live in the server action itself: a direct check that the target of a destructive action is never the account making the request, and never the platform's last owner account. Server-side, not just a hidden button.

We found and fixed exactly this gap in an early version of our own admin platform -- which is the kind of thing a decision log exists to capture honestly rather than quietly patch and forget.

Where this gets harder

Self-service password resets, account promotion flows, and audit logging all sound straightforward until you ask "what happens if this specific step fails halfway through." A new admin account that gets created in the authentication system but never gets its corresponding permissions record written is now a real account that can sign in and do nothing -- worse than no account at all, because it looks like a bug report instead of an access-control decision.

Buying an admin tool means trusting someone else got these specific edge cases right for your exact authorization model. Building it means owning the responsibility -- and the audit trail -- directly.

For more on the same default-deny philosophy this admin platform runs on, see What RLS-By-Default Actually Costs You.