Build vs Buy in the Age of AI

One topic that has been around since the beginning of the tech industry, is whether we should build or buy in order to solve some problem?

This question applies to traditional IT, as well as to every product team.

There are often one or more buy alternatives, but each comes with an associated cost, and usually limitations in functionality. But of course building comes with its own well-known challenges, both in terms of creation time and cost, and ongoing maintenance.

For most companies, if the problem we’re solving represents a core competency, then we usually build. But if it’s outside our core competency, we try to buy. But of course there’s lots of exceptions, and also there are many problems that are so specialized that there are no buy options.

Moreover, in many cases, “buy vs build” has always been an oversimplification, as it’s very common to buy, and then need to customize in order to tailor to the needs of your particular business, especially in large enterprises.

Historically, while the product teams had the luxury of being able to build, the rest of the company typically did not. Which is why “the business” would so often have an endless list of requests for “IT”.

The Advent of User Programming

This first started to change in 1979, with the invention of the first form of user-programming tool, designed to run on the first personal computers: the spreadsheet Visicalc built for the Apple II.

User programming refers to “programming” by non-technical people. And especially at the time, this was enormously empowering.

Today, countless millions of user-created programs (mainly formulas) run in Excel and the like across most companies in the world. And Visual Basic (first released in 1991), enabled millions more, which was probably the first low-code option. Even before generative AI, there was a wave of low-code and no-code options for non-technical people.

But now, thanks to Generative AI, we are seeing the rise of a major new generation of user-programming tools, with products such as Lovable and Bolt, where essentially the programming language is now English, which opens these capabilities up to nearly anyone with a problem to solve.¹

But just to be clear, we have always had the build vs buy choice; and non-technical people have often had options. The only question was the particular skills required to use the tool, and the type of app that the tool was designed to build.

That said, what’s so impressive about the new generation of user programming tools (aka vibe coding) is that the main skill you need is natural language (English), and the types of apps you can build are much less constrained.

The Future of Business Software Solutions

While this historical perspective is hopefully useful, the reason for this article is that today, many people would have you believe that the new generation of user programming tools means that everyone will build, and nobody will buy. And therefore the SaaS players are doomed.

What I wanted to explain is why this is almost certainly not true.

At the risk of oversimplification, the reason your business software – procurement, invoicing, payments, budgeting, forecasting, payroll, staffing, sales force automation, customer relationship management, customer service, etc. – is not likely to be replaced with a user programmed solution is due to business rules and the associated business logic.

What most people don’t realize is that there are literally thousands of often complex business rules, and millions of lines of business logic, behind most enterprise business solutions. These rules and code capture constraints and processes around policy, compliance, security, legal, financial, pricing, and more.

And many of these rules take considerable time and effort to discern and to codify.

The vast majority of non-technical people that wish to create business apps have little to no idea about these business rules. Even the technical people struggle with these rules because mostly they are embedded in the code as business logic, and the people that defined and implemented these rules have often moved on long ago, and while there might (rarely) be a document describing the business rules, those documents almost never explain the reason and nuance behind each rule.

This is the knowledge that product managers (and the business analysts before them) acquire in order to define viable solutions.

This is also one of the reasons why addressing technical debt is often so difficult, because we have to tease out the business rules, and decide which still apply going forward.

So a system that captures, manages and enforces the thousands of essential business rules, and ensures transactions are handled the way they need to be, is going to be real work to create, but valuable to have.

However, because of this value, while the strong SaaS vendors are not likely to disappear anytime soon, I do believe that big changes are coming.

Today, these business solutions were created to be used by people (although many of these SaaS vendors are so weak at product design it’s understandable if you doubt this).

But going forward, these solutions will not be used just by humans, but also by AI agents, and by new custom solutions crafted (vibe-coded or hand-coded) on top of these component solutions.

The Model Context Protocol

What I’m describing here is something extraordinarily powerful for complex enterprises.

The major enabler for this is something that we have long needed, starting with the advent of the internet, but is only now becoming a reality.

The industry has needed a widely accepted protocol to describe business services that can be read and understood by computers and not just people. About a year ago, Anthropic proposed The MCP Protocol, and it has rapidly gained traction because it solves such an important, long-standing architectural problem.²

So if I’m correct, then the future of build vs buy will be “yes to both.”

Companies will continue to buy complex and valuable component services for important parts of their business, but these components will be designed to be accessed and controlled by both humans and software. Some of that software will be AI agents acting on our behalf, and some will be customer (or system integrator) defined workflows generated from gen AI tools.

I expect that these AI agents will be created by the vendors themselves, by systems integrators, and by end customers.

The Age of User Programming

So far, user programming has largely been on the margin. But the new generation of tools is quickly bringing these capabilities to the mainstream.

I consider this overall to be a very good thing for the countless people that have been living with very constrained IT resources.

That said, as more non-technical people aspire to create solutions beyond simple personal time-savers, they will need to learn much of what the product world has learned.

And the most important lesson of all is that the hard part is rarely building and delivering the solution; the hard part is discovering the right solution to build.

Note that I’m distinguishing here between the vibe-coding tools designed primarily to increase the productivity of software engineers, such as Cursor and Replit, versus those aimed more at non-technical users. That said, the space is developing rapidly so these companies may evolve their positioning based on the market.
↩︎
It’s beyond the scope of this article to discuss why it took 30 years for this to happen, even though it was not a technical constraint, but sometimes for a problem like this to be solved, you have to wait until the stars align, and this has finally happened.
↩︎

Build vs Buy in the Age of AI

Comments