Shipping less can be the fastest way to build better software.
Most people ask founders what they're building next. Almost nobody asks what they decided not to build.
That's usually the more important story.
If you're building software long enough, you start to realize that your product quality isn't just a result of good ideas. It's mostly a result of rejected ideas. Every system gets shaped by what you refuse to add, what you refuse to support, what you refuse to pretend is "close enough."
For a long time, I made the same mistake a lot of technical founders make. I treated every plausible request like it deserved to become a feature. If a user asked for it, I wanted to be responsive. If I could technically build it, I felt pressure to include it. If a competitor had it, I assumed I had to match it.
That way of working feels responsible, but it can quietly kill a product.
You don't notice it right away. At first it just looks like momentum. More options. More screens. More settings. More flexibility. Then one day you realize the product is harder to use, harder to maintain, and harder to explain. Nothing is exactly broken, but everything is heavier.
The turning point for me was realizing that every new feature has a hidden tail. You don't just build it once. You carry it forever. You test it. You support it. You document it. You defend it against regressions. You keep it coherent with everything else that follows.
I started asking a different question before writing code: does this make the core job clearer, faster, or safer?
If the answer is no, it usually shouldn't ship.
That question sounds obvious, but it filters out a surprising amount of work. A lot of ideas are not bad. They're just off-mission. They add surface area without adding leverage. They make the product look bigger while making the experience weaker.
I've also learned to distrust "may be useful." That phrase has burned more hours than any bug I've ever fixed.
"May be useful" is how you end up with features nobody truly depends on, but everyone has to mentally navigate around. It's how real workflows get crowded out by optional complexity. It's how engineering time gets consumed by maintenance on things that never meaningfully moved outcomes.
Saying no is uncomfortable, especially when the request is reasonable and the person asking is genuine. But in practice, good products need clear boundaries more than they need endless accommodation.
The best way I've found to keep those boundaries is to force plain-language explainability. If I can't explain in two or three direct sentences why a feature exists, who it is for, and what decision it improves, it's probably not ready. Usually, it's not needed.
I use that standard on myself before users ever see a roadmap.
There's another benefit to deciding what not to build: speed. Not fake speed, real speed. When the product surface stays focused, iteration gets faster. QA gets easier. Releases get cleaner. The architecture stays understandable. You can make stronger moves with less coordination and less risk.
And users feel it. They may never say "thank you for not adding five extra toggles," but they feel the difference when a tool behaves predictably and gets out of the way.
So when people ask what I'm building, the honest answer is usually two parts: what I'm shipping, and what I'm actively refusing to add.
Both matter.
Maybe the main founder skill isn't feature creativity. Maybe it's disciplined subtraction.