Every organisation has a risk story they tell themselves about technology.
It goes like this: "Building software is risky. Projects fail. Budgets blow out. We could invest heavily and end up with nothing. Better to buy proven solutions from established vendors. That's the safe choice."
This story made sense for decades. It doesn't anymore.
The risk equation has inverted.
Building capability is now the conservative play. Staying dependent on vendors is the gamble.
Most organisations haven't updated their mental models. They're still optimising for risks that have shrunk while ignoring risks that have grown. They're making "safe" choices that are anything but.
The Old Risk Equation
Here's how risk assessment used to work:
Risks of building:
- • Project might fail (high probability)
- • Budget might blow out (high probability)
- • Timeline might slip (very high probability)
- • End product might not meet needs (medium probability)
- • Ongoing maintenance burden (certain)
- • Key developers might leave (medium probability)
Risks of buying:
- • Vendor might raise prices (low-medium probability)
- • Product might not fit perfectly (certain, but manageable)
- • Vendor might be acquired or shut down (low probability)
- • Lock-in makes switching hard (certain, but distant concern)
Looking at these lists, buying seemed obviously safer. Building had more risks, higher probabilities, and more ways to fail. The rational choice was to buy whenever possible and only build when absolutely necessary.
This calculus drove decades of enterprise technology decisions. It's why organisations have hundreds of SaaS subscriptions. It's why internal IT became primarily about vendor management. It's why "we don't build" became organisational identity.
The old equation wasn't wrong, at the time. But the inputs have changed.
What Changed
Three shifts have rewritten the risk equation:
1. Building got dramatically easier.
AI-assisted development has compressed timelines by 80% or more. What took a team of six developers eighteen months can now be accomplished by two people in a few weeks. The probability of project failure has dropped. The cost of experimentation has plummeted.
This doesn't mean building is trivial. But the horror stories that shaped organisational risk perception (the two-year death march that delivered nothing, the million-dollar project scrapped before launch) are increasingly relics of a different era.
2. The cost of dependency became visible.
For years, SaaS spending was scattered across departments, growing incrementally, never scrutinised holistically. Now organisations are waking up to the aggregate cost, and it's staggering.
More importantly, they're seeing the hidden costs: the opportunities missed because the vendor roadmap didn't align, the inefficiencies accepted because customisation wasn't possible, the talent lost because good people don't want to spend their careers administering other people's software.
Dependency always had costs. They're just no longer ignorable.
3. The competitive landscape shifted.
When everyone bought the same software, nobody had an advantage or disadvantage. Now some organisations are building, and they're moving faster, spending less, and differentiating in ways their dependent competitors can't match.
The two-person team that can ship in weeks is real. They're in every industry, targeting every incumbent. The threat isn't theoretical anymore.
The New Risk Equation
Here's how the calculation actually looks today:
Risks of building:
- • Project might not work first time (medium probability, but iteration is cheap)
- • Might take longer than expected (medium probability, but timelines are short)
- • Requires developing new skills (certain, but skills are assets)
- • Ongoing maintenance needed (certain, but you own what you build)
Risks of NOT building:
- • Competitors who build will outpace you (high probability)
- • Costs will increase every year (certain)
- • Differentiation will erode (certain)
- • Capability will atrophy (certain)
- • Talent will leave for more innovative organisations (high probability)
- • When disruption comes, you won't be able to respond (certain, timing unknown)
Look at the second list. Those aren't edge cases or unlikely scenarios. They're near-certainties. The question isn't whether they'll happen, it's how severe the damage will be.
The old equation compared probable building failures against unlikely vendor problems. The new equation compares manageable building challenges against certain competitive decline.
The "safe" choice flipped.
The Risk Inversion
Let me make this concrete.
Old world: You could buy software from established vendors and be confident it would work. Building was a gamble, maybe you'd get something great, more likely you'd waste money and time. Risk-averse organisations bought.
New world: You can build focused solutions quickly and cheaply. If they don't work, you iterate or abandon without catastrophic loss. Meanwhile, vendor dependency guarantees increasing costs, decreasing differentiation, and inability to respond to change. Risk-averse organisations build.
This is the inversion. Building used to be the risky bet.
Now dependency is the risky bet.
Most organisations haven't processed this shift. They're still using the old risk framework, making decisions that feel safe but are actually reckless.
The Hidden Risks of "Safe" Choices
Let's examine what the "safe" path actually exposes you to:
Vendor Concentration Risk
How many critical systems run on software from vendors you don't control? What happens if one raises prices 40%? Gets acquired by a competitor? Decides your market segment isn't strategic? Has a major security breach? You have no leverage. You have no alternatives. You're exposed.
Capability Decay Risk
Every year you don't build, your organisation loses muscle. The people who might have developed skills don't. Institutional knowledge of how to create solutions atrophies. The longer this continues, the harder it becomes to reverse. Five years of not building doesn't mean you're five years behind. It means you may have lost the ability to catch up at all.
Talent Risk
The best people want to build. They want to create, not administer. If your organisation is just a collection of vendor implementations, ambitious people will leave for places where they can actually make things. You'll be left with people who are comfortable with dependency. That's a self-reinforcing spiral toward mediocrity.
Innovation Risk
When you depend on vendors for capability, your innovation is bounded by what they offer. You can't build new products that require custom technology. You can't create processes that don't fit vendor assumptions. You can only do what your software stack permits. Your competitors who build don't have these constraints.
Disruption Risk
When your industry gets disrupted (and it will) your response time is measured in how quickly you can adapt your technology. If that means waiting for vendors to build new features, you'll be too slow. If that means renegotiating contracts and switching systems, you'll be too slow. The organisations that survive disruption are the ones that can respond fast. Dependency makes you slow. Slow means dead.
The Probability Shift
The old risk models assigned low probabilities to dependency risks because historically, they rarely materialised catastrophically. Vendors were stable. Industries changed slowly. The gap between capable and dependent organisations was narrow.
All of those assumptions are breaking down.
Vendor stability is decreasing. Private equity acquires and strips companies. Startups get acqui-hired and products sunset. The "established vendor" you're depending on may not exist in recognisable form in five years.
Industry change is accelerating. AI is reshaping every sector. What seemed like stable competitive dynamics are shifting rapidly. The ability to adapt quickly has become essential, not optional.
The capability gap is widening. Organisations that build are compounding advantages. Organisations that don't are falling behind faster than ever. The penalty for being on the wrong side of this divide is growing.
The probability of dependency risks materialising hasn't just increased, it's approaching certainty. The only uncertainty is timing.
Reframing "Project Failure"
Here's another mental model update: failure in building isn't what it used to be.
Old model:
A failed project meant years of work and millions of dollars wasted. It meant careers damaged and organisations burned. The cost of failure was catastrophic, so avoiding failure was paramount.
New model:
A failed experiment means weeks of work and minimal cost. It means learning what doesn't work and applying that knowledge to the next attempt. The cost of failure is low, so the goal is to learn fast rather than avoid failing.
This reframe is crucial. When failure is expensive, risk-aversion makes sense. When failure is cheap, risk-aversion becomes risk-creation, you're avoiding small, manageable risks while exposing yourself to large, existential ones.
The organisations that understand this are experimenting constantly. They're shipping, learning, iterating. They fail often but fail small. And they're building capability with every attempt, successful or not.
The organisations stuck in the old model are avoiding experiments to prevent failures that wouldn't be catastrophic anyway, while sliding toward a dependency cliff that will be.
What Smart Risk Management Looks Like Now
If you're genuinely trying to minimise risk, here's what you should do:
- →Identify your dependency exposure. Catalogue your critical vendor relationships. What happens if each one doubles their price? Gets acquired? Shuts down? Goes offline for a week? The exercise will be uncomfortable. Do it anyway.
- →Assess your capability baseline. Can your organisation build anything? Do you have people who could create a solution if they had to? If the answer is no, that's a risk factor, probably your biggest one.
- →Start building capability through low-stakes projects. Don't start with your most critical system. Pick something contained, something where failure is acceptable, something where you can learn without catastrophic consequences. Build, ship, learn.
- →Develop optionality. For critical systems, have a plan that doesn't depend on your current vendor. That might mean building an alternative, identifying substitutes, or designing for portability. Don't be trapped.
- →Invest in skills. Training and tools that develop building capability are risk mitigation investments. They expand your options. They reduce your dependency. They make you more resilient.
- →Reframe your risk discussions. When someone says "building is risky," ask: "Compared to what?" Make the dependency risks explicit. Put them on the same ledger as the building risks. Then make a clear-eyed comparison.
The Executive Conversation
If you need to convince leadership that the risk equation has changed, here's the argument:
"We've historically avoided building because it seemed risky. That made sense when building was slow, expensive, and failure-prone.
The environment has changed. Building is now faster, cheaper, and more forgiving. Meanwhile, our dependency on vendors has become a strategic liability, we can't move quickly, we can't differentiate, and we're exposed to concentration risks we've never examined.
The safe choice isn't safe anymore. Our competitors are building capability while we're renting software. Every year this continues, the gap widens.
I'm not proposing we stop using vendors entirely. I'm proposing we develop the ability to build when it matters, so we have options, so we can move fast, so we're not helpless.
That's not a risky bet. That's basic risk management for the world we're actually in."
The Choice Is Risk Either Way
There's no risk-free option. You're choosing which risks to take.
If you build: You risk projects not working, timelines slipping, and resources being spent on things that don't pan out. These risks are manageable, limited, and declining.
If you don't build: You risk competitive irrelevance, cost escalation, capability decay, talent loss, and inability to respond to disruption. These risks are severe, compounding, and increasing.
The question isn't whether to accept risk. It's which risks are acceptable.
I know which side I'm on.
Written by
Jason La Greca
Jason La Greca is the founder of Teachnology. He spent twenty years watching organisations make "safe" technology decisions that were anything but. Teachnology helps organisations understand the real risks they face and build the capability to address them.
Connect on LinkedInReady to reassess your risk exposure?
Take the AI Readiness Assessment to see where you stand.
Start AssessmentNeed help building capability?
Explore how Teachnology Advisory helps organisations build the capability to address real risks.
Explore Advisory