The Build-vs-Buy Flip Nobody Priced Into Their 2026 Roadmap

Abstract visualisation of a modern enterprise technology stack Most engineering organisations are still running a build-versus-buy heuristic they adopted somewhere around 2020. It went like this: writing software is expensive and slow, therefore buy anything that is not a core differentiator, and only build where the thing genuinely makes you money. That heuristic was correct. It is now correct in some layers and actively wrong in others, and the asymmetry is what catches teams out. The asymmetry AI-assisted development compressed the cost of producing certain kinds of software dramatically. It compressed the cost of producing other kinds not at all. Which kind matters enormously, and the dividing line is not where most people assume. Where the cost fell sharply: workflow and orchestration logic. The rules governing what happens next, who approves, what escalates, how exceptions route. This is code that is conceptually straightforward, high in volume, heavily testable, and tightly specified by domain knowledge the organisation already has. It is close to a best case for AI-assisted development. What was a multi-month engineering effort is now substantially less. Where the cost did not fall: systems of record. A general ledger, a payroll engine, a regulated reporting system. The expense there was never mostly writing code. It was regulatory surface area, two decades of accumulated edge cases discovered the hard way by someone else, certification, and the liability of being wrong. None of that is affected by how quickly code can be produced. Meanwhile, licence pricing in both categories has moved very little. What that does to the arithmetic Run the comparison on the orchestration layer over three years. The buy side is not just the licence. It is licence, plus implementation, plus the configuration consultancy required to make a general-purpose workflow engine express your specific rules, plus the ongoing cost of re-doing that configuration whenever the business changes, plus the constraint that you can only express rules the platform anticipated. The build side is a materially smaller engineering effort than it was three years ago, plus ongoing maintenance, plus the genuine risk of owning something. For a business whose orchestration is actually distinctive, that comparison now frequently favours building — which would have been an unusual conclusion in 2022 and is an unremarkable one today. For a business whose orchestration is standard, buying still wins comfortably, because you are not paying for the platform's generality, you are benefiting from it. Run the same comparison on systems of record and the answer is unchanged. Build there because coding got faster and you will discover that the fast part was never the expensive part. The trap in the intelligence layer There is a third layer where the maths is different again, and where the common mistake is neither building nor buying but committing. Model capability improves faster than any procurement cycle can track. A three-year commitment to a platform's embedded AI is functionally a three-year commitment to a capability snapshot. Teams that wired a specific provider deep into their product in 2024 have largely spent this year unwinding it, which is a cost that appeared in no business case. The architectural response is to treat provider choice as a replaceable component rather than a foundation. Own the retrieval, the prompt construction and the agent logic in your own codebase. Put providers behind an interface that expresses what your application needs rather than how a particular vendor is called. Keep an evaluation set of real production tasks so you can actually tell whether a swap regressed quality. The specific leak to watch for is retrieval. Managed retrieval is appealing because it removes real work, but it places the component that most determines answer quality inside a vendor boundary, and embeddings are not portable between providers. Owning the index and being able to rebuild it from source is what keeps the model layer genuinely swappable. A decision procedure Rather than one decision, make four, in this order: 1. Systems of record — buy, without agonising. Advantage does not live here and regulatory cost dominates. 2. Data and integration — assemble from mature components. Treat this as the primary engineering product, because the value lives in the joins rather than the systems. 3. Orchestration — build if your process is genuinely non-standard and that difference is why customers choose you. Buy if it is not. Be honest about which. 4. Intelligence — build thin and keep it swappable. Commit to architecture, not to a provider. The clearest empirical signal that you bought wrong in layer three: count the spreadsheets people maintain alongside the platform. Three or more means the tool cannot express how the business actually works, and further configuration will not fix that. Frequently Asked Questions How exactly did AI change build-versus-buy? Asymmetrically. It sharply reduced the cost of building orchestration and workflow logic, which is high-volume, testable, well-specified code. It did not reduce the cost of systems of record, where expense comes from regulatory surface, accumulated edge cases and liability rather than development effort. Does this mean we should build our own ERP? No. The cost of an ERP was never mostly writing code. Regulatory complexity, certification and decades of edge cases dominate, and faster code generation does not touch any of them. When is building orchestration logic actually justified? When your process is genuinely non-standard and that difference is a reason customers choose you, or when the cost of integrating and configuring a bought platform exceeds the build. If your process is standard, buying still wins because you benefit from the platform's generality rather than paying for it. What is the risk in the intelligence layer? Committing to a provider rather than an architecture. Model capability moves faster than procurement cycles, so a multi-year commitment to embedded vendor AI is a commitment to a capability snapshot that will look dated before the contract ends. Why is retrieval the main lock-in risk? Because retrieval determines answer quality more than model choice does, and managed retrieval places it inside a vendor boundary. Embeddings are not interchangeable across providers, so an externally managed index makes the model decision effectively permanent. How do we tell whether we bought the wrong platform? Count the spreadsheets maintained alongside it. Three or more, with at least one treated as more authoritative than the system, indicates the platform cannot express how the business actually works — a fit problem rather than a training problem. * * The full argument, with the four-layer model, budget ratios and rollout sequencing, is here: Digital Transformation Software: A 2026 Buyer's Playbook . We build orchestration and intelligence layers as owned software at TechCirkle — agentic workflow development and AI development services .