Server management platforms don’t need dashboards.

Let me explain.

I’ve been building Serversinc on and off for around four years now, building it, scrapping the solution, then rebuilding again. Each cycle I’d recreate the same problems, the same friction, the same burnout, which eventually led me to scrap it in the first place.

When I first started, I’d used tools like Forge, Heroku, and AWS. Dashboards felt like the obvious choice because that’s simply what these platforms had, so when I was drafting plans for Serversinc, a dashboard was automatically part of the spec without much question.

Four years later, I’ve realised something important: server management platforms don’t need dashboards, or at least not dashboards with buttons and interactions for every single thing the API can do.

Towards the end of last year I took a break from Serversinc to work on other ideas, but I also took a step back and looked at the bigger picture. Two things became very clear.

First, the dashboard was consuming most of my development time, probably around 70% of it, from designing layouts and forms to handling validation, error states, and everything inbetween. Then I’d tweak something in the API and immediately need to update the UI to match. That cycle slowly burned me out every single time and is what kept pushing me toward scrapping the whole project.

Secondly, this kind of work doesn’t really belong in a web dashboard at all. It belongs in the terminal, in my editor, in the same context where I’m already doing my work.

That made me start thinking about how I’ve actually used dev tools in the past and, surprise surprise, most of them have been via a CLI tool; cloudflare, git, opencode to name a few.

And I don’t think that’s just me. Most engineers work this way. Any time we don’t have to break context is a good time.

Even with monitoring tools like Sentry, we’re not sitting there refreshing dashboards. We set up alerts and notifications, and when something breaks, we get pinged and deal with it. The dashboard exists, but it’s not where the work actually happens.

The pattern became obvious: for operational tools, tools you use to do work rather than just observe state, the best interface is often no interface at all. A solid API paired with a good CLI is usually enough.

Meanwhile, the actual server management part of Serversinc was working fine. The API was solid and did what it needed to do, but I was spending most of my energy on the layer above it, trying to make buttons feel right when nobody, including me, actually wanted to click those buttons in the first place.

I let those two realisations sit for a while, thinking them over throughout the week instead of immediately jumping into another rebuild. I wrote down what I actually needed from the tool, how I was using it day to day, and how it could fit more naturally into my workflow.

Then came decision time: do I try to bend the existing codebase into a CLI-first shape, or do I rebuild it again, for the fourth time?

The answer was rebuild.

It turned out I’d massively overengineered things just to support the dashboard. Countless CRUD endpoints existed solely to keep the UI in sync. Features felt essential when staring at a web interface but didn’t really matter for the core problem. I’d even started duplicating Docker functionality just to have more things to display.

Rebuilding let me slim everything down, letting Docker do Docker’s job and letting Serversinc focus on its own job instead of trying to do both, badly.

Stripping all that away felt good, like finally admitting I’d been solving the wrong problems.

So I started building v4, CLI-first this time. No dashboard to maintain, no forms to validate, no loading states to perfect, just a solid API and a command-line tool that talks to it.

As a sidenote, CLI-first tools age surprisingly well in the era of AI. Agents already understand terminals. A good CLI gives them a universal interface, and a simple --json flag is often enough to make output easy to reason about and automate.

Development is faster because I’m no longer context-switching between backend logic and UI concerns. When I add a feature to the API, I add a command to the CLI and I’m done. There’s no figuring out where it fits in a navigation menu or designing the perfect interaction pattern. The codebase is smaller too, which only adds to the speed and ease of development.

But the biggest difference is how it feels to use. I’m actually using Serversinc now, not because I’m forcing myself to dogfood my own product, but because it genuinely fits into my workflow. I’m already in the terminal, I type a command, it does the thing, and I keep working.

No context switch, no waiting for pages to load, no digging through Vue files trying to remember where that one button lives. Just the tool doing its job and staying out of my way.

Looking back, I think I fell into a trap a lot of builders fall into: copying patterns from successful products without questioning whether those patterns actually fit the problem being solved.

You can see this pattern all over the server management space. Almost every platform ships with a dashboard that looks and behaves broadly the same, not because it’s the only solution, but because it’s the solution we’ve all learned to expect. That doesn’t make it wrong, it just means the pattern often goes unquestioned, even when the problem being solved might be better served elsewhere.

Dashboards are great for some tools, but for developer tools that need to live inside your workflow, the less friction the better. The less UI between you and the thing you’re trying to do, the better.

It took four years and three rebuilds to figure that out. But at least v4 is going well!

Thanks for reading! 🤠

Article stats:

• 1 month to write
• 4 title changes
• ∞ rewrites