Slow software is a design position

There is a category of software that is finished. Not abandoned — finished. It does one thing, it does it correctly, and its maintainer has decided that the next feature request is not going to be accepted.

This is usually read as a failure of ambition. I think it is closer to a design position, and a defensible one.

The cost that nobody prices

Every feature has a build cost, which everyone estimates, and a carrying cost, which almost nobody does.

The carrying cost is what you pay forever after: the branch in the code that must keep working, the configuration option that must keep being valid, the documentation paragraph that must stay true, the bug report that arrives three years later from the only person using it.

For a company with a team, carrying cost is absorbed. For a single maintainer, carrying cost compounds until it consumes the entire maintenance budget — at which point the project stops receiving fixes, not because the maintainer left, but because there is no room left to move.

Choosing to be small

Software that stays small is making a trade: fewer people served, indefinitely, versus more people served, briefly.

// The version that stays small
public function publish(Post $post): void
{
    $post->update(['status' => PostStatus::Published, 'published_at' => now()]);
}

// The version that has absorbed four feature requests
public function publish(
    Post $post,
    ?Carbon $at = null,
    bool $notify = true,
    bool $skipValidation = false,
    ?string $channel = null,
): void {
    // ... and now every caller has to understand all five
}

The second signature is not worse code. It is the same code carrying four decisions that could have been made elsewhere.

Where the line actually sits

The position is not "never add anything". It is that additions should have to argue for themselves against a default of no, and that the argument should include who is going to carry the thing in five years.

Three questions that make the trade visible:

1. Does this change what the software is, or only what it can also do?
2. If this feature had a bug in eighteen months, would I still care enough to fix it?
3. Could the person asking build this themselves on top of what already exists?

A yes to the third question is not a rejection. It is often the best outcome: the feature exists, someone who needs it maintains it, and the core stays the size one person can hold in their head.