AI has changed the build-vs-buy calculation for small businesses

For years, the sensible advice to a small business was usually: don't build software if you can buy it. AI hasn't made that advice wrong. But it has made the calculation much more interesting.

There's an old rule in software: If something already exists, buy it. Usually, that's very good advice.

Why spend months building an accounting system when you can buy one? Why build a CRM when excellent CRMs already exist? Why create your own ecommerce platform?

Project-management software? Email platform? Booking system?

Payment processing? For most small businesses, custom software has historically been expensive enough that you needed a very good reason to build rather than buy. AI is beginning to change that calculation.

Not because businesses should suddenly build everything themselves. They absolutely shouldn't. But because the cost of creating certain kinds of software is falling.

And when the cost changes, some of the decisions change with it.

The old build-vs-buy calculation

Imagine a business has an awkward internal process. Perhaps staff receive information from customers, check it against several things, put it into another system, create a document, send something back and update a record. It's annoying.

It's repetitive. Everybody knows it could be better. So the business looks for software.

Product A does 60% of what they need. Product B does 70%, but requires them to change their process. Product C is designed for much larger companies and costs a fortune.

Nothing quite fits. Historically, the alternative was custom development. And that might mean:

requirements, design, development,

testing, integrations, project management,

deployment, and ongoing maintenance. Suddenly the irritating process didn't look quite irritating enough to justify building software around it.

So the spreadsheet survived another five years.

Businesses have always adapted themselves to software

I've seen this throughout my career in web and digital. A company buys a system. The system almost fits.

So the business changes the way it works. Then somebody creates a workaround for the bit that doesn't fit. Then another workaround.

Eventually you get: the main system, a spreadsheet,

a shared folder, an email process, a manual check,

and one person who understands how all the pieces fit together. The software was supposed to support the process. Gradually, the process starts supporting the software.

SaaS solved an enormous problem

I don't want this to sound like an argument against software-as-a-service. SaaS has been transformational for small businesses. For a relatively modest monthly fee, a small company can access systems that once would have required enormous technical investment.

CRM. Accounting. Payments.

Email marketing. Project management. Ecommerce.

Support. Analytics. HR.

The economics are extraordinary. And for standard business functions, buying will often remain the obvious answer. AI doesn't change that.

What AI changes is the edge

The interesting bit is everything around those core systems. The unusual workflow. The company-specific process.

The missing integration. The internal tool. The customer portal that doesn't quite exist.

The admin process that's too specialised for an off-the-shelf product. The little piece of software that would save hours but was never worth commissioning. That's where AI-assisted development changes things.

Building software requires less mechanical effort

Software development has always involved far more than typing code. But typing, debugging, refactoring, testing, documentation and understanding existing code all consume time. AI can now assist across much of that work.

That means an experienced technical person can potentially move from idea to working software much faster than before. And that's important economically. A tool that wouldn't justify four weeks of development might justify four days.

Something that wouldn't justify four days might justify four hours of prototyping to see whether the idea works. The threshold for worth trying moves.

This doesn't mean "vibe code your business"

There's a dangerous leap from: AI makes software easier to create. to:

Anyone can now build production software by describing what they want. You can certainly build surprisingly impressive things that way. The question is what happens after the impressive bit.

Who thinks about: authentication, permissions,

security, data, backups,

errors, integrations, performance,

monitoring, accessibility, maintenance,

and what happens when the person who built it isn't there? A prototype and a dependable business system are different things. AI has reduced the cost of creating software.

It hasn't abolished software engineering.

The prototype is where the change is particularly dramatic

This is one of the parts I find most exciting. Historically, even finding out whether an idea worked could be expensive. You might need to:

write a specification, design it, build it,

connect systems, and test it before you had something useful enough to put in front of people.

Now it's possible to explore much further before making a large commitment. Can this workflow work? Would customers use this?

Can these systems connect? Can AI handle this part reliably enough? Does this interface make sense?

Can we eliminate these manual steps? You can answer more of those questions with working software rather than meetings and documents. For small businesses, that's significant.

The choice is no longer simply build or buy

I think there are now at least four options.

BUY

Use an existing product largely as intended. Best when the problem is standard and the product already solves it well.

CONFIGURE

Use an existing system, but tailor its workflows, fields, rules and integrations. Often the right answer.

CONNECT

Keep the systems you already have and build the missing layer between them. This is becoming increasingly interesting.

BUILD

Create software specifically around the business requirement. AI is making this option viable in more situations. The useful question isn't:

Should we buy software or build it? It's: Which parts should we buy, configure, connect and build?

The hybrid answer is often the best one

Suppose you need a customer portal. Don't build payment processing. Use a payment provider.

