Why Ops HUD exists.
Every signal a solo operator wakes up checking — in one glanceable dashboard, on the desktop, plugin-driven.
The shape of the problem
If you run your own software, you spend a chunk of every morning bouncing between dashboards. Stripe to check MRR. GitHub for the CI status. Discord to scan mentions. Freescout for the support queue. Each one is a tab, a context switch, a small tax.
Cloud SaaS dashboards are great when you live inside one of them. For a solo operator running three or four products, the per-product dashboard is the wrong unit of work. You don't want every Stripe chart — you want this number, right now. You don't want the GitHub Actions run history — you want is anything failing on main, yes or no.
How it's built
The host is a small native binary (Rust + egui + WebView2). The
widgets are Python scripts — sidecars — that the host launches
and polls. The protocol between them is four stdout events: count, status, list, alert. That's it. If you can write a Python script
that prints JSON every five seconds, you can ship an Ops HUD
plugin.
Local by default
The widget values never leave your machine. The optional cloud account stores layouts and team-relay metadata so you can share a dashboard with a teammate — but the data underneath each widget is read locally by the plugin running on your laptop. That's the architecture, not a privacy promise we'll quietly reverse later.
One person built it
Ops HUD is built by Gorgan — one person, transparently. It's a sister product to Focus HUD, the desktop focus timer. Same brand family, same plugin DNA, same conviction that the most valuable desktop software is the kind that fades into the periphery until you need it.
Have a plugin idea? A signal you wish you could glance at? Email the maker via the gorgan.dev contact form.