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 one that already exists?

Back then it was mostly an enterprise decision. Large companies had engineering teams, IT budgets, infrastructure and security people, and enough scale that a custom system could pay for itself. Most small and medium businesses had nothing to decide. They bought software.

Not because the software fit well. Often it didn’t. A small business might use a tenth of what its CRM, ERP or workflow tool could do. But building something better meant developers, servers, testing, deployment, and years of maintenance and support.

AI coding tools have changed that. A founder, an operations lead or a shop owner with some technical curiosity can now build useful software in a fraction of the time and money it took a few years ago.

So Build vs. Buy is no longer a question only CIOs and enterprise architects get to ask. A solo founder can ask it. So can a ten-person company, or the owner of a corner shop.

A simple example: a printing shop’s CRM

Picture a small printing company that needs a CRM. A commercial one comes with lead scoring, campaign automation, sales forecasting, multiple pipelines, hundreds of integrations, fine-grained permissions, analytics, an AI assistant, and a lot more.

That makes sense for the vendor, who has to sell one product to thousands of very different companies. The printing shop’s problem is much smaller.

A customer sends an artwork file. The shop quotes. The customer approves and pays a deposit. The job goes to production. When it’s printed, the shop tells the customer, collects the balance and delivers.

Then there are the details only this shop cares about. Prices depend on paper, quantity, finishing and which machine is free. Customers talk on Zalo or WhatsApp, not email. Quotes and invoices have to follow how things are done in that market.

Until recently the owner had two options: buy a general CRM and bend it as far as it would go, or keep running the business on spreadsheets, chat apps and memory. Now there’s a third. Build a small system around the way the shop actually works.

For decades, businesses changed their processes to fit the software they could buy. Now the software can be shaped to fit the process.

The hidden cost: building is not just building

That doesn’t mean every small business should start writing its own apps. Cheap development creates a trap: if something is easy to build, it must be cheap to own.

It isn’t.

The first version is where an application’s life starts, not where it ends. Once it’s live, someone has to keep it running. Bugs need fixing. Dependencies need updating. The database needs backups. APIs change. Permissions change. Security holes turn up. The business changes, and staff ask for changes too.

Sooner or later something breaks at the worst possible moment, and someone has to work out why.

Experienced technology teams know development is only one slice of the total cost of owning software. Business owners who have just discovered AI coding often haven’t learned that yet.

AI makes software much easier to build. It doesn’t make it any easier to own.

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

The old question was Can we afford to build this? More and more often, the answer is yes.

The better question now is Should we own this?

Take payroll. For most businesses it’s a bad candidate for custom work: complicated, regulated, and no different from what everyone else needs. The same goes for payments, login, accounting, email delivery and file storage. Mature products already do these well, and getting them wrong is expensive.

A very specific internal workflow is another matter. If five people spend hours a day copying data between systems, checking exceptions, building reports or following a process only your company has, a small purpose-built app can pay off quickly.

So the line isn’t between generic and custom software. It’s between the parts where owning the software gives you an edge and the parts where it just gives you more to look after.

The questions to ask now

• Is the process unique? The more it reflects how your company specifically works, the stronger the case for building.
• Does a perfect fit actually matter? It matters when it changes productivity, the customer experience or the economics. Otherwise a close fit is fine.
• What happens when it fails? A convenience tool for the office and a system the business can’t run without deserve different standards. The same question decides which business tasks are safe to automate.
• How often will it change? Every custom app is a maintenance commitment, and frequent change makes that commitment bigger.
• Who owns it after it’s built? If nobody has a good answer, stop here.

Buy the foundation. Build the differentiation.

We don’t think the future is pure build or pure buy. Most businesses will do both.

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

A company might use Stripe for payments, a cloud provider for hosting, an identity service for login and an established accounting package for the books. On top of that it builds a thin layer of its own software that reflects how it actually operates.

That layer could be a specialized workflow, a reconciliation tool, an internal dashboard, a small customer portal, or something that connects existing systems in a way only this business needs.

This is where AI-assisted development earns its keep. A small company has no reason to rebuild Salesforce, QuickBooks or Stripe. The piece that connects those platforms to the way the company actually works is often worth building, and nobody sells it.

Software that never made sense to build before

Plenty of useful applications were never built because the economics didn’t work. Too niche to be a SaaS product, too expensive to justify as an internal project.

A tool used by eight people might save hundreds of hours a year and still not justify six months of several engineers’ time. Cut that effort by ten and thousands of those tools start to make sense.

That points to a kind of software somewhere between SaaS and traditional custom development. Some of it will serve one company, and may be worth more there than as a product. Some will serve one department. Some will live for a couple of years and then be thrown away.

None of it needs millions of users. It only has to solve one operational problem precisely.

A new generation of builders

The person who understands a business problem best is usually not a software engineer. It’s the operations manager, the finance lead, the hotel GM, the head of sales, the consultant, the owner.

That person used to explain the problem to developers, who translated it into software, with plenty lost along the way. AI shortens the distance between understanding a problem and building the fix.

Software engineering still matters. The more important a system gets, the more architecture, security, reliability, testing, monitoring and maintainability matter too.

What changes is the bar. Problems that were too small to justify software now clear it.

Eight years ago, Build vs. Buy was a topic for enterprise software strategy.

Now it’s a business decision for almost everyone.

More people being able to build software is the obvious part. The bigger change is that very small, very specific software now pays for itself.

A small printing shop doesn’t need its own Salesforce. It might do very well with software built exactly around how that shop works.

AI gives businesses the ability to build it.

The hard part is knowing when to use that ability.