Why I'm Building a Dashboard Before I Build Anything Else

<p>I've got AIREP, Find a Sign, Sweeper Parts, Nova, and this website all moving at once. For a while I told myself that was fine — I'd just keep it in my head, check in on each one when it needed attention, and trust my own sense of priority. That worked when I had two projects. It stopped working somewhere around project four.</p><p>The tell was small but consistent: I'd sit down to work and spend the first twenty minutes just figuring out where I'd left off. Not on the hard technical problems — those I remembered fine — but on the boring logistics. Which client was waiting on a reply. Which branch had an open PR. Which bug report on Sweeper Parts I'd triaged but not actioned. None of that is interesting work, but all of it costs attention, and attention is the actual scarce resource here, not time.</p><p>So the current build is a multi-project orchestration dashboard — a single workspace that shows work-in-progress, open issues, and recent activity across everything I'm running. Not a project management tool in the Jira sense. I don't need story points or burndown charts. I need something closer to a cockpit: what's live, what's broken, what's waiting on me versus waiting on someone else.</p><p>The obvious approach would be to bolt this onto an existing tool. I looked at that and backed away from it fast. Every general-purpose PM tool assumes a team, assumes tickets get created by humans typing them in, assumes the overhead of maintaining the tool is worth it because multiple people benefit from the shared state. None of that applies to a solo operator running parallel projects with an AI system doing a chunk of the operational work. The overhead of feeding a generic tool would exceed the value of using it.</p><p>What I actually want is for Nova to populate the dashboard. Nova already touches most of these projects in some capacity — it's the backend AI service behind keirantrace.com, it has ERP specialist agents that understand AIREP's data model, it's been used across client work. If Nova already knows the state of a project because it's been working inside it, there's no reason I should have to manually transcribe that state into a tracking tool. The dashboard should assemble itself from what Nova already knows, plus whatever raw signals I feed in — repo activity, open issues, recent notes.</p><p>This is the same pattern I keep coming back to across everything I build right now: don't add a system that requires me to maintain it in parallel with doing the actual work. If a tool needs constant manual upkeep to stay accurate, it decays into fiction within a week and then it's worse than having no tool, because now I'm making decisions off stale data and feeling falsely informed.</p><p>It's a fairly boring piece of infrastructure to be excited about, I'll admit. There's no clever algorithm here, no interesting architecture decision worth a deep dive. But I think this is exactly the kind of thing that quietly determines whether the AI-as-core-competency bet actually pays off. It's easy to point at Nova doing something flashy — drafting a contract, triaging a support ticket, writing this post — and call that the leverage. The less visible leverage is Nova removing the coordination tax that comes with running five things instead of one. That tax is what kills solo operators long before any single project fails on its own merits.</p><p>I don't have this fully built yet. Right now it's closer to a collection of scripts pulling status from different sources than a real dashboard. But the shape of it is clear, and clarity on shape is usually the hard part. The rest is just wiring.</p>