The Dashboards I Actually Run merlinoai.com On
I don't build dashboards in a folder and demo them later. I ship them to a real URL the same week and run them on live data. That habit is why my stack is not one app but a family of small, working surfaces.
The dashboard family behind the site
Behind the public site I run a set of private ops dashboards, each one a shipped tool doing one job: the fleet mesh, the Master Brain, the workforce view, deploys, and proof of work. They sit behind a login because they show live operational data, but they are the same kind of thing as the public ones: real apps on real URLs, not mockups sitting in Figma waiting for a client sign-off.
They're live, indexed under one registry, and they pull real fleet numbers rather than a static screenshot: real agents across real machines, active-now counts, open and closed task totals, real last-active timestamps. No fake heartbeats. If a number looks off, it's because a real process is stuck, not because someone forgot to refresh a mock.
That distinction matters more than it sounds. A dashboard with fake heartbeat data trains you to stop trusting your own tools. A dashboard that shows a stalled agent as stalled trains you to go fix it.
What "no login wall" actually buys me
Two of my public builds skip authentication entirely, on purpose. https://personality-atlas.vercel.app is the fleet-typing tool I used to assign every agent in the ecosystem a 16Personalities type, an Enneagram number, and a DISC profile, so I could reason about how an agent behaves under pressure instead of guessing. https://agentvaults-3d.vercel.app is a 3D force-directed graph of the same fleet, so the relationships between agents are something you can spin around and look at instead of something you have to hold in your head.
Both shipped clean: a working theme, no broken layout, a live URL that returns a real 200 and lets anyone click through with nothing to sign into. That's a deliberate constraint I put on myself. If a tool only works behind a login, it's easy to let it half-work and never notice. If it's public with no wall, every broken state is visible to me first, before it's visible to anyone else.
Streaming the build, not the highlight reel
Shipping live also changes what "streaming the build" means for me. I'm not staging a demo take after the fact. The dashboard you'd watch me build on is the same dashboard sitting at that URL an hour later, still pulling from the same Convex tables, still showing whatever state the fleet is actually in. If an agent's last-active timestamp goes stale mid-stream, that's not an editing problem, that's a debugging problem, live.
That's also why I don't spin up a new dashboard for every idea. Before I add another dashboard, I check what's already running and ask whether the job belongs on an existing surface or genuinely needs its own. I keep a running registry of everything I've built specifically so that question has a fast answer instead of a guess.
Why this is the discipline, not the flex
None of this is about proving activity. It's about removing the gap between "I built something" and "you can go look at it." Every one of those dashboards, and both of the standalone public tools, exists because I decided a private folder wasn't good enough proof, for me or for anyone watching. A dashboard that only I can see is a claim. A dashboard at a real URL, pulling real data, is a fact.
If you're building your own agent tooling and wondering whether to keep it internal until it's "ready," my answer is that ready is a moving target and a live URL is not. Ship the subdomain. Let the timestamps be honest. Fix what's actually broken instead of what's embarrassing on camera.