I keep coming back to the same trade-off in different software projects. It’s a concept that I also apply to many things that are not related to software, but in this blog I want to focus on the software aspect. It’s not a new concept, not at all. But I think (especially in software) it’s not applied nearly as often as it should be. There are different ways to describe it or think about it, but I want to frame it like this:
How can software stay manageable without becoming too limited to be useful?
It is tempting to solve problems by going all out. The newest tech stack, more features, more configuration options, more plugins, more abstraction, more services, …
While it allows the software to be more capable and potentially useful to more people, it often makes the core experience much worse. The things you want to do with the software 90% of the time are slower, harder to access and there are more distractions.
But that’s not all. Software has a cost beyond its feature list. Complexity shows up in security, performance, supply chains, developer experience, onboarding, mental models, hardware requirements, debugging, and long-term maintenance.
A tool can be powerful and still feel heavy. It can support many use cases while making the important one harder.
The kind of software I like tends to sit somewhere else:
small enough to understand, capable enough to be useful.
That is what I mean by manageable but capable software.
This is not the same as minimalism for its own sake. A tool can be too small. It can refuse useful features just to look elegant. That is not interesting to me.
The interesting space is the middle ground: software that accepts constraints, chooses its core job carefully, and tries to do that job well without becoming a platform for every possible need.
There are many references for this idea but here I want to point to one in particular: Niklaus Wirth’s essay “A Plea for Lean Software.” It captures this concept really well: software often becomes worse when it grows without enough pressure to stay understandable.
This idea connects most of the things I build and write about.
Stelae keeps WordPress where it is useful, as an editor, but removes it where it is often unnecessary: public hosting. The result is less dynamic, but also simpler to host, easier to move, faster by default, and much less exposed.
My interest in compiler bootstrapping comes from a similar place. The question is not only “how small can the seed be?” but also “how much of this chain can a human actually recognize, inspect, and trust?”
The same theme shows up in smaller tools, UI libraries, maintenance-mode plugins, and runtime experiments. I am interested in software that does the important part without demanding too much from the people who use it, run it, or maintain it.
This blog is where I want to collect those thoughts.
Some posts will be about Stelae. Some will be about static WordPress, Java tooling, open source, compiler bootstrapping, or small technical decisions that do not fit anywhere else.
The common thread is not a specific technology.
It is the question:
How simple can software be while still remaining useful?
That is the kind of software I want to build more of.