Why I'm building OlympStack — tools you own, for developers who run their own infrastructure. A small manifesto against renting software you'll use unchanged for the next decade.
I opened SSH into a server this morning the same way I did in 2014. Same command. Same workflow. The protocol turns 32 next year and it has not fundamentally changed in my lifetime as a developer.
So here's a question I can't stop asking:
why am I being asked to pay monthly for tools wrapped around workflows that haven't moved in a decade?
That question is the whole reason OlympStack exists. This is my first post here, so let me lay out what I'm building and the opinion underneath it.
The workflow hasn't changed. The pricing model did.
Connecting to servers. Testing an API endpoint. Watching logs. Managing keys. These are some of the oldest, most stable workflows in our entire profession. The way you do them now is recognizably the way you did them ten years ago, and it'll be recognizable ten years from now.
What did change is how the tools around them get sold. Somewhere in the last decade, "buy a tool" quietly became "rent a tool, forever." A connection manager became a $12/month seat. An API client locked its history behind a login and a plan tier. The thing you opened a hundred times a week became a recurring line item with a roadmap of features you never asked for.
I have nothing against SaaS. Subscriptions make perfect sense when they’re backed by an active service that’s actually needed—something that’s hosted, constantly changing, and incurs ongoing costs. A backup destination. A monitoring pipeline. A managed database. You pay for the service that’s actually running. But some of these tools don’t need such services at all, yet they’re forced upon you.
And a desktop tool that talks to your servers, on your machine, doing a job that was solved years ago? That's not a service. That's a tool. And tools are something you should be able to own.
What OlympStack is
OlympStack is a solo developer project — built by one person, for developers who run their own infrastructure without enterprise overhead. The tagline on everything I make is deliberately plain: tools I use every day myself and am proud of.
That's not marketing. It's the actual filter. I don't build something unless I'm already reaching for it daily. Right now that means:
Pro Tools released
- OlympSSH Commander — managing SSH connections and sessions the way I actually work, not the way a pricing tier wants me to.
- OlympAPI — testing and working with APIs without my request history being held hostage by a login screen.
The common thread is ownership. Your connection list, your request history, your keys — those live with you, not on my servers behind a paywall. A tool you bought should keep working whether or not I'm having a good quarter.
Free Tools released
- OlympCron Manager - accessing your Linux Server through SSH and check the Cron Jobs, edit them and use the cron builder for human readable Crons.
- OlympTest Manager - A simple yet powerful manual QA tool. Easy to work with, Easy to create Test Scenarios with AI and then you can do structured End User Tests for the Application.
The opinion I'll plant a flag on
The industry trained a whole generation of developers to accept that software is something you rent indefinitely. I think that's a default worth questioning, not a law of nature.
Some software genuinely earns a subscription. A lot of it just adopted one because the market let it, bringing Cloud Features you don't need and asked, lock you inside their infrastructure and tell you the subscription is worth the payment.
When the underlying workflow is stable — and ours often is — "you own this" is not a quaint throwback. It's the honest model. But honesty don't sell very well.
I’m not naive about this. It’s harder to build a business based on perpetual licenses. Recurring revenue is reliable and predictable, which is why almost everyone relies on it as the default these days—from newspaper subscriptions to all kinds of software, as well as computer and mobile games; subscriptions are everywhere these days. I’m consciously choosing the harder path, because as a developer who pays for my own software, that’s the model I actually want. So I’m building it.
Where this goes
This account is going to be the build log. Expect posts on the tools themselves, the decisions behind them, and the occasional sharp opinion about how developer software gets made and sold. Some of it will be technical. Some of it will be me arguing with the status quo. Probably both at once.
If you also run your own infrastructure and you're a little tired of renting your toolbox — we're going to get along. Tell me where you've drawn your own subscription-or-not line in the comments. I genuinely want to know if I'm the only one keeping a tally.
— OlympStack
Top comments (2)
The tool versus service line is the sharpest part of this. You pay for what is actually running and costing you, a backup target, a monitoring pipeline, a hosted database. A desktop app talking to your own servers is not that, so renting it forever never sat right with me either.
Where I keep landing is that the line blurs the moment any sync or hosting shows up. I build a small finance planning app on the side, and the honest answer there is that the bidirectional sync and the server it runs on do cost something every month, so a subscription is at least defensible. But the second a tool is fully local and the workflow has not moved in ten years, charging rent for it is just charging because the market lets you.
The part people underrate is data ownership, which you nailed. Holding someone's request history or keys behind a login is the real lock-in, separate from the pricing model. Let people own the data and a perpetual license stops feeling risky to the buyer.
Will follow the build log. The one I am curious about is how you handle updates on a perpetual license over a few years, since that is usually where the owned model gets hard.
You've raised some good points.
Regarding synchronization, I actually have a compelling answer — especially for local tools like an API client. You can achieve the same functionality via Git or BYOC ("Bring Your Own Cloud"), both of which my tools support natively. And this applies not just to hosted Git services like GitHub, but also to self-hosted Git solutions like Forgejo.
This way, I don't force anyone into "my" cloud. Instead, offer choices:
I don't actually offer the sync with our infrastructure — I have no interest in providing infrastructure to host other people's data. And think about it: any tool that uses a cloud for data synchronization is ultimately just storing that data somewhere — whether it's NoSQL, SQL, or a file system doesn't matter. The synchronization simply needs to be integrated. Some developer tools force you into their own cloud, even though the developers or vendors could just as easily have implemented BYOC.
Applied to my tech stack, this means: even the free versions offer manual Git synchronization, while the Pro version unlocks automatic synchronization for both Git and BYOC. This gives every developer the ability to back up their data — or even enables teams within companies to collaborate.
It's hard for me to judge exactly what your financial planning app does and whether it actually requires hosted infrastructure. I suspect your servers communicate with other services and everything ties together — that's a solid foundation for SaaS and absolutely justifies a subscription model.
Now for the interesting part: you asked how I handle updates. That's a tricky question. Let me explain my approach using the example of my recently released app, OlympAPI:
My ideas for OlympAPI v2 include "Bring Your Own AI" integration, CSV-based testing, a mock server, and an MCP client. That represents the next major step — a paid, optional upgrade. Does v1 meet your needs? Then simply keep using it. There is no "phone home" feature designed to disable the program, and I will continue to provide security updates and bug fixes for critical issues (those that would render the app unusable) as a standard service.
Note: While Version 1 remains available for €29, the cost to upgrade to Version 2 will be €20, as Version 2 is expected to cost €49. Those who only need the "Basic" API client can still purchase it for €29 and upgrade later; users requiring advanced features—such as AI integration or mock servers—can purchase Version 2 directly with the full feature set. (Prices are subject to change, but you own the software forever at the price you paid for it.)
My entire mindset might seem old-fashioned. When you go to a hardware store and buy a shovel, you don't expect it to last a lifetime. Eventually, the handle breaks, the blade warps under strain, or it rusts through. No one expects a shovel used daily to last 5, 10, or 20 years.
So why must software work forever? I believe this is a flawed mindset instilled in us by the computer industry.
I hope this explanation wasn't too long — and thanks again for your interest.