Software Engineering : When Building Beats Buying (And When It Doesn’t)

Building beats buying when performance, latency, or precision requirements sit at the core of your competitive edge, since vendors optimize for broad markets, not your specific bottleneck. Buying wins for commodity problems where speed-to-market and maintenance costs outweigh customization value. The real test isn't build-versus-buy ideology, it's whether the capability is a differentiator or a distraction from your actual business.

1. A disclosed bias

I spent twelve years writing algorithmic trading software before any of the cloud infrastructure work. That is where the bias actually comes from, not from EC2. Trading systems taught me that being quick and being good are not separate goals you trade off against each other, they are the same requirement stated twice. A trading system that is merely correct but slow is worthless, and one that is fast but wrong is dangerous. You build your own tooling in that world because nothing bought off a shelf moves at the speed or the precision the problem demands, and because the vendor selling it to you is never going to care about your latency budget as much as you do. Everything I did afterwards at EC2 reinforced that instinct rather than creating it. I want to say upfront that this is a bias, not a virtue, and the rest of this piece is an attempt to argue against my own instinct rather than simply justify it.

2. A framework built for a world that no longer exists

Most build versus buy thinking, mine included until recently, was formed in an era where writing software was the expensive part of building software. That assumption quietly shaped two decades of enterprise procurement. You built only when a capability was strategic enough to justify the cost of an engineering team, and you bought everything else because buying was faster and development was the scarce resource.

That assumption is no longer true, and most organisations have not noticed yet. AI has not made build slightly cheaper. It has collapsed the one cost that used to make buying the default answer. The rest of this piece works through what changes once you take that seriously, and what still does not change no matter how cheap development gets.

3. The real cost of buying

The pitch for buying is always the same. Faster time to value, someone else carries the maintenance burden, and you get a roadmap written by people who supposedly think about this problem all day. Some of that is true. What the pitch leaves out is what actually happens after signature.

Start with the phrase itself. Out of the box is close to a lie. Nothing comes out of the box. It is the line a salesperson uses on a buyer who does not have the technical grounding to ask the follow up question, which is always some version of, out of the box for whose process, configured by whom, and maintained by which team once your integrator has left. Sales exists to close the gap between what a buyer wants to hear and what a product actually does, and out of the box is the phrase built specifically for that gap. You want feature X, sure, it does that out of the box, sign here. By the time anyone discovers how much configuration that feature actually required, the deal is done and the renewal clock has already started.

Vendor lock in is the obvious cost, and everyone budgets for it in theory. What people do not budget for is the customisation spiral. You buy a platform because it promises to fit eighty percent of your process out of the box. Six months later you have paid a systems integrator to bend it into your specific workflow, and that customisation layer is now a second system you maintain on top of the first one, except you do not own the underlying code and cannot fix it yourselves when it breaks.

Then comes the upgrade event. Every major platform eventually forces a version upgrade, and because you customised so heavily, that upgrade is not a patch, it is a multi year programme. I have watched this play out enough times to know the ending before it starts. Years of effort, a project team the size of a small department, and at the end of it the business is functionally back where it started. Nothing new was delivered. The organisation simply spent enormous effort returning to the same altitude it was already flying at, on a newer version number.

Buying software is also rarely just buying software. It is buying identity integration, event integration, API integration, audit integration, monitoring, backup, disaster recovery, and a data pipeline to get information in and out of a system that was never designed with your other systems in mind. Every platform you bring in becomes an island, and someone on your team spends the next several years building bridges to it. That integration cost rarely appears on the procurement business case, because the people signing the contract are not the people who will be paying it.

And underneath all of it sits the talent problem. Try finding good specialist developers for a heavily customised enterprise platform right now. The market is thin, the good ones know it, and the rates reflect that scarcity. You end up paying premium wages for skills that only exist because the platform is complicated enough to require its own ecosystem in the first place. That is not a cost you would ever face if the workflow lived in your own object model.

4. The real cost of building

None of this means build is free of its own traps. The most obvious one is talent scarcity in the other direction. Good platform engineers are hard to find and expensive to keep, and if you build something brilliant that only two people in the organisation understand, you have created a different kind of lock in, just with your own staff instead of a vendor.

The maintenance burden is real too, and it is worth being precise about what that actually means rather than waving at it. Every dependency upgrade you postpone increases the eventual migration cost, because more of your system accumulates assumptions about today’s behaviour that a future upgrade will break. Technical debt is not an abstract discomfort. It is a compounding interest rate charged against every shortcut you did not have time to close out.

There is also a framing problem worth naming honestly. Build is never really build from scratch. Most software your team writes rests on enormous amounts of open source infrastructure that your team did not author and does not maintain. The runtime, the libraries, the frameworks, the database engine, all of it is someone else’s work that you are depending on just as much as you would depend on a vendor. The difference is not that build eliminates dependency. It is that build lets you choose which dependencies you take on and gives you the ability to fix or replace any one of them yourself rather than waiting on a vendor’s release cycle. That is a real advantage, but it is not the same as ownership, and pretending otherwise leads to a false sense of self sufficiency.

