You can map the last six months of my AI journey entirely through abandoned dashboards.
Three for OpenClaw. Three for tracking LLM spending. A recipe builder that died mid-bake. Two Hermes experiments that lasted about a day each. And most recently, a project management dashboard for Pi Coding Agent. Still warm, still unfinished, already abandoned.
That’s ten projects. Give or take. None of them survived.
Where It Started
I blame Alex Finn.
Not really. He’s not wrong about what he needs. Finn’s YouTube channel has been pushing “Mission Control” as essential infrastructure for anyone working with LLM tools. Build a dashboard. See everything. Control everything. He even published a whole prompt library for it. The production value makes the pitch feel inevitable.
He wasn’t alone. This was late 2025. Andrej Karpathy had just started talking about “vibe coding,” the idea that you could describe what you wanted in plain language and have an AI build it. Retool put out a report showing 78% of developers expected to build more custom tools in 2026, often replacing SaaS products with AI-generated dashboards. The message from every direction was the same: of course you need custom infrastructure. Everyone’s building one.
So when OpenClaw (then still called ClawdBot) produced files everywhere: conversations, outputs, config dumps, a whole filesystem with no obvious way to navigate it. The conclusion felt obvious. Build a dashboard. See everything. Control everything.
I built one. Then another because the first one didn’t feel right. Then a third because the second one was getting messy but I’d learned things and this time it would be clean.
It wasn’t clean. Nothing after that was clean either.
The Cost Tracking Trilogy
Somewhere along the way, I decided the real problem wasn’t navigation. It was money. These tools cost money to run. Someone should track that. Someone should build a dashboard for it.
So I built three cost trackers. Three separate attempts to solve a problem I could have solved with a spreadsheet in twenty minutes.
There’s a term for this: dashboard sprawl. Internal tools start as “quick projects” that become permanent maintenance sinks. Every API change, every new metric you want to track, every framework update—they all demand manual intervention. You end up managing more custom software than actual work. I was living it. Each tracker started with enthusiasm and stalled when I realized I didn’t enjoy looking at my own spending closely enough to maintain a web application for the privilege.
The pattern had solidified: new tool arrives, excitement spikes, Mission Control construction begins, interest evaporates somewhere around the CSS grid layout, another body in the graveyard.
The Accident That Worked
The recipe builder was supposed to be different.
I wanted something that could take ingredients I had on hand and suggest recipes that fit my dietary restrictions. Peritoneal dialysis patient here; phosphorus and potassium are daily concerns. A proper web app with a database, search, filtering, the works.
I got partway through the frontend and ran out of patience. Not patience with the idea—patience with the build. I needed something that worked now, not three sprints from now.
So I did something dumb. I wrote a quick skill file for OpenClaw instead: a text prompt wrapped in some YAML, no database, no UI, no deployment pipeline. You feed it ingredients, it suggests recipes. That’s it.
It worked immediately. Better than anything I’d spent weeks building in React.
When I migrated from OpenClaw to Hermes Agent at the end of February, that skill came with me. Got improved over time. Still runs today. Still gets used whenever I’m staring at the fridge wondering what’s safe to cook.
That throwaway hack outperformed nine carefully planned dashboards combined. Not because it was better engineered—because it existed, I finished it, and it did exactly one thing well enough that I never had reason to replace it.
What’s Actually True Now
Here’s my current setup for managing everything:
cmux (terminal multiplexer). Sublime Text. macOS Finder.
That’s it. No Next.js state to manage, no auth layer to maintain, no “quick deploy” that eats a whole weekend debugging environment variables. I open a terminal, I type a command, something happens. When it doesn’t work, I can see why in the same window where I ran it.
I like building CLI tools. They can get complicated. TUIs have come a long way in recent years and they can look sharp. But they don’t carry the same maintenance debt: no mobile breakpoints, no framework update that breaks your component tree next quarter, no hosting bill for something only you will ever use.
Dashboards sell you visibility. That psychological comfort of seeing everything laid out in cards and charts. It feels productive. It feels like control. Then reality sets in: the thing you’re looking at needs updating, the data source changed its API format, the chart library dropped support for your version, and suddenly your dashboard of control is just another maintenance obligation.
CLI tools don’t pretend to give you that comfort. They give you output instead. You run the command, you get the answer, you move on. The tool doesn’t need to look impressive because nobody’s watching it except you, and you already know what you asked for.
The Glitch Isn’t Fixed
I still feel the pull, though. That’s the part I’m not proud of.
Pi Coding Agent showed up. I liked it immediately. The coding experience is good. So naturally, within about a week, I’d started building a project management dashboard for it. A way to manage multiple projects, start coding sessions, track progress across codebases.
Sounds reasonable. Sounds like something a person who likes a tool might want to build.
I didn’t finish it. I already stopped working on it. The same graveyard, fresh body.
I tell myself it’s fading. I hope it fades. But the reflex is still there—new tool lands, brain says “build Mission Control,” hands open a code editor before the conscious mind catches up.
Maybe acknowledging it is the first step. Or maybe I’ll be writing a follow-up post in six months about the twelve dashboards I built between now and then. Ask me then.
What I Actually Learned
Not “dashboards are bad.” Some people love them. Finn clearly does, and his setup works for him. The lesson isn’t that web interfaces are universally wrong for personal tooling.
The lesson is simpler: I don’t finish dashboards. I start them, enjoy the initial architecture phase, lose interest somewhere around implementation details, and move on to the next thing before the current one ships.
But I do finish small tools that do one thing: skill files, shell scripts, little CLI utilities that solve today’s problem without pretending to solve next year’s too.
That’s not a downgrade. That’s just knowing what shape your work fits into. Maybe the next time my hands open a code editor before my brain catches up, I’ll remember that.