2026-06-27

Why I'm Building Dev App Launcher: A Menu Bar Fleet for Too Many Dev Servers

building · product · buildinpublic

Today I hit the same wall I hit every few weeks. A Cursor agent was mid session on one project, three other dev servers were parked in random terminal tabs, and my fan had been screaming for ten minutes before I figured out which process was actually causing it. I killed the wrong one, lost a hot reload, and spent five minutes digging through scrollback just to find which port belonged to which repo.

That's usually the moment I open a new repo and start building the fix instead of finishing what I was supposed to be working on.

The actual problem

I'm never running one app. On a normal week I'm bouncing between several products, each with its own dev server, its own ports, sometimes its own production preview build, plus whatever side project I started two weekends ago. Add Cursor running multiple agent sessions in parallel, and the terminal stops being a workspace and starts being a liability.

image.png

The specific failure modes I keep hitting:

  • I forget a server is running until the laptop heats up
  • Dev and prod preview commands get mixed up because they live in the same tab
  • A Cursor agent finishes editing code, and I still have to manually rebuild, restart, and refresh to see if it worked
  • Logs are scattered across panes with no quick way to grab one and paste it into a bug report

None of these are hard problems on their own. Together they're a constant, low grade tax on every coding session, the kind of friction that never makes it onto a roadmap but still eats an hour a day.

What I'm building

I'm calling it Dev App Launcher. It's a native macOS menu bar app, built with Tauri, that treats my machine like a small fleet instead of a pile of unrelated terminal tabs. Register a project once, and it remembers the scripts, ports, and commands. After that, everything is one click from the tray.

What that gets me:

  • One popover showing every registered app, running or stopped, with live CPU and memory per process
  • Start, stop, restart, and build per app, with a separate toggle for dev versus production preview
  • A folder scanner that pulls every package out of a monorepo in one pass instead of registering each one by hand
  • Logs streamed inline, with a one click export for when something breaks and I need to paste the output somewhere

The piece I actually care about most is the Cursor integration. When an agent session ends, the launcher gets a hook, rebuilds the project, restarts the production preview, and sends a notification. If the build fails, it can hand the error straight back to a Cursor agent for another pass. That's the loop I want: code changes, preview updates, nothing manual in between.

Why today specifically

I'm vibe coding fast enough across enough products now that the manual rebuild step has quietly become the slowest part of my workflow, slower than the AI generating the code in the first place. Everything else in my stack already runs itself: Cloudflare deploys, the ops dashboard, the build servers on the two M2 minis sitting idle in the corner. The one thing still living entirely in my head and my terminal history is "which app is running where, and did I actually restart it after that last agent run." That's a small enough problem that it should have been solved months ago, and an annoying enough one that today I finally stopped putting it off.

Where it stands right now

Early. The core loop, register an app, see it in the tray, start and stop it, is the part I'm building first. Resource monitoring and the Cursor hook come right after. Things like team sync, Linux support, or proper HTTP health checks are on the list, but they're not built, and I'm not promising them yet.

What's next

I'll run it on my own stack first, the same products that gave me the problem in the first place. If the Cursor loop holds up the way I'm hoping, closing the gap between "agent finished" and "preview is live" with zero steps in between, this becomes the thing I open before I ever open a terminal.

#buildinpublic

This one's mostly for me. If you're also running more local services than you can comfortably track in your head, I'll post the next update when there's something to actually click on.

More posts