Build vs. Buy in the Age of AI

· 6 min read

For almost my entire career, split between enterprise operations and software teams, the build vs. buy discussion has come up. Before the cloud, when the work of setting up and configuring software was even more challenging than it may be today, the question was mostly about how much work it took to install, update, and maintain a vendor's software versus simply building something more bespoke. There were also far fewer software options available to enterprises, so the question of custom came up often — few vendors could meet all of your requirements without potentially costly manual configuration. Naturally this was not true of all enterprise software. Most of us even then bought a third-party mail platform (thanks, Lotus Notes), but the long tail of everything else was frequently custom built.

Then the cloud came, and suddenly the ability of software companies to build almost everything made building your own a task few enterprises wanted to embark on, except in very specific cases. Many years back, when I was at Novartis, we spent significant resources building out a Real World Evidence solution — but that was with partners, and because no such solution really existed to support pharmaceutical research with all its controls and regulatory hurdles. Certainly there were times when a team would look at a solution (a workflow tool, a work-management tool, a company portal) and think it could very easily be built in house, and maintained, for cheaper. For those who embarked on that, though, there were often unexpected consequences.

Consequences of Custom Application Development

One of the largest challenges of choosing to build was this: the subscription fee paid to a vendor is enforced by contract, and no such contract exists between an organization and its own staff — or even the contracted resources brought in to do the work. To speak plainly, when cost pressure enters the picture it is very easy to shrink the team to the point where it can no longer update the software the way it once could. A company that willingly spent $1M–$2M a year for a piece of enterprise-grade software suddenly cuts the development team to $400K a year in human capital, with the expectation that development is 'done'.

This leads to the cycle you would expect. The software gets held together on old versions of middleware, with dated graphics and grumpy developers who leave for greener pastures, replaced by even more junior developers who struggle to keep the platform running. After running at that deep technical deficit for years, a manager looks at the upgrade cost — now equalling not just the entire build of a net-new platform but an expensive data migration on top of it — and reconsiders the decision to build. So they go back to buying.

Our manager in this case is not wrong. At the point the software has been left to decay that long, the choice is obvious: retire the thing and buy something from a vendor that looks, and possibly works, ten times better than what was built five years ago. But this ignores the reality that brought us here. A small development team, with proper care, can compete with costly enterprise software — as long as they are allowed to develop, and are treated the way a product team would typically be treated.

Spec-Given Development, AI Coding Tools, and How Things Work

I'm not a professional developer. I work with a lot of professional developers who use AI tools to greater or lesser degrees for code-assisted development. At the time this was written there were a wide variety of tools that let developers be significantly more productive. The jury is still out on what that means in the long term: how much of that code turns out to be slop, how thoughtful developers are being about reviewing it, and how good the platforms really are. I'm not going to relitigate that debate here. I'm simply going to say that the vast majority of developers I know who use newer models — not just frontier ones — are far more productive at actually building solutions than they were before these models existed.

The reason this is significant is that it adjusts the mathematics. It allows activities like regression testing, UI testing, review, pipeline building, and even core code to be mostly automated by careful and thoughtful engineers who review the work.

The model I have put together assumes this. So read through the explanation below, download the spreadsheet, and see for yourself whether your enterprise really needs to buy the new SaaS tool — or whether maybe, just maybe, today you can build again what you actually need.

One More Caveat

There is another side to this, one I wrote about years ago in The Dark Side of Innovation, that needs to be considered. Many teams in IT operations have become used to blaming the vendor. When a major SaaS vendor has an issue, there may be little we can do in operations but point a finger and wait for a fix — or raise our voices and threaten. Large-scale issues, like Azure outages, are met with shaking heads and frustration, but there is very little enterprise IT can do about them.

When you own the product, though, and you are functioning as a product team, you are back in the world where everything is your responsibility. Even a complaint about a cloud vendor's slowness can be met with a switch to another cloud, or multi-cloud, or regional work. As you staff out the team, ensure you have appropriate non-engineering talent capable of doing true product work.

The Basic Model

Annual cost to buy
  = (license per seat × seats)
  + (admin team × loaded cost)
  + customization tax

Annual cost to build
  = (build team × loaded cost)
  + infrastructure
  + risk premium

Break-even seats
  = (build cost + infra − admin cost)
    ÷ license per seat

Plug in defaults: 15 engineers at $250K loaded ($3.75M) and $1M of infrastructure — and note that buying still costs you a six-person admin and integration team ($1.5M), because enterprise software usually requires internal teams anyway. Against a $20/seat product, break-even lands around 160K seats. (The downloadable model is stricter: once you also charge the risk premium and the customization tax, break-even lands nearer 185K.)

Annual cost versus seat count Line chart of annual cost in millions of dollars against seat count from 25,000 to 800,000 seats. Buying rises steeply from $2.5M to $18M because it scales with seats. Building stays nearly flat: $5.5M to $6.3M with fifteen engineers, and $3.5M to $4.3M AI-assisted with eight. Buying overtakes the AI-assisted build at about 78,000 seats and the conventional build at about 184,000 seats. $0M $5M $10M $15M $20M 25K 50K 100K 200K 400K 800K Seats Buy $20/seat + 6 admins Build 15 engineers Build, AI-assisted 8 engineers ≈ 78K ≈ 184K
Annual cost vs. seat count at the model’s default inputs. Buying scales with seats; building barely does — though build costs do rise as counts get higher, since infrastructure scales with users.

The AI wrinkle is that construction got cheaper, so the crossover slides from ~160K seats down to ~80K. A 200K-seat enterprise is now in 'build' territory for anything priced above roughly $15/seat. But the model above is missing the four terms that actually kill internal builds:

  1. Time to value. Buy delivers in a quarter. Build delivers in 12–24 months of paying the team for nothing. That's $4–8M of pure burn for most products.
  2. You now own a product. Security patching, compliance evidence, accessibility, on-call, the integration that breaks every time Microsoft sneezes. Maintenance is 60–80% of lifetime cost, and AI helps with that far less than it helps with initial construction. A codebase that eight people generated in six months is a codebase nobody fully understands by year three.
  3. The roadmap treadmill. The vendor amortizes their engineering across 10M seats. You will amortize across 200K. Every feature they ship, you either rebuild or fall behind.
  4. Key-person risk at 15 people is worse than at 200. Two resignations and you own an orphan. Vendors often have an organizational resilience you cannot replicate at small scale.

The Rule

Build only when all of these hold: the workload is differentiating rather than commodity; loaded team cost per seat is under roughly 60% of license cost (the other 40% pays for the four terms above); you would keep the team for five-plus years; and the vendor's per-seat price is punitive relative to what the software actually does.

That last clause is where AI hurts. A $30/seat/month AI add-on across 200K seats is $72M a year, which funds a 288-person organization. A four-person team wrapping models around your own data doesn't need to be as good as the vendor's. It needs to be good enough, and $70M cheaper.

So the answer is: yes, buy the platform. But the age of AI didn't move the 'buy' line. It moved the 'what's worth building' line — from 'software for millions' to 'the thin layer on top of the software you bought that the vendor is charging you rent for'.

The Spreadsheet

The model behind all of this is a spreadsheet — download and use it if you wish.