I run a single dashboard for the whole company. That screen shows everything at once: what I am working on, what is blocked, which builds shipped, which deploys are up, where the money is, and how the server is doing. One pane of glass.
For weeks, it ran like most internal tools: a server somewhere, a database, and a login. It worked. Eventually I realized the setup was backwards.
The Backwards Version
The old setup looked like this. A Python script on my Mac gathered everything. It read my task files, queried git, pinged my deployed services, pulled server metrics, and assembled a JSON snapshot. Then it pushed that snapshot to a small VPS over HTTP, authenticated with a shared secret. The VPS stored it. When I opened the dashboard in my browser, a React app fetched that snapshot back from the VPS and rendered it.
Read that again. The data was born on my Mac, moved to a server, and then came back to my Mac so I could look at it. The server in the middle only held the data between two trips it did not need to make.
That middle hop was not free. It came with a list of things to maintain:
- An
/ingestendpoint that accepted snapshots. It was a write surface exposed to the internet. - A shared secret to authenticate the push. It needed to be stored, rotated, and never leaked.
- A database on the VPS to persist the latest snapshot.
- Basic auth on the read side so the dashboard was not public.
- A content security policy tuned for a public origin.
- A quiet class of bugs: a push could land incomplete, leaving the dashboard with a snapshot that was partly old and partly new.
On top of all that, every dashboard change required a deploy. Local code and deployed code would drift, and I had to think about why the dashboard looked different in the browser.
That is a lot of moving parts for a tool exactly one person ever looks at.
The Realization
I did not replace the sync with a better one. I deleted it.
Every field in that snapshot originates on my Mac. The task files are on my Mac. The git history is on my Mac. The only thing that genuinely lives elsewhere is the server metrics sample, and I can reach for that over SSH when I actually need it.
So the server in the middle was not infrastructure. It was a detour.
The Local First Version
Now the dashboard runs on my Mac and reads the repository directly. No push, no pull, no server in the loop.
The architecture collapsed to two pieces:
A background refresh. A small Node process regenerates the snapshot every ten minutes by running the same Python gathering engine. It now uses a plain "read everything, return JSON" mode, with the network push half removed. The result sits in memory. Server metrics are pulled on demand over SSH inside that engine, so the one genuinely remote number stays fresh without a daemon shipping it to me on a schedule.
A server that can only read, bound to loopback. A tiny Express app serves that cached snapshot to the React front end and binds to 127.0.0.1 only. The network cannot reach it at all. There is nothing to log into because there is nothing anyone else can reach.
To start it I type npm start. That is the whole operation.
What Got Deleted
This is the part I care about most. Moving the dashboard local first did not add a feature. It subtracted almost everything that was not the dashboard:
- The
/ingestendpoint is gone. With it went the only write surface this tool ever exposed to the internet. - The shared secret is gone. There is no secret left to leak.
- The database is gone. The snapshot is just an object in memory. If it is stale, the next refresh replaces it.
- Basic auth is gone. Loopback is the auth.
- The CSP for the public origin is gone.
- The bug class involving partial payloads is gone. No payload is in flight that can arrive only partly written.
- Deploy drift is gone because there is no deploy. The code I edit is the code that runs.
I removed the service from the VPS entirely. I stopped the process, disabled its web entry, and confirmed that nothing else on that box depended on it. Nothing did. The detour had no dependents because it was always a detour.
My default, when I look at any system I have built, is to ask what would happen if a piece of it did not exist. Most of the time the honest answer is "things would be simpler and nothing would break." Deleting two hundred lines is worth more than writing two hundred lines. This was the same idea applied to a whole server.
The Redesign That Came With It
Since I had the hood open, I also rebuilt how it looks. The old dashboard was warm and editorial: cream background, serif type. Nice, but not the right register for a control panel you scan in two seconds.
So I took it in the other direction: a dense, neutral surface with the feel of Linear and Vercel. It uses a semantic design system with light and dark themes built from the same tokens, a single restrained accent color, tabular numbers, and a bento layout that puts the glanceable KPIs up top and the detail panels below.
Why This Keeps Being the Right Move
The same question applies to any pipe in a system: does the data actually need to go where I am sending it?
A lot of "infrastructure" is really just a habit. We reach for a server because tools live on servers, just as we reach for a database because data goes in databases. But a tool for one user that reads data already sitting on the same machine does not need a server, a database, a secret, or a login. It needs to read a folder and draw some boxes.
The VPS build felt more serious. I trust the one on my Mac because there is almost nothing left in it to break.