The admin panel nobody sees

The most worked-on pages I have ever shipped will never be indexed, linked, or seen by another person. The public half of this site is a storefront you can read in an evening. The other half, the owner console behind the login, is where the months actually went.

What lives there: editors for every project, post, and link on the site, an integrations page that connects LinkedIn, and a system section with two pages I am unreasonably fond of. One is the route registry view: all ninety-three routes the site currently serves, public, API, and admin, are declared in a single file, src/core/routes.ts, and the sitemap, the robots file, and the console navigation are all derived from that declaration. The registry page just renders it, which means the console contains a complete, honest map of the surface area, and a route that is not in the map cannot appear in any of the derived places either. Each entry also declares who can reach it, public, unlisted, user, owner, or token, and the file's own comment states the standard I hold that field to: a wrong access tag is a security misstatement, not a cosmetic bug.

The other is the server cockpit. My VPS runs the Discord bot under PM2, and a systemd timer on the box reports every thirty seconds: it shapes the PM2 process list into a snapshot and POSTs it to the site. The console polls that snapshot plus the host's VM telemetry every fifteen seconds and draws it: per-process CPU and memory as stacked meters against the machine's totals, two hours of sparkline history, staleness and crash-loop alerts, and reboot and stop controls behind confirmation dialogs. The first server render waits on two live calls to the host's API, so the tab has a route-level loading skeleton purely so that clicking Server responds instantly instead of hanging for the slower of two upstreams. That is a public-site courtesy applied to an audience of one, which is the theme here.

The direction of that data flow was the one real design decision in it. The VPS pushes; the site never reaches in. There is no monitoring port open on the box, no inbound path at all for this feature, because monitoring that widens the attack surface of the thing it watches is a bad trade. A reporter that can only speak outbound costs one systemd timer and removes an entire category of exposure.

The argument for polishing any of this, when the audience is one person who already knows where everything is: internal tools do not die of bugs. They die of friction, quietly. Nobody files an issue against your own dashboard; you just stop opening it, and then you stop knowing what your server is doing, and the tool has failed without ever breaking. Every small roughness, a slow load, a layout that jumps, a number you have to squint at, is a tax on checking, and enough tax means you stop checking. So the cockpit gets a loading skeleton and honest meters for the same reason the public site gets responsive breakpoints. Different audience, same failure mode: a surface people quietly stop using.

And there is a part I will just admit. I open the server tab when nothing is wrong, watch four processes breathe in their meters, and close it, the way you check on a garden you already watered. Dashboards you enjoy are maintenance you will actually perform. That is not a metric I can defend in a design review, and it has kept the server healthier than any alert threshold I have set.

The storefront gets the visitors. The workshop is why the storefront stays standing.