Build vs. Buy in the Age of AI

A different question today

Eight years ago, Build vs. Buy was the classic software question: should a company build a system itself, or buy an existing product?

At the time, this was largely an enterprise technology decision. Large companies had internal engineering teams, IT budgets, infrastructure, security capabilities, and enough scale to justify evaluating whether a custom-built system might create strategic value. For most small and medium businesses, there was not much of a decision to make. They bought software.

That was not necessarily because commercial software was a perfect fit. Often it was not. A small business might use only a fraction of the functionality in a CRM, ERP, or workflow platform. But building an alternative required developers, infrastructure, testing, deployment, maintenance, and ongoing support.

AI is changing that assumption. With modern AI coding tools, a technically curious founder, operator, or small-business owner can now create useful software with a fraction of the time and resources that would have been required only a few years ago.

The barrier to building has fallen so dramatically that “Build vs. Buy” is no longer a question reserved for CIOs and enterprise architects. It can apply to a solo entrepreneur, a ten-person company, or the owner of a neighborhood business.

A simple example: a printing shop’s CRM

Imagine a small printing company that needs a CRM. A commercial CRM might include lead scoring, campaign automation, sales forecasting, multiple pipelines, hundreds of integrations, sophisticated access controls, analytics, AI assistants, and dozens of other functions.

Those capabilities make sense because the vendor is creating one product that needs to work for thousands of different companies. But the printing shop may have a much simpler problem.

A customer submits an artwork file. The shop prepares a quotation. The customer approves it and pays a deposit. The job moves into production. When printing is complete, the customer is notified, the balance is collected, and the order is delivered.

There may also be details that matter specifically to this company. Pricing might depend on paper type, quantity, finishing options, or machine availability. Customers may communicate primarily through Zalo or WhatsApp instead of email. Quotations and invoices might need to follow the practices of that particular market.

Historically, the owner had two realistic choices: buy a general-purpose CRM and customize it as much as possible, or continue working through some combination of spreadsheets, messaging apps, and manual processes. Now there is another possibility: build a small system around the way the business actually works.

This is an important shift. For decades, businesses often adapted their processes to the software they could buy. AI increasingly makes it possible for software to adapt to the process instead.

The hidden cost: building is not just building

None of this means every small business should start creating its own applications. In fact, the lower cost of development can create a dangerous illusion: because something is easy to build, it must also be inexpensive to own.

Those are two very different things.

The first version of an application is only the beginning of its lifecycle. Once it is deployed, somebody has to keep it running. Bugs need to be fixed. Dependencies need to be updated. Databases need backups. APIs change. User permissions evolve. Security vulnerabilities appear. Business processes change. Employees request modifications.

Eventually, something breaks at an inconvenient time and somebody has to understand why.

This has always been one of the less visible costs of software. Experienced technology organizations understand that development represents only one part of total cost of ownership. Small-business owners who are newly empowered by AI coding may not yet have that experience.

AI can make software dramatically easier to build. It does not automatically make software easier to own.

From “Can we build it?” to “Should we own it?”

In the past, the question often started with: Can we afford to build this? Increasingly, the answer may be yes.

A better question today is: Should we own this?

Consider payroll. For most businesses, it is a poor candidate for custom development. Payroll is complicated, regulated, and largely non-differentiating. Similar logic applies to payment processing, authentication, accounting, email delivery, cloud storage, and many other commodity capabilities. Mature products already solve these problems well, and the cost of getting them wrong can be significant.

A highly specific internal workflow is different. If five employees spend hours every day moving information between systems, checking exceptions, preparing reports, or following a process unique to the company, a small purpose-built application may create significant value.

The distinction is not simply between generic software and custom software. It is between capabilities where ownership creates an advantage and capabilities where ownership creates unnecessary responsibility.

The questions to ask now

• Is the process unique? If it is highly specific to how the company operates, custom software becomes more interesting.
• Does customization create meaningful value? A perfect fit matters when it materially improves productivity, customer experience, or economics.
• What happens when it fails? An internal convenience tool and a mission-critical system should not be evaluated using the same standard.
• How often will it change? Every custom application creates an ongoing maintenance obligation.
• Who owns it after it is built? This may be the most important question of all.

Buy the foundation. Build the differentiation.

We suspect the future will not be dominated by either pure “build” or pure “buy.” Instead, businesses will increasingly combine the two.

They will buy the foundations and build the parts that make them different.

A company might use Stripe for payments, a cloud platform for infrastructure, an identity service for authentication, and an established accounting product for its financial records. On top of those services, it can build a relatively thin layer of software that reflects its own operating model.

That layer might be a specialized workflow, a reconciliation engine, an internal dashboard, a small customer portal, or an application connecting several existing systems in a way that is unique to the business.

This may be one of the most valuable areas for AI-assisted development. There is little reason for a small company to recreate Salesforce, QuickBooks, or Stripe. But there may be enormous value in building the missing piece between those platforms and the way the company actually operates.

A new class of software becomes economically possible

Many useful applications were never built in the past because they occupied an awkward economic space. They were too specific to become commercial SaaS products, but too expensive to justify as internal development projects.

A system used by eight employees might save hundreds of hours per year, yet still not justify a six-month software project involving several engineers. If AI reduces that development effort by an order of magnitude, thousands of previously uneconomic applications suddenly become viable.

This could create a new category of software somewhere between traditional SaaS and traditional custom development. Some applications may serve only one company. Others may serve one department. Some may exist for only a few years.

Their value does not come from serving millions of users. Their value comes from how precisely they solve one operational problem.

A new generation of builders

The person who understands a business problem best is often not a software engineer. It may be an operations manager, finance manager, hotel GM, sales leader, consultant, or business owner.

Historically, that person had to explain the problem to a development team, which then translated the business requirement into software. AI dramatically shortens the distance between understanding a problem and creating something that solves it.

That does not make software engineering irrelevant. The more important a system becomes, the more traditional engineering disciplines still matter: architecture, security, reliability, testing, observability, performance, and maintainability.

What changes is the threshold. We can now justify building software for much smaller problems.

Eight years ago, Build vs. Buy was mostly an enterprise software strategy discussion.

Today, AI is making it a business decision for almost everyone.

The interesting part is not simply that more people can build software. The more important change is that the economics of very small, very specific software are becoming viable for the first time.

A small printing shop does not need its own version of Salesforce. But it may benefit enormously from software designed precisely around how that printing shop works.

AI gives businesses the ability to build that software.

The challenge now is learning when that ability should be used.