Every software project has an invisible competitor: the version of itself that does less. The strongest engineering decision is often choosing that version.
Features compound
Every feature you add is not just work once. It is work forever: in the UI, in the edge cases, in the training of new users, in the security review, in the upgrade three years from now that nobody remembers how to test. Complexity does not add up — it multiplies.
The smallest system that fully solves the problem is the one that stays coherent as it grows. It is the one a new team member can hold in their head in a week. It is the one where, when something breaks, there are only so many places to look.
"Fully" is the load-bearing word
Smallest does not mean cheap or shallow. A system that solves 80% of the problem is often worse than no system, because it creates a manual shadow process to cover the gap — and shadow processes are where organizations quietly rot.
The discipline is in the word fully. Understand the problem deeply enough that you know exactly what "solved" means, then build to that line — and stop.
How to practice it
- Start from the real workflow, not from what a platform happens to make easy.
- Say no to speculative features. If there is no user and no workflow, there is no feature.
- Make deletion easy. A system that can safely remove things stays small.
- Measure against the problem, not against the roadmap.
The smallest system that solves the problem is not a compromise. It is the design, delivered.