There is a particular kind of software that wants to do everything. It launches with a clean interface and one clear purpose. Then, over the following months, it accretes. A dashboard. A notification centre. An AI assistant. Integrations with tools that integrate with other tools. By the time it has become truly useful to the people who built it, it has become genuinely exhausting to the people who have to use it.
I find myself returning, again and again, to a different instinct. Build less. Do fewer things. Do those things well, and then leave the user alone.
The complexity problem is not a technology problem
Every product I have used that became complicated started simple. The complexity came later — usually from reasonable decisions, made incrementally, by people who cared. A new customer asked for one feature. A roadmap demanded a quarterly release. A competitor shipped something similar and the team felt pressure to match it.
None of these individual decisions were wrong. Collectively, they produced software that requires a six-minute onboarding video and a dedicated "getting started" documentation site.
The tool is no longer doing work for the user. The user is doing work to manage the tool.
This is the inversion that simple tools try to resist. A tool with fewer features is not a lesser tool. It is a tool that has made a different set of decisions about whose time it respects.
What "simple" actually means
Simple does not mean minimal. A well-designed knife is not simple because it is small — it is simple because every element serves the same purpose. Remove any part and it stops working. Add any part and it becomes something else.
The same is true of software. Simple tools have an internal coherence. They know what they are for. They make that purpose legible to anyone who picks them up. And they resist the pull toward becoming a platform, a hub, or an ecosystem.
Why this matters now
We are building tools faster than we ever have. The cost of generating a new feature, a new screen, a new integration has dropped considerably. This is genuinely useful. It is also dangerous, because the friction that used to slow down complexity has been removed.
When a feature takes six weeks to build, there is natural pressure to ask whether it is truly necessary. When it takes six hours, that question gets skipped. The result is software that reflects what was technically possible rather than what was actually needed.
Building simple tools in this environment is not a romantic statement about craftsmanship. It is a practical position: most users need less, not more. Most problems are smaller than the software built to solve them. And most products would be improved by removing things rather than adding them.
The practical rule I use
When I am deciding whether to build a feature, I ask one question: if this were removed six months from now, would anyone notice?
If the answer is probably not, I do not build it. If the answer is definitely, I consider whether it belongs in this tool at all, or in a different one.
This is not a perfect heuristic. But it keeps the scope honest. And it keeps the tool doing the thing it was supposed to do, rather than the thing that seemed like a good idea at the time.