Architecture decisions have to come before tool selection, because vendor lock-in is not caused by picking the wrong AI tool. It is caused by building on one before you have decided how you would ever leave it.
An RFP crossed my desk recently from a Johannesburg manufacturer, with 37 requirements for selecting an AI platform. Model benchmarks, feature checklists, roadmap commitments, integration counts.
Not one requirement about what it would cost to leave.
That document is why this issue exists. The most expensive AI decisions I have seen were not bad tool choices. They were good tool choices made in the wrong order, welded into architectures that could not let go.
The wrong first question
“Which tool should we buy?” feels like the responsible opening question. It is measurable, it is comparable, and procurement knows how to run it.
It is also the most perishable decision on the list. Model leaderboards reshuffle every quarter. Vendors reprice, repackage and retire products on their schedule, not yours; the last 18 months have been a masterclass in that. The pricing you are evaluating today is often designed not to last. When the US government's procurement arm got frontier AI for a dollar per agency in 2025, every procurement professional watching understood the number was not the price. It was the hook.
Meanwhile, the market itself is telling you how uncertain it is. Best-of-breed buying preferences dropped to 20.7% of enterprises in 2026, according to Futurum, while 41% plan consolidation. Buyers are visibly unsure whether to spread bets or concentrate them. When the whole market is oscillating, locking your architecture to this quarter's answer is the risk.
The order that works
Across the implementations I have led, including helping clients from Cape Town to Pretoria adopt AI without disrupting operations, and the unwinds I have been called into, the sequence that holds is this.
- Which decision are we automating? Not which task, which decision. A decision has an owner, an error cost and a tolerance. If you cannot name those, no tool can help you yet.
- Who is accountable when it is wrong? Answer it before the demo, because after the demo everyone is in love and nobody wants custody.
- What does swapping cost in 18 months? Price the exit before you sign the entry. If the honest answer is “we would be stuck,” you are not buying a tool, you are marrying one.
- Now the tool. By this point, the shortlist usually writes itself, because the first three answers eliminated most of it.
What “modular” actually means
Architecture-before-tools gets nodded at in principle and skipped in practice, because the practice is unglamorous. Concretely, it means five things.
- Your data layer belongs to you, not to the platform. The single biggest unwind cost I have seen was not licences; it was data shaped around one vendor's schema. Export formats and access patterns are architecture decisions, not implementation details you delegate to whoever is onboarding you this quarter.
- Orchestration sits separate from models. The logic that routes work should treat any model as a socket, not a spine. Build the routing logic once, and swapping a model becomes a configuration change instead of a rewrite.
- Interfaces are contracts. Anything that talks to a model does it through a layer you control, so the engine can swap without the plumbing moving. It is more upfront work than calling the API directly, and it is the difference between a Tuesday-afternoon migration and a quarter-long one.
- Governance evidence lives outside the tools. If your audit trail lives inside a platform, your compliance posture has a landlord. The day you leave, you want that evidence walking out with you, not staying behind as someone else's export feature.
- Exit clauses go into contracts while you still have leverage. That is only ever before signing. After signing, you are asking a vendor for a favour; before signing, you are negotiating a term.
None of this slows you down. It is roughly a week of design discipline upfront. I have watched the absence of that week cost a client most of a year on the way out of a platform bet that had aged badly. It is also why modernising the technology foundation for AI has to happen alongside this work, not after it. Architecture built on brittle legacy systems inherits their fragility.
“Upgrading to the latest LLM model is easy. Upgrading your harness is hard, and often expensive and painful.”
That observation from South African CIO Louis de Klerk captures the orchestration layer above in one sentence.
The school-fees test
A South African client of mine told me recently they were done paying school fees, done funding vendors' and advisers' learning curves. The architecture version of that principle is one where your future state should assume the market will surprise you, because it will. Modular design is how you stop paying tuition on every market shift.
One honest caveat: if you are running a six-week experiment, do not architect a cathedral around it. Speed beats purity for anything with a kill date measured in weeks. The discipline above is for what you intend to keep.
So, before the next AI purchase, work through those four decisions in order, and give the tool discussion the final 15 minutes. Ask the vendor what leaving costs, in writing. If anyone calls the architecture week a delay, ask them what 11 months of unwinding feels like.
Frequently asked questions
What does “architecture before tools” actually mean?
It means deciding how your data, orchestration, interfaces and governance work before you pick a specific AI model or platform, so the platform stays replaceable instead of load-bearing.
Does picking the wrong AI tool cause vendor lock-in?
Not on its own. Lock-in happens when data structures, workflows and audit trails get built directly around one vendor's platform, so leaving means rebuilding all of that, not just cancelling a subscription.
How long does building a modular AI architecture take?
Roughly a week of design discipline upfront for most mid-sized implementations: deciding data ownership, orchestration boundaries and exit terms before the vendor conversation starts.
What should an AI vendor contract include to protect against lock-in?
A named exit clause covering data export format, timeline and cost, agreed before signing. It should not be negotiated after you have already decided to leave, when you have no leverage left.
Does architecture-first still apply to short AI pilots or experiments?
No. For anything with a kill date measured in weeks, speed matters more than architectural purity. This discipline is for systems you intend to keep running.
Why does this matter more for South African businesses specifically?
There is less room to absorb a bad bet. Data residency requirements, rand-denominated budgets against dollar-priced platforms and load-shedding contingencies can make an expensive unwind cost more here than in a market that can absorb it more easily.
Related insights
