The build vs. buy equation has changed: why companies will build more of their own software

For the last 15 years, one piece of software advice was almost universally correct:

Do not build it if you can buy it.

Need a CRM? Buy one.

Need project management? Buy one.

Need an HR system, reporting platform, ticketing system, knowledge base, scheduling tool, or document workflow?

There is probably a SaaS product for it.

And for good reason. Custom software was expensive, slow to build, difficult to maintain, and usually required a serious engineering team.

But AI is beginning to change the economics behind that decision.

Not because SaaS is going away.

It isn't.

But because the cost of building software is dropping so quickly that companies can suddenly justify building things that would have been completely unreasonable a few years ago.

And we think this changes something much bigger than developer productivity.

It changes what software inside a company can look like.

We saw this happening inside one of our clients

This idea did not start as a theory.

It came from something we saw while working with a client.

The company's CEO is extremely curious about technology. She started experimenting with AI coding tools and building small internal applications around problems she encountered in the business.

These were not startup products.

There was no plan to sell them.

They were simply tools the company needed.

A workflow here.

An internal interface there.

A way to organize information.

A small application solving something unusually specific to how their company operates.

A few years ago, most of these ideas would never have been built.

The business case would not have made sense.

You would need to define requirements, find developers, design an architecture, build the application, test it, deploy it, and maintain it.

For a small internal problem, the answer would usually be:

"Just use Excel."

Or:

"There must be a SaaS for this."

Now the calculation is changing.

And once we noticed it with one client, we started seeing the implication everywhere.

The old software model forced companies to adapt to the tool

Most SaaS products are designed around a reasonable assumption:

Thousands of companies have roughly the same problem.

Build one product that solves 80% of that problem and sell it to all of them.

That model created some of the most successful software companies in the world.

But anyone who has actually implemented software inside a business knows what happens next.

Your process does not quite fit the CRM.

Your approval flow needs three extra steps.

Your team maintains another spreadsheet because the ERP does not contain the field you need.

Someone manually copies information from one system to another.

A manager wants a report that requires exporting three CSV files.

The company develops workarounds around the software.

Soon you have:

SaaS + spreadsheets + WhatsApp + email + manual work + tribal knowledge.

The software works.

But the company has adapted itself to the software.

AI changes the economics of custom software

The important shift is not simply that developers can write code faster.

It is that the amount of effort required to turn a business requirement into working software is falling dramatically.

AI coding tools can already help with architecture, interfaces, APIs, database migrations, tests, documentation, debugging, and deployment.

Automation platforms handle integrations that previously required custom engineering.

AI agents can handle parts of workflows that traditional rule-based software struggled with because the input was unstructured: emails, documents, conversations, images, and human language.

None of this means software suddenly builds itself.

Production systems still need architecture, security, permissions, testing, monitoring, data modeling, and someone who understands the business problem.

But the threshold has changed.

A tool that once needed to save hundreds of thousands of dollars to justify building may now make sense because it saves one team a few hours every week.

That creates an entirely new category of software opportunity inside companies.

The new question is not "Can we build it?"

Increasingly, the answer to that question is yes.

The harder questions are becoming:

What should we build?

What should we automate?

What should we buy?

Where should we use AI?

Which processes should stay human?

How does everything connect to the systems we already have?

That is the part of the AI revolution that we think is underestimated.

As building becomes easier, software development itself becomes less of the bottleneck.

Understanding the organization becomes the bottleneck.

Someone still needs to walk through how the business actually works.

Someone needs to notice that five employees spend Monday mornings combining reports.

Someone needs to understand why the company's normal CRM cannot represent an important part of the sales process.

Someone needs to identify where human judgment creates value and where it is simply repetitive work.

Someone needs to decide whether the correct solution is:

• buying existing software
• configuring an existing platform
• building an automation
• building a small internal application
• introducing an AI agent
• connecting several existing systems
• or doing absolutely nothing

The technical possibilities are expanding.

The difficult part is choosing the right one.

Every company may eventually have its own software layer

This is where we think things get interesting.

Imagine a 50-person company five years from now.

Alongside its major systems, CRM, ERP, accounting, email, project management, it might have dozens of small tools built specifically for the way that company works.

One handles onboarding.

Another prepares information before client meetings.

Another checks documents before they are submitted.

Another reconciles invoices.

Another generates management reports.

Another monitors project profitability.

Another knows the company's procedures and answers employee questions.

Another coordinates a workflow across four different systems.

Each tool may be relatively small.

Together they form something much larger:

the company's own software layer.

You could almost think of it as a private App Store.

Except the applications are not generic products downloaded by thousands of companies.

They exist because this particular company needed them.

SaaS is not disappearing

This distinction matters.

We are not predicting the death of SaaS.

Buying software will still make much more sense in many categories.

Nobody needs to build their own email provider.

Most businesses should not build their own accounting system.

If a mature product solves your problem perfectly for $50 per month, building an alternative would be absurd.

But the old rule was:

Buy unless you absolutely have to build.