Don't necessarily build authentication from scratch. Use established infrastructure. Don't build an email delivery network.

Use an existing service. But perhaps the workflow that happens between those components is unique to your business. That's where custom development can make sense.

Build the thing that differentiates or fits your process. Buy the commodity infrastructure underneath it.

AI makes the connective tissue cheaper

I think this is one of the biggest opportunities for small businesses. Often they don't need an entirely new system. They need their existing systems to work together properly.

The website. CRM. Payments.

Email. Documents. Database.

Customer portal. Internal workflow. Historically, the integration work between these systems could become expensive.

AI-assisted development can make building those connections faster. And increasingly, AI itself can help bridge systems where traditional integrations are awkward. The result doesn't need to be a giant new platform.

It might simply make the systems the company already pays for work like one system.

This can reduce SaaS sprawl too

There's another interesting consequence. Businesses sometimes buy an entire software product because they need one feature. Then another because they need another feature.

Soon they're paying for: five platforms, overlapping functionality,

multiple user licences, and several integrations, while employees still copy information between them.

At some point, building the missing capability may become cheaper than buying yet another platform. Not always. But much more often than before.

Subscription cost changes the calculation

Imagine a specialist SaaS product costs £500 a month. That's £6,000 a year. Perhaps it's worth every penny.

If it saves £20,000 of work, buy it. But perhaps the company uses 10% of it. And the feature it actually needs is relatively narrow.

Historically, building an alternative might have cost £20,000 or £30,000, so the subscription still made sense. If AI-assisted development significantly reduces the cost of creating that narrow capability, the calculation changes. Now you can compare:

licence cost, implementation, customisation,

integration, training, switching,

ownership, maintenance, and long-term dependency.

The sticker price isn't the whole cost on either side.

Owning software has value

There are situations where owning a particular piece of software matters. You control the workflow. You decide what changes.

It can fit the business precisely. You aren't waiting for a vendor's roadmap. You may be able to integrate it more deeply.

You aren't paying per-seat pricing for the software itself. That can be attractive. But ownership comes with the other side too.

You own: the bugs, the maintenance,

the security, the updates, the hosting,

the technical debt, and the responsibility for keeping it working. "Custom" doesn't mean "free forever".

Buying has enormous advantages

When you buy good software, you're not merely buying the feature you can see. You're also potentially buying years of: development,

security work, testing, support,

documentation, infrastructure, compliance,

updates, and lessons learned from thousands of customers. That is very difficult to replicate.

So if a mature product already solves the problem well at a sensible price, I'd need a good reason to rebuild it. AI doesn't turn rebuilding Stripe into a sensible weekend project.

Build where the business is unusual

This is probably the most useful rule. Buy the standard. Build the specific.

Accounting is standard. Payment processing is standard. Email delivery is standard.

Your peculiar six-stage workflow for handling a particular type of customer request may not be. That's the bit worth examining. The more specific something is to how the business creates value, the more interesting custom software becomes.

Build where the workaround has become expensive

Another signal: Look for processes where employees have built a mini software system out of: spreadsheets,

emails, documents, manual copying,

shared folders, and memory. Calculate what that workaround costs.

Not just in hours. Also: mistakes,

delays, lost information, poor customer experience,

dependency on individuals, and inability to scale. The business may already be paying for custom software.

It's just paying for it in human labour.

Build where a new capability creates revenue

Cost saving isn't the only reason. Perhaps custom software allows you to offer: a customer portal,

personalised reports, a self-service tool, a new digital product,

a faster service, or something competitors can't easily provide. Now the build-vs-buy calculation includes revenue.

This is where AI-assisted development can be particularly interesting for smaller companies. It lowers the cost of testing ideas that previously might have been too speculative.

But don't build because AI made the demo easy

This is important. A founder describes something. AI generates an interface.

It works. Everyone gets excited. Then the prototype quietly becomes production software.

Six months later it contains: real customer data, payments,

business-critical workflows, hundreds of users, and nobody is quite sure how half of it works.

The ease of building the first 80% can make the final 20% easy to underestimate. Production standards still matter.

Ask who owns it after launch

Before building custom software, ask: Who maintains it? Who understands it?

Who responds when it breaks? Who reviews dependencies? Who handles security updates?

Who manages access? Who monitors it? Who decides what gets changed?

AI can help with much of that work too. But "the AI will maintain it" isn't an ownership model. Somebody remains responsible for the system.

Documentation becomes more important, not less

If AI allows a small technical team to build much more software, there's a risk that businesses accumulate systems faster than they accumulate understanding. Document: what the system does,

why it exists, where the data lives, which external services it depends on,

how access works, how it's deployed, what happens when something fails,

and how to recover it. The faster you build, the more important this becomes.

Don't underestimate integration with the real business

