One front door — a portal that turns internal apps into modules

Instead of a sprawl of standalone web apps, one SSO portal: a single login, per-user access tiles, an aggregated task feed, and an architectural rule that every new system ships as a module inside it.

Logins

was one per app

300/yr

Hours returned

≈ $14K of staff time

$15K/yr

Platform savings

vs. commercial intranet/SSO

as modules

New features

the architectural default

Once you start building internal tools, you get a sprawl problem fast: a dozen apps, a dozen logins, a dozen URLs nobody remembers, and no single place to see what's on your plate. I'd shipped enough systems — asset tracking, change management, complaint tracking, IT requests, shipping, QC — that the sprawl was real.

So I built a portal. One sign-in for any active employee, a home page of system tiles showing only what each user has access to, and a task feed aggregated live from every downstream app. The portal never keeps its own copy of who works here — it looks identity up from the asset system at login and signs a token the other apps trust. The rule going forward: new capability ships as a module inside the portal, not as another standalone app.

Stack

Next.js 15 client
Express API
PostgreSQL (credentials + audit)
JWT bridge downstream apps accept (path to full SSO)
Service-token directory lookups against the asset system

The sprawl problem

Building internal software is its own kind of success trap. Each app solves a real problem, but the tenth app means ten logins, ten URLs, and ten places to check whether something needs your attention. The collection becomes harder to use than any single piece of it.

The decision: a hub, not another app

The portal is the front door. Every system registers a tile (gated by access) and a task source. The non-obvious call was what the portal should NOT do: it should not own identity. A central app that keeps its own user table just becomes one more place for that data to drift.

Identity stays in exactly one place

At login the portal looks up the employee's name, department, and manager live from the asset-tracking system via a scoped service token, then signs a JWT the downstream apps accept. There's one source of truth for who works here, and the portal reflects it rather than copying it. Onboard or offboard someone in one place and every surface follows.

An aggregated task feed

Each downstream app exposes an integration endpoint. The portal pulls from all of them into one unified to-do feed, so a user sees everything waiting on them — an MOC approval, an IT request, a QC step — in a single place instead of hunting across systems.

Modules, not apps

The rule that keeps the sprawl from coming back: new capability is a module inside the portal unless there's a hard reason it can't be. One auth model, one navigation, one place to look, and over time one deployment target. It's a deliberate constraint that trades a little short-term flexibility for long-term coherence.

Why it matters

For a one-person IT organization, consolidation is leverage. The portal is the thing that makes a growing suite of internal software maintainable by one person — and the thing that makes it feel, to everyone else, like one product instead of a pile of side projects.