Adding UI to remove UI — strackt [ ](/ "Home") [How It Works](/how-it-works) [Pricing](/pricing) [Company](/company) [ How It Works ](/how-it-works) [ Pricing ](/pricing) [ Company ](/company) Tuesday, May 5, 2026 -------------------- Adding UI to remove UI ====================== ![](/assets/janpeterwiersma-profile.jpeg) Jan Peter Wiersma [ Signal ](/blog/category/signal) ![adding-ui-to-remove-ui.png](/assets/blog/adding-ui-to-remove-ui.png) We're adding UI now so we can take it away later. Look at strackt today and you'll see something we plan to delete. Detailed server statistics, firewall configs with custom ports, checkpoints, activity logs, operation debug logs — knobs and screens for almost everything we do. It's there for a reason; it's also temporary. The UI isn't there because we plan to keep it. It's there because we need it to find out what to keep. We're the first user. Every button, every panel, every debug log on screen is something we're triggering ourselves — testing what fires when, watching what breaks, figuring out which moments need a notification and which ones can stay quiet. > The interface is research. The loop is pretty simple: add functionality with a button next to it; watch how it ties into the rest; see what we end up triggering most, checking most, looking at most. Then peel away the buttons we never use. Remove the option. Automate the behaviour. The end state is fewer buttons every quarter. Which means the server panel — the most cluttered surface in strackt right now — is the one we expect to shrink the most. Today the server panel is dense — every screen pulling you in to look at something and decide something. That's not where it lands. The server view we're building toward asks four questions: is it being used efficiently, is it performing the way it should, how are the maintenance levels, and should you bring another one on board. That's it. Beyond that, a visual overview of what your server actually is — its capacity, its workloads, what's running on it — and almost no buttons. Because the truth is: we don't actually need you to configure your server. We need you to bring it. Compute capacity, storage capacity, a place for us to run things. The rest is our problem. You'll still see your server. You'll still be able to take it back and run it yourself if you change your mind — that's never going away. But while strackt is managing it, you shouldn't have to think about it as a server. You know it's there; you don't have to touch it. --- Look at how the rest of the industry handles this and you find two answers — both of them positions, both of them extreme. Server control panels have spent the last decade adding. Forge, Ploi, RunCloud — every release is more graphs, more fields, more switches, more firewall rules to configure, more deploy hooks to wire up. The thesis is control: hand the developer every knob and trust them to know which to turn. The interface keeps growing because every release adds choices and never removes them. Managed clouds went the other way. Heroku, Render, Fly, Laravel Cloud — you push, it runs, and you never see how. A deploy log, a metrics graph, a billing page. That's the surface. The thesis is opacity: hand the developer nothing and charge them for the privilege of not having to think. You don't worry about how because you can't. Both took a position. Neither direction is the one we chose. --- strackt sits in the middle. You bring your own resources — your own VPS, your own provider, your own bill. We do the work to keep them running well. You don't have to think about how, but you can see what we're doing whenever you want, and you can walk away with your server in working order whenever you want. That position is harder than either extreme. The control panel route is easy: build a UI, ship it, leave the user to figure it out. The cloud route is also easy in its own way: hide the machine, charge a margin on the abstraction, never explain. The middle requires us to make decisions for you that work, and to keep making them as the world changes — without burying you in the proof or pretending the work doesn't exist. The hardest product work is the discipline to remove. To resist the pull of more graphs, more switches, more configs; to look at what we built last quarter and decide which parts you shouldn't have to see anymore. That's the work of an opinionated platform: figuring out what you actually need, then doing it for you before you need it. So expect strackt to keep growing for now. New panels, new controls, new ways to see what's happening on your server. The work behind it is what comes after: figuring out what you don't need to see, and removing it. That's the part most platforms never get to. We plan to. [ Back to the log](/blog) Get started ----------- Your servers. Your provider. Your data. Our problem. Deploy your first app in minutes. Early access opens mid-2026. Join the Waitlist Join You're on the list! ### Product - [How It Works](/how-it-works) - [Pricing](/pricing) - [ELI5](/what-is-strackt) - API ### Company - [Blog](/blog) - [Company](/company) ### Support - Documentation - [Feature Requests](https://strackt.featurebase.app/) - Support ### Legal - [Terms of service](/terms-of-service) - [Security](/security) - [Privacy policy](/privacy-policy) © 2026 Madonie Holding. [ ](https://x.com/stracktio) We don't stack cookies. Just two essentials and one optional. That's the whole stack. **Session & CSRF** — keep things running. Always on. **Support & feedback** — so we can actually talk. Your call. No tracking. No ads. [Privacy policy](/privacy-policy#cookies) Accept all Essentials only