Build,Modify,Buyin the Era of AI

Conventional wisdom in enterprise software has always favored “buy” over “build.” Engineers, on the other hand, almost always want to build. Somewhere between those two instincts sits “modify,” a model that’s especially common in research and discovery organizations, where unique and rapidly evolving needs push teams to work with vendors to extend or customize off-the-shelf software.

Modify gets you most of the way there, but it tends to leave vendors carrying a long tail of edge-case features that are poorly developed and inconsistently supported across their customer base.

This is the strategic question I want to revisit, because the ground underneath it is shifting fast. AI is changing the economics of software development, and the old build/modify/buy decision matrix doesn’t quite fit the world we’re walking into.

The Traditional Framework

Let’s start with the version most of us have been using for the last decade or two.

And once again, XKCD has summed it up as well:

All joking aside, the Build vs Buy decision matrix usually looks like this.

It was never really three options

The real decision is multi-axis: internal resources, time available, uniqueness of need, cost, strategic value, competitive advantage, in-house domain expertise, the rate your needs are changing, and the opportunity cost of pulling resources off other work.

The Roots of the Build Challenge

Software development has always been difficult, slow, and expensive. In lab automation, it’s worse. We layer scientific domain expertise on top of already-complicated hardware and software engineering.

Three deep domains, one team

Lab automation lives at the intersection of Science, Software, and Hardware. Individual engineers rarely cover all three in depth.

Why Agile exists, and what it costs

Agile and Scrum solve one core challenge: a repeatable process for predictable management of software development that maximizes developer time and produces incremental, verifiable deliveries. The trade-off is significant process overhead, most of it dedicated to keeping non-expert teams from building the wrong thing.

Four uncomfortable data points

This is the world that produced the conventional wisdom: “buy if you can, build only if you must.”

What’s Changing

The driver of change, of course, is AI. We don’t yet have great data on the full impact, because the capability frontier moves faster than studies can track it.

The Moore’s Law of AI capability

METR’s recent work on “task time horizon” (how long a task an AI can autonomously accomplish) shows the frontier roughly doubling every seven months. By the time a study is published, the data is already obsolete.

“The future is already here. It’s just not evenly distributed yet.”

William Gibson

Software development is probably the area AI has impacted earliest and most dramatically. The software industry is being disrupted ahead of others. We’re seeing the future first.

A 100x gap between the median and the frontier

Bolting AI onto the old process

Change is hard inside large organizations, and there isn’t a good roadmap yet for restructuring teams and processes to capture AI-native productivity at scale. Most large organizations are simply bolting AI-assisted coding onto their existing Agile/Scrum process.

They get some lift on the coding step itself, but planning, review, QA, deployment, and coordination barely move. AI accelerated 25% of the work; the other 75% is unchanged. Even if coding time went to zero, the impact wouldn’t match teams using a fundamentally new process.

The electrification parable

Before electrification, factories distributed power through massive line shafts and belts driven by central steam engines. When electricity arrived, the first move was the obvious one: replace the steam engine with an electric motor, and keep the line shafts.

It was a marginal improvement. No more shoveling coal, but the architecture was unchanged. The real productivity unlock didn’t arrive until factories redesigned around individual electric motors on each machine. That let them rearrange the shop floor, scale production dynamically, and reorganize workflow around the new primitive.

SaaS Is Breaking Down

There’s a structural consequence of this shift that we’re only beginning to absorb. The Software-as-a-Service model is starting to break down.

What SaaS originally solved

• Distribution and deployment of complex software
• Lower upfront cost than perpetual licenses
• Centralized maintenance

What SaaS bakes in

• Built for the average user, not your workflow
• Customization is shallow: configure, not redesign
• Roadmap controlled by the vendor, not you
• Your data ends up locked in silos

Enter MaaS

An emerging alternative, Modify-as-a-Service, proposes that instead of renting generic tools, customers subscribe to continuously evolving, custom-built software that they own and control.

What This Means for Build/Modify/Buy

Software development costs are dropping. Delivery timelines are improving significantly. Traditional SaaS is fragmenting. It’s hard to know how quickly this will play out, or how far it will go.

Three things follow

Code is no longer a moat. Domain expertise is. The differentiator isn’t “we wrote it.” It’s “we understand the challenge deeply enough to keep evolving it.”

People matter more, not less. What you pay a vendor for is increasingly their ability to service, support, secure, and evolve systems against your changing needs, rather than the static code itself.

Successful vendors will be smaller and nimbler. Deep domain knowledge, fast deployment of interoperable components, and ongoing support, rather than bloated feature catalogs.

A new X-axis for the decision matrix

How the recommendations shift

Business-critical infrastructure: still favors Buy or Modify, with strategic resourcing for long-term support. The risk profile demands it.

“Nice to have” productivity tools: can absolutely be vibe-coded in-house with low risk, vetted for security. Three years ago this would have been crazy. Today it’s a Tuesday afternoon.

The key vendor question is new. It’s no longer “do they have what I need?” It’s “do they understand my challenge deeply enough to evolve with me?” A great vendor should be able to build new functionality almost as fast as you can generate requirements.

Practical Takeaways

The question has changed

That’s a different question. And the organizations that adapt to asking it well are going to pull away from the ones still stuck in the old paradigm.