5. Why the object model is the actual story

Buried in the middle of most conversations about AI accelerated building is a line about having a decent object model and schema underneath it, and it usually gets less attention than Claude Code itself. That is backwards. The model is the reason the tool works as well as it does.

An object model is your business logic written down as structure rather than as scattered rules living in people’s heads, spreadsheets, and the undocumented judgment of whoever has been in the role longest. When that structure is clear, an AI coding tool has something solid to build against. It knows what a customer, a transaction, a claim, or a case actually is in your organisation, what fields matter, and how those things relate to each other. Workflow logic on top of that structure is almost mechanical to generate, because the hard intellectual work, deciding what your business actually consists of, has already been done.

This is also why the same tooling produces wildly different results across organisations. A team with a clean, well maintained object model gets extraordinary leverage out of AI assisted building. A team without one gets the AI equivalent of writing customisation on top of a platform that does not fit their process, except now the customisation was generated in an afternoon instead of over a six month integration project. The object model, not the AI, is what determines whether you get speed or you get sprawl.

6. The economics have moved

The traditional build versus buy calculation had two buckets. Build meant development cost plus maintenance. Buy meant licence, implementation, integration, customisation, and eventual upgrade. Historically the development box in the build column was the largest and most uncertain cost, which is exactly why buy won by default for anything that was not clearly strategic.

AI has shrunk that one box dramatically. Nothing else in either column has changed. Licence fees, implementation, customisation, upgrade programmes, and integration cost are all exactly as expensive as they were five years ago. What has moved is the crossover point. Twenty years ago you only built when a capability was important enough to absorb a large, uncertain development cost. Today that same threshold is met by a much wider set of capabilities, because the development cost that used to gate the decision has fallen by an order of magnitude.

There is a second shift sitting next to the cost question, which is pace. Historically the vendor won the innovation race, because they had a dedicated product team and you did not. That is no longer a safe assumption. An internal team with a clear object model can often implement this afternoon a feature that sits on a vendor’s public roadmap nine months out. When your own team can move faster than the vendor you are paying, the case for buying has to rest entirely on the argument that the capability is not worth building well, which is a much narrower argument than most procurement conversations admit.

7. A framework for 2026

The way I actually make this decision now runs on two questions rather than one. The first is the question I always asked. Is this capability core to how we compete, or is it commodity. The second question is newer and matters almost as much. How fast does this capability change.

Strategic importance and rate of change together give a genuinely useful map. Low importance and low rate of change, payroll being the obvious example, is an easy buy. High importance paired with low rate of change is a mixed case that deserves real judgement rather than a rule. Low importance paired with high rate of change usually still leans buy, because you do not want to be the one maintaining a fast moving commodity capability yourself. High importance paired with high rate of change is the clearest build case there is, and fraud decisioning is the example I come back to most often, because a fraud model that only updates on a vendor’s release cycle is already behind the fraud patterns it is meant to catch.

There is a gray area, better called a grey area, worth naming inside this framework, because it is the one that quietly traps organisations who thought they had drawn the line correctly. A system can look like textbook commodity and still become core through data gravity. Customer ticketing is a fair example. Nobody wins market share because their ticketing tool is elegant, so the instinct is to buy without a second thought. But if your fraud models or your customer context engines depend on parsing the unstructured data sitting inside those tickets, a closed vendor ecosystem has quietly become a bottleneck on a capability you consider core. The fix is not to build ticketing yourself. It is to make data liquidity a non negotiable condition of any commodity purchase, so the vendor never gets to sit between you and the data your actual core systems need.

8. Governance has to move as fast as the building does

None of this is a licence to skip architecture discipline, and the faster building gets, the more true that becomes rather than less. If it becomes trivially easy for any engineer to spin up a workflow tool in an afternoon, the real risk shifts from build cost to sprawl, a growing pile of hyper custom, AI generated utilities with no shared data lineage, no consistent compliance story, and no owner once the person who prompted it moves teams. AI accelerated building still needs the same architecture governance you would apply to anything else, just applied earlier and more consistently, or you trade vendor lock in for a mess entirely of your own making.

9. Two failure modes, not one

I want to be honest about the failure mode on my own side of the argument, not just the vendor side. Teams that build everything out of ego make the same mistake as teams that buy everything out of fear of hiring their own engineers. Neither is a strategy. One is a preference dressed up as a principle, and the other is an insurance policy dressed up as a decision.

The organisations that get this right are the ones that can say, clearly and without flattery to themselves, which of their systems are core and which are commodity, how fast each one is actually moving, and then have the discipline to build accordingly, even when their instincts or their existing contracts point the other way.