The cost of a feature is not the build

What the estimate leaves out

It leaves out every subsequent change that now has to consider this feature. Each addition to a system increases the surface future work must be compatible with, and that tax is paid indefinitely.

It leaves out the testing that now runs forever, the documentation that goes stale, the support questions, and the migration that becomes harder because there is one more thing to migrate.

And it leaves out the option cost: a team carrying more features has less capacity to change direction, which in a domain with slow feedback loops is the expensive part.

Removal is much harder than addition

Adding a feature requires one decision. Removing it requires knowing who uses it, which is genuinely hard to establish, plus the political work of telling somebody that a thing they rely on is going away.

In clinical software this is sharper than elsewhere, because a feature used rarely may be used at exactly the moment it matters most. 'Low usage' is not sufficient evidence for removal when the usage pattern is emergencies.

The asymmetry means the decision point that carries real leverage is before the build, not after.

Configurability is a feature with a multiplier

Making something configurable feels like deferring a decision. It is in fact making a larger commitment: every option multiplies the number of states the system can be in, and all of those states are ones somebody may report a bug from.

It also moves work rather than removing it. Somebody now has to decide the configuration, document it, support it and reason about it during every subsequent change.

Sometimes that is exactly right, because hospitals genuinely differ. But 'make it configurable' should be a considered answer, not a way of avoiding a conversation about what the default should be.

The questions we ask instead

What breaks if we do not build this? If the honest answer is 'somebody does something manually that they are already doing manually', that is useful information about urgency.

What does this prevent us from changing later? Features that constrain the data model are much more expensive than features that sit at the edges, even when they take the same time to write.

Who will own it in two years? Not rhetorically a feature with no plausible long-term owner will decay, and it is better to know that before it exists.

Say no clearly, and say why

A vague deferral is worse than a refusal. 'Not now' with no reasoning invites the same request every quarter and gives the requester nothing to work with.

So declined requests get a reason and, where possible, an account of what would change our mind. Occasionally that circumstance arrives and the decision reverses, which is the system working rather than a reversal to be embarrassed about.

The counter-argument, honestly

This reasoning can be used to justify never building anything, and a team that says no reflexively is not being disciplined, it is being unhelpful. Real users have real needs and shipping is the point.

The distinction is whether the cost is being counted or merely invoked. Counting it sometimes says build and when it does, we build.

The other honest caveat is that these costs are estimates too, and worse ones than build estimates, because they are spread over years. We are not claiming precision. We are claiming that a rough number for the whole cost beats a precise number for a fraction of it.