Why a central admin hub

As side projects accumulate, so do admin UIs. Once you reach three to five, costs pile up in three places.

1. Three costs

Operator ramp-up — different sidebars, tables, search positions per site. "Where's the add button here again?" becomes a per-site memory problem.
Developer boilerplate — a new Next project, AuthGuard, OAuth, pagination — reinvented each time.
Audit trail scattered — during an incident, "which site's logs do I check?"

One Next.js app pointing directly at several domain DBs shrinks all three.

2. Why one app with many pools is OK

pg lets you create multiple Pool singletons. Each points at one DB.

export const blogPool = new Pool({ host: 'pg-blog', ... });
export const marketPool = new Pool({ host: 'pg-market', ... });
export const supabasePool = new Pool({ host: '... .supabase.com', ... });

Store blog posts · list market users · pull stats from Supabase — all in one page, pool per step.

3. Skip domain service APIs

"But the domain service already has an API" is the usual objection. Admin needs (soft delete, forced merges, things that require audit) tend to be different concerns from user-facing API. Building admin-only APIs inside each domain service duplicates code.

With direct pool access:

Domain services stay focused on user logic
The admin app writes only the queries it actually needs
Audit logs land in one place

4. Minimal exceptions

Some tasks are simpler delegated to the domain service:

LLM inference — where the GPU / API key / scheduler already live
Heavy crawlers — where Playwright browser pools already live
Notifications — where FCM / SMTP credentials already live

Expose internal-only endpoints (POST /api/internal/...) for these. ~90% stays in the admin app talking directly to DB.

Closing

You don't need a central hub on day one. With one or two services, a hidden admin page inside each service is simpler. The third service is usually where "where did I block that user yesterday?" kicks in — a natural trigger to build the hub.

02-project-setup