What Will the Next Change Cost?
Table of Contents
The cheaper proposal does not necessarily produce the cheaper system. The difference often appears a year or two later, when the company needs a new customer type, a different approval process, a revised price list, or an integration with another service. Only then does it become clear whether the original saving was real or merely a deferred cost.
When buying business software, it is therefore not enough to ask, “How much will it cost to build?” An equally important question is, “How much will it cost when we change this next year?”
The Cost That Does Not Appear in the Proposal #
Imagine two proposals for the same internal system. One costs €12,000 and the other €16,000. If we compare only the feature list and the final price, the first option clearly looks better.
Both systems may do exactly the same things on delivery day. The difference can be hidden in their internal structure. In the first solution, business rules are scattered across forms, exports, and unrelated parts of the code. In the second, they are separated from the rest of the system and each rule has a clear home.
A year later, the company requests an additional approval step. In the first system, the team must begin by discovering everything the change may affect. In the second, it adjusts an isolated part of the process. Two functionally equivalent systems suddenly have very different costs.
The initial price is highly visible, so it naturally dominates purchasing decisions. The cost of future changes is harder to put into a proposal. Over the system’s lifetime, however, it may exceed the price of the first version.
A Small Request Can Trigger a Large Change #
A user may describe a request in one sentence: “Let us add a new customer type.” For the software, however, that may not be one change.
The more places a developer must find, understand, and modify, the longer the change takes. At the same time, the risk increases that something will be overlooked or that the fix will break another feature.
The cost of a change is therefore not determined only by the amount of new code. It also includes discovering dependencies, checking consequences, testing affected areas, migrating data, deploying the update, and resolving any resulting defects. A seemingly small adjustment becomes expensive mainly when it has a large change radius.
Three Delivery Methods and a Fourth Problem #
A company has an ordering system with three delivery methods: courier, customer pickup, and pallet shipping. In the first version, the quickest approach is to write three conditions directly wherever they are needed.
Over time, the same assumption appears in pricing, invoicing, notifications, warehouse operations, and accounting exports. Every part of the system assumes that there are exactly three options.
Two years later, the company adds parcel lockers. The main question is no longer:
How long does it take to program a fourth delivery method?
The more important question is:
How many places in the system assume that there are exactly three?
If delivery has its own model and the rest of the system uses a shared interface, the new option can be added locally. If specific delivery methods are hard-coded in many places, the change spreads throughout the system.
This is the practical difference between a low and a high cost of change:
- Low cost: we modify one rule in one known place.
- High cost: we first have to discover everywhere the rule exists and everything that depends on it.
Changeability Is Not Just a Property of the Code #
Clean, understandable code helps, but it is not enough on its own. Changeability comes from several decisions working together.
| Area | How it affects future changes |
|---|---|
| Data model | Determines whether new cases can be added or stored data must be restructured. |
| Module boundaries | Decide whether a change remains local or spreads across the system. |
| Configuration | Allows rates, limits, and rules to change without modifying the program. |
| Interfaces and integrations | Separate internal logic from services the company does not control. |
| Automated tests | Reveal more quickly whether an update has broken existing behaviour. |
| Documentation | Reduces the time needed to understand decisions and dependencies. |
| Deployment process | Determines the effort and risk involved in delivering a change to users. |
| Vendor dependency | Affects whether someone else can safely take over and develop the system. |
The company itself is also part of the equation. If it cannot describe its processes, exceptions, and responsibilities clearly, even a technically sound system will not be cheap to change. Changeability is a property of the entire solution — its code, data, operations, and decision-making practices.
Flexibility Is Not Free Either #
None of this means that everything should be generic and configurable from day one. Preparing for every imaginable future creates more code, more complicated controls, and a higher initial cost. A system can become so flexible that it is no longer understandable.
The expensive capabilities may also never be used. That is just as wasteful as a short-sighted solution that must be rebuilt after its first change.
The sensible goal is therefore not maximum flexibility. It is proportionate changeability in areas where change is likely or where a later change would be exceptionally expensive.
Design for Probable Change #
The future cannot be predicted precisely, but not every change is equally surprising. It helps to distinguish three groups during design:
- Changes already known. The company may be planning a new warehouse, another market, or a second pricing scheme. The system should not block them.
- Changes typical of the domain. Price lists, rates, approval steps, user roles, and external APIs commonly evolve. Isolating these rules and making sensible use of configuration has clear value.
- Purely hypothetical possibilities. If there is no business reason or realistic scenario for them, there is no need to pay for their support today.
Good architecture is not fortune-telling. It is the ability to identify which assumptions are stable, which are likely to change, and which decisions would be especially difficult to reverse later.
Ask One More Question Before Accepting the Next Proposal #
No serious supplier can give an exact price for an unspecified future request. They can, however, explain how the system limits the impact of probable changes.
Before ordering or extending business software, it is worth asking:
- What happens when another product, warehouse, customer, or delivery type is added?
- Which business rules will be configurable and which will be embedded in code?
- Are rules kept in one place or scattered across several modules?
- What will need to change when an external system or API is replaced?
- How will the team verify that an update has not broken existing features?
- Can another developer understand and take over the solution?
- Which decisions made today would be the most expensive to change later?
These questions do not replace a technical design or an estimate. They do help distinguish a system that merely satisfies today’s specification from one that can be developed economically.
The initial price still matters. It should not obscure the fact that business software exists for much longer than its delivery day. An architectural decision is also a decision about the future cost of every change.