Ask a product team in trouble what comes next and the answer is nearly always the same: build more. More features, more integrations, more settings, more surface. Yet the software people trust most is rarely the software with the longest changelog. It is the software that does a few things so reliably that nobody thinks about it at all.
This essay is about why software teams should build less, not as a cost-cutting measure but as an engineering discipline. Call it anti-bloat engineering. The premise is blunt: every feature is a liability until proven otherwise, deleting code is a legitimate KPI, and a small team with sharp tools will outship a large one dragging an unexamined codebase behind it.
Every feature is a liability until proven otherwise
The day a feature ships, it has produced no value yet. What it has produced, immediately and with certainty, is obligation. It must survive every framework upgrade. It widens the attack surface. It needs documentation, support answers, and a place in onboarding. It adds rows to the testing matrix and constraints to every future design decision.
Value, by contrast, is speculative. Maybe users adopt it. Maybe it moves retention. Maybe the prospect who demanded it actually signs. The costs are guaranteed and the benefits are hoped for, which makes skepticism the rational default.
Reverse the burden of proof. Most teams treat a request as approved unless someone objects. Flip that. A feature earns its way in by demonstrating demand: a workaround people keep using, a spreadsheet someone built in protest, a task users measurably fail at today. If no evidence exists, the cheapest experiment is not building it.
The compounding cost nobody puts on the roadmap
Estimates cover the cost to build. Almost nothing covers the cost to carry.
Features do not sit side by side, they interact. Each new capability must coexist with every existing one, so complexity grows combinatorially while the team grows linearly, on a good quarter. A toggle added for one customer in year one becomes an edge case in a migration in year three and a silent data bug in year five.
Dependencies age too. APIs deprecate, libraries lose maintainers, platform rules shift under you. A feature used by three accounts still demands attention on every release, forever, or it quietly rots. This carrying cost never appears in planning meetings because no line item exists for it, and whatever goes unmeasured gets treated as free.
Deleting code as a KPI
Teams measure what they ship: story points, velocity, features per quarter. Almost nobody measures what they remove, which is strange, because removal is one of the few engineering activities with compounding returns. Every deleted path is a path you never test, patch, document, or explain again.
- Schedule it. Hold a recurring deletion review, quarterly is enough, where the only agenda is what can go: dead feature flags, abandoned experiments, duplicate code paths, settings nobody toggles.
- Instrument first. Usage data turns deletion debates from opinion fights into arithmetic. A capability with no meaningful usage in six months is a candidate, not a sacred object.
- Put sunset dates on experiments. Anything shipped as a test should carry an expiry. Without one, every experiment becomes permanent by default.
- Celebrate removals. Put them in the release notes. A team that takes pride in deletion stops hoarding.
The usual fear, that nobody remembers why some code exists, is itself a diagnosis. Code nobody understands is not an asset being protected. It is a risk being postponed.
Saying no as a service
For anyone who builds software for others, restraint is the hardest product to sell. A client asks for a feature, and every incentive in traditional billing says yes: more scope, more hours, more invoice. The vendor who agrees to everything looks accommodating right up until the system stops being maintainable.
We feel this directly. ETREXIO works on retainers rather than per-feature billing, and that one structural choice inverts the incentive: every line of code we add is a line we will be operating next year. When you are paid to keep a system healthy over time instead of to maximize billable scope, refusal stops being a confrontation and becomes part of the service. Our average client stays around five years, which we read as evidence that the refusals aged better than the requests would have.
A useful no always arrives with an alternative: the smaller version that tests the same hypothesis, the configuration change that avoids code entirely, or the manual process that proves demand before anything gets built.
Small teams with sharp tools outship large ones
Headcount was never proof of capability. It was a proxy for cost, and for most of software history it was the only proxy buyers had.
The arithmetic works against size. Communication paths multiply far faster than the people who create them, so every hire adds output and drag at once. Worse, large organizations build features to justify their own structure: the role that exists because the last role existed will find something to ship, whether or not the product needs it. Bloat in a codebase is often just the org chart, rendered in code.
A small team with sharp tooling escapes both traps. Two or three people can hold an entire system in their heads, which means they see the cost of an addition before it is made. AI changes this equation without repealing it. Machine assistance makes code cheap to produce, which makes restraint more important, not less, because bloat can now be generated at scale. The discipline has to live with the humans who review and decide.
What maintaining 50 products teaches about restraint
ETREXIO has shipped and still maintains more than 50 products with two senior builders and an AI workforce, always with humans making the final call. Operating everything you ship teaches a lesson no planning framework can: a feature added casually in year one is a production alert in year four, and you will be the one awake for it.
That perspective changes decisions at the source. We reach for boring, proven technology. We prefer configuration over code whenever configuration will do. We treat each new surface as a standing commitment, because across a portfolio this size, small indulgences multiply into a load no team could carry.
The payoff of building less is not austerity. It is speed that survives. A lean system can change direction in a week; a bloated one needs a quarter just to understand itself. If your roadmap feels heavier every quarter, the fix is probably not more hands. It is fewer features, better chosen. And if you want a partner in making that case, talk to us.
Frequently asked questions
Why is building less software better than building more?
Every feature carries permanent costs: maintenance, security exposure, testing, support, and added complexity for users. Those costs are certain, while the value of any single feature is speculative. Building less keeps the guaranteed costs low and concentrates effort on capabilities with proven demand, which makes the whole product faster to change and easier to trust.
How do you decide which features not to build?
Reverse the burden of proof. Require evidence of demand before writing code: a workaround users already perform, measurable failure at a task, or repeated requests tied to real usage. Offer a smaller experiment first, such as a manual process or a configuration change. If the evidence never materializes, the feature was a cost you avoided.
Does deleting code actually improve a product?
Yes, and the returns compound. Every removed code path is one you never test, patch, document, or debug again, which frees capacity on every future release. Deletion also shrinks the attack surface and makes the remaining system easier to reason about. Teams that schedule regular deletion reviews ship faster because they carry less weight.
Can a small team really maintain a large product portfolio?
It can, if the portfolio is built with restraint. ETREXIO maintains more than 50 products with two senior builders plus an AI workforce under human review. The approach relies on boring technology, heavy automation, aggressive deletion, and refusing features without evidence, so each product stays small enough to operate indefinitely.