The most expensive feature is the one that formalises the wrong behaviour.
Software is exceptionally good at enforcing rules. That is precisely why a process deserves scrutiny before it becomes a feature.
Automation is seductive because inefficiency is visible. A repeated manual task looks like obvious waste, so the instinct is to encode it. But repetition is not proof that a process deserves permanence.
Software turns habits into infrastructure.
Once a workflow becomes a feature, it acquires gravity. Teams train around it. Data structures assume it. Integrations depend on it. Customers adapt to it. What was once an awkward workaround becomes “how the system works.”
That makes the pre-implementation question unusually important: are we automating a necessary rule, or are we preserving a behaviour that only exists because the current process is poorly designed?
Consider an approval process with five steps. Building an elegant approval dashboard may reduce the time required to move through all five. But if three approvals exist only because nobody trusts the information entering the process, the software has improved the symptom while protecting the cause.
The cost is not only development.
The real cost of the wrong feature is future constraint. Every rule that becomes infrastructure reduces the organisation’s freedom to change that rule later. Product debt can therefore begin as policy debt.
This is one reason I prefer to distinguish rules from exceptions. Repeatable rules are strong candidates for automation. Exceptions should often remain visible rather than being buried under increasingly complicated conditional logic.
A good system does not try to eliminate judgement everywhere. It places judgement where it is valuable and removes it where it is repetitive.
Design deletion before addition.
Before adding a feature, ask what would happen if the underlying step disappeared. What risk was the step protecting against? Is that risk still real? Can it be handled earlier, with better information, clearer responsibility or a simpler default?
Sometimes the best product decision is not to digitise the process. Sometimes it is to redesign the process until there is less left to digitise.
Software is leverage. Leverage applied to the wrong behaviour simply makes the wrong behaviour more efficient.