On shipping less

Every project I have regretted shipped too much. Not too late, not too buggy: too much. More options, more screens, more knobs than the problem actually needed.

The cost of surface area

Each feature you ship is a promise. You promise to keep it working, to document it, to not break it when the next thing lands. The bill arrives later, quietly, as the time you no longer have to do the work that matters.

So I have started asking a blunt question before building anything:

If I cut this, would anyone notice within a month?

If the honest answer is no, it does not get built.

What "less" looks like in practice

• One way to do a thing, not three.
• Defaults good enough that most people never open settings.
• Saying no to the feature request that benefits one loud user.

The result is software that is smaller, calmer, and far cheaper to keep alive. That last part is the real win: maintenance is where projects quietly go to die.

Shipping less is not doing less. It is refusing to confuse motion with progress.