The Technology Decision You Are Making Right Now That You Will Regret in 18 Months
Technology decisions that produce the most expensive regret are rarely the careless ones. They are the ones made carefully, with genuine intent, under conditions that made them look like the right call at the time. The decisions that cause the most damage eighteen months later are the ones that were made with confidence and without sufficient examination of what they foreclosed. Understanding the conditions that produce this kind of regret is the most practical form of technology governance a leadership team can practise.
In fifteen years of working with technology organisations across the US, UK, Europe, and Asia, I have seen the same categories of regrettable decisions appear with remarkable consistency. They are not random. They follow patterns that are recognisable in advance if you know what you are looking for. The challenge is that these decisions typically feel right in the moment. The context that makes them look wrong only becomes visible later, when the consequences of what they foreclosed begin to materialise.
The most common pattern is what I call the Clarity Pressure Decision: a technology choice made not because it is the best available option but because the urgency to move forward is greater than the discomfort of uncertainty. The organisation reaches a decision point, the options feel unclear, the pressure to act is high, and the choice made is the one that resolves the immediate discomfort rather than the one that best serves the eighteen-month position. These decisions are almost never made by careless leaders. They are made by capable leaders operating under conditions that were not designed to support good long-term judgment.
The Foreclosure Cost Formula: Calculating What Each Decision Closes Off
In SuperBotics’ technology strategy work, I use what I call the Foreclosure Cost Formula before any major architecture or platform decision: for each option under consideration, map out not just what it enables but what it makes significantly more difficult or impossible within a three-year horizon. The decision with the highest foreclosure cost is not necessarily wrong, sometimes foreclosing options is the correct strategic move. But it should be made consciously, with explicit understanding of what is being traded away and why that trade is worth making.
The most expensive technology decisions are not the ones that failed to deliver what was promised. They are the ones that succeeded at their stated goal and simultaneously foreclosed a more valuable future option that nobody mapped before the decision was made.
| Decision Type | Feels Right Because | Regret Source at Month 18 |
|---|---|---|
| Monolithic rebuild | Unified codebase, faster initial delivery | Scaling bottleneck, integration cost |
| Single-vendor lock-in | Simplicity, support relationship | Price leverage gone, migration cost |
| Deferred data architecture | Ship features first, fix later | Analytics blind, AI impossible without rebuild |
| Skipping governance setup | Move fast, governance slows delivery | Technical debt compounded, quality regressions |
The Deferred Data Architecture Problem
Of all the technology decisions I see producing eighteen-month regret, deferred data architecture is currently the most consequential. Organisations building new systems or modernising existing ones are under pressure to ship features quickly. Data architecture feels like infrastructure, important eventually but not immediately blocking delivery. The decision to defer it is made with every intention of returning to it, and the return almost never happens because new feature pressure immediately replaces old feature pressure.
Eighteen months later, the organisation wants to build AI capabilities on top of their systems. They discover that their data is distributed across disconnected stores, lacks the consistency needed for model training, and would require a significant rearchitecting effort to become useful for the applications they want to build. The features shipped quickly are working well. The data architecture never built is now the bottleneck to the next two years of competitive development. The regret is not about what was built. It is about what was not built alongside it.
Single-Vendor Dependency and the Leverage Problem
Single-vendor dependency decisions are made for understandable reasons. Consolidating onto one platform simplifies operations, builds a deeper support relationship, and often produces meaningful cost savings in the short term. The regret arrives when the vendor recognises the dependency and adjusts pricing accordingly, when the platform limitations become visible as the organisation scales, or when a better option emerges in the market and migration is structurally prohibitive.
The organisations I have seen navigate vendor relationships most successfully are the ones that made dependency decisions consciously. They understood what they were accepting when they chose depth over flexibility. They built migration feasibility assessments into their vendor relationships before committing. And they maintained enough architectural awareness of alternatives that they could have an honest conversation with their vendor about the real cost of their relationship. Dependency is not always wrong. Unexamined dependency is almost always expensive.
Building the Conditions for Better Decisions
The practical implication of all of this is not that technology decisions should be slower. Speed matters. Competitive environments require decisiveness. The implication is that the conditions around technology decisions need to be designed to surface foreclosure costs before commitment happens. That requires a practice, not a process. It requires leaders who ask the foreclosure question as a matter of habit, technology partners who are expected to surface long-term consequences rather than just optimise for immediate delivery, and governance structures that treat major architecture decisions as requiring explicit sign-off on what they close off, not just what they enable.
The decisions that will produce regret eighteen months from now are being made in your organisation right now. They are being made by capable people under real pressure with genuine good intent. The question is whether the conditions around those decisions are designed to catch the ones that will hurt later. More on technology governance and strategic decision-making on this blog.