A custom application rarely exists alone. It needs to interact with: customers,

staff, data, existing systems,

email, payments, files,

analytics, and business processes. The difficult part is often not creating the interface.

It's fitting the software into reality. That's why understanding the business process matters as much as understanding the technology.

AI changes who can justify custom software

This may be the biggest shift. Custom software used to be disproportionately available to organisations with large budgets. Smaller businesses adapted themselves around the products they could afford.

As the cost of software creation falls, more businesses can potentially say: Our process is unusual. Let's build something around it. That doesn't mean every small company becomes a software company.

It means software can become more tailored to the business rather than the business always being tailored to the software.

It changes agency work too

For years, a client might come to a web or software company with an idea and the first question would effectively be: Can we afford to build this? AI changes how quickly we can explore that question.

More ideas can reach prototype. More integrations become practical. More internal tools become viable.

More bespoke functionality can fit within smaller budgets. But that puts more weight on another question: Is this actually worth building?

When execution gets cheaper, judgement becomes more valuable.

This is where experience matters

I've spent around 15 years working in web and digital, and AI has changed how much I can personally build. Not because everything I knew before stopped mattering. The opposite.

The faster the execution becomes, the more useful it is to understand: how websites work, how systems connect,

how users behave, how data moves, how businesses operate,

and where things usually go wrong. AI gives you more building capacity. Experience helps you decide where to point it.

Small businesses can test before they commit

This is perhaps the practical takeaway I'd emphasise most. You don't always need to make a giant build-vs-buy decision at the beginning. Prototype the missing capability.

Test it against the real process. Use real examples where appropriate. See where it fails.

Calculate what it would replace. Compare the cost with existing products. Then decide.

AI has made learning by building much cheaper. Use that advantage.

A build-vs-buy test for 2026

If I were looking at a software requirement for a small business, I'd ask: DOES A GOOD PRODUCT ALREADY EXIST? If yes, start there.

IS THIS A STANDARD BUSINESS FUNCTION? The more standard it is, the stronger the argument for buying. HOW MUCH OF THE PRODUCT WOULD WE ACTUALLY USE?

Don't buy a factory because you need a screwdriver. IS THE REQUIREMENT SPECIFIC TO HOW WE WORK? The more specific it is, the more interesting custom development becomes.

COULD WE CONNECT EXISTING SYSTEMS INSTEAD? You may not need another platform at all. WHAT DOES THE CURRENT WORKAROUND COST?

Include time, mistakes, delays and capacity. DOES THIS CREATE A NEW CAPABILITY OR REVENUE? Not every build needs to be a cost-saving exercise.

WHAT HAPPENS AFTER LAUNCH? Maintenance and ownership belong in the calculation. WHAT HAPPENS IF THE VENDOR CHANGES?

For bought software, consider dependency too. CAN WE TEST IT CHEAPLY FIRST? Increasingly, the answer may be yes.

Don't ask "Could AI build this?"

It probably can help build at least some of it. That's no longer the interesting question. Ask:

Should this exist? Should we own it? Should we buy it?

Should we connect what we already have? What will it cost over time? What business problem does it solve?

That's the build-vs-buy decision.

AI hasn't killed SaaS

Far from it. Great software products will remain enormously valuable. Businesses don't want to maintain everything themselves.

Nor should they. But I do think the boundary is moving. Some software that was previously too expensive to justify building is becoming viable.

Some integrations that were permanently sitting on a wish list can now be considered. Some awkward internal processes can finally have software built around them. Some new digital products can be tested by very small teams.

And some businesses will discover that they don't need another enormous platform. They need a small piece of software that fits the gap between the things they already have.

The calculation has changed

For years, "buy rather than build" was a very sensible default for small businesses. It still is in many situations. But defaults are worth revisiting when the economics change.

AI is reducing parts of the cost of software creation. That makes custom development viable further down the list of business problems. Not everywhere.

Not automatically. And not without responsibility for what you build. But enough to make one question worth asking again:

Are we adapting our business to the software because that's genuinely the best way to work, or because building something better used to be too expensive? The answer may still be "buy". It may be "configure".

It may be "connect". Increasingly, it may be "build". The important thing is that small businesses now have more of a choice.

Where to go next

• AI is changing how much one technical person can build Why AI is increasing the execution capacity of experienced technical people and smaller teams.
• What happens to software development when AI writes most of the code? Code generation is getting easier. Deciding what deserves to become production software isn't.
• Don't start with AI. Start with the work. Don't build software simply because AI made building easier. Start with the business problem.
• AI vs automation: what's the difference, and when do you need each? Sometimes you don't need a new application at all. You need a better connection between the systems you already have.

Related: AI is changing how much one technical person can build.