The new rule may become:

Buy what is standardized. Build what is specific to how your company creates value.

That is a very different software landscape.

The interesting opportunity is not replacing every SaaS product.

It is filling the enormous space between generic SaaS and traditional expensive custom development.

The internal tools nobody built before

Consider a professional-services company.

There may be no global software market for:

"Before we send this specific type of client report, check these 17 company-specific rules, compare the numbers against two internal databases, verify that the latest documents exist, flag anything unusual, and prepare the final package for an employee to approve."

That problem is too specific to become a successful SaaS company.

But it might be extremely valuable to one business.

Historically, these problems remained manual precisely because they were too specific.

AI makes these problems economically interesting.

And almost every established business has dozens of them.

This also creates a new problem: AI chaos

There is a dangerous version of this future too.

Give everyone AI coding tools and tell them to build whatever they want.

Six months later you may have:

• duplicated applications
• undocumented databases
• exposed credentials
• inconsistent permissions
• abandoned automations
• tools nobody owns
• critical workflows built on one employee's laptop
• five different versions of the same customer data

We are already entering the era of AI-powered shadow IT.

So the future cannot simply be:

Everyone becomes a developer.

Companies need a way to let software creation become decentralized without letting their infrastructure become chaotic.

That means architecture.

Governance.

Shared authentication.

Permissions.

Reusable components.

Monitoring.

Documentation.

Security standards.

Ownership.

And someone responsible for seeing the whole picture.

We think a new type of technology partner will emerge

This is also changing how we think about Automation Flow.

When we started, it was easy to describe what we did as:

AI and automation development.

A client has a process.

We automate it.

A client needs an AI system.

We build it.

That is still part of our work.

But we increasingly think the larger opportunity is different.

Instead of building isolated automations, we can help companies gradually build their internal software and AI layer.

That starts with understanding the organization.

Then continuously deciding:

What should we buy?

What should we automate?

What should we build?

What should AI handle?

What should humans handle?

And how should all of it work together?

Some solutions may take two days.

Some may take three months.

Some may be AI agents.

Others may contain almost no AI at all.

The technology is secondary.

The goal is to continuously remove friction from the organization.

The moat will not be writing code

There is another consequence of this shift that software companies and development agencies need to accept.

If AI continues making development faster, writing code itself becomes less valuable as a differentiator.

The valuable capabilities move upward.

Understanding businesses.

Designing systems.

Making architectural decisions.

Identifying high-ROI opportunities.

Integrating with messy existing infrastructure.

Handling edge cases.

Security.

Adoption.

Knowing when not to use AI.

And translating an ambiguous sentence like:

"This part of our operation is driving us crazy."

into a production system that employees actually use.

AI can generate more and more of the implementation.

But somebody still has to understand what should exist.

That may become the most valuable skill of all.

The companies that learn to build will operate differently

There is a second-order effect here.

Once building software becomes normal inside an organization, the company itself can begin changing faster.

Today, an operational problem may survive for years because fixing it requires buying a new platform, migrating data, getting budget approval, and training the entire organization.

Tomorrow, a team may identify a bottleneck on Monday and have the first internal version of a solution running two weeks later.

That creates a new type of company.

One where processes are not treated as permanent.

When friction appears, the company can redesign the process and build the missing software around it.

Software stops being something the organization occasionally buys.

It becomes a capability the organization continuously uses to improve itself.

We think that is where this is heading.

Frequently asked questions

Will AI replace SaaS?

No. Mature SaaS will continue to be the correct choice for standardized problems. AI mainly changes the economics of solving company-specific problems that previously were too expensive to justify with custom development.

Why build software instead of using existing tools?

You should not build when existing software solves the problem well. Custom software makes sense when the process is strategically important, unusually specific, spans several systems, or requires employees to maintain significant manual work around an existing product.

Can non-technical employees build internal tools with AI?

Increasingly, yes. But there is a large difference between creating a prototype and operating production software. Security, permissions, architecture, monitoring, data integrity, and maintenance still need to be managed.

What is an internal AI and software layer?

It is the collection of custom applications, automations, integrations, agents, and shared infrastructure built specifically around the way one company operates.

Where should a company start?

Not by building ten applications. Start by mapping the organization. Find one recurring process that consumes meaningful time, has a clear business impact, and is painful with the tools you currently have. Then determine whether the right answer is to buy, automate, build, or combine them. Ship one useful solution, learn from it, then build the next one.

---

Your company probably already has the first five apps waiting to be built

They just do not look like software ideas yet.

They look like:

"Every Friday, Maya spends three hours doing this."

"Before we send this, Dan always checks these four things manually."

"Only Roni knows where that information is."

"The CRM cannot really handle this part of our process."

"We export this to Excel because the system cannot do it."

Those sentences are increasingly becoming software requirements.

At Automation Flow, this is what we map with companies: what should stay as it is, what should be automated, what should be bought, and what is finally worth building.

Because the question is no longer only whether your company can build software.

It is what your company should build next.