The wrong question is whether AI will make companies build more software.

The better question is what kind of software becomes worth building when the cost of building drops, who is suddenly able to build it, and what operating model is required so the company does not drown in its own new capability.

That is the builder shift.

For the last twenty years, most companies treated software creation as scarce. If a workflow needed software, the default path was to buy SaaS, wait for IT, submit requirements, hire consultants, or tolerate spreadsheets. Building internally was expensive enough that many bad workflows survived because fixing them was not worth the queue time.

AI changes that math. Not because every employee becomes a great software engineer. Not because SaaS disappears. Not because agents magically replace systems. The shift is narrower and more useful: a much larger group of people can now shape tools, automations, interfaces, reports, and workflow glue close to where the work actually happens.

That changes the bottleneck.

The bottleneck is no longer only code production. It becomes taste, architecture, governance, maintenance, and judgment.

Software abundance creates management problems

Software scarcity had obvious problems. Teams waited too long. Operators built fragile spreadsheet empires. SaaS tools accumulated because every department bought something close enough. Work leaked between systems through exports, uploads, and manual reconciliation.

Software abundance creates a different problem: too many things can be built.

When building gets easier, the company needs better answers to basic questions:

  • What should be built internally?
  • What should remain a vendor product?
  • Who is allowed to build production tools?
  • What risk tier is this workflow in?
  • Who maintains it after the exciting first version?
  • What systems of record does it touch?
  • How will users learn it, trust it, and report issues?
  • When should it be retired?

Without those answers, AI-enabled building becomes shadow IT with better demos.

The builder shift is not anti-SaaS

The lazy take is that AI kills SaaS because companies can build everything themselves.

That is not how serious operators should think.

SaaS exists because many business processes are common, boring, regulated, networked, or operationally heavy. Payroll, accounting, CRM, identity, billing, security monitoring, contract management, data warehouses, and support platforms are not attractive internal reinvention projects for most companies. Vendors still carry product depth, uptime, compliance, integrations, benchmarks, and support burden.

But SaaS was also a compromise. Companies bought generic tools because custom internal software was too expensive. They adapted their workflow to the tool, then filled the gaps with spreadsheets, Zapier chains, manual handoffs, and tribal knowledge.

AI pressures that compromise. The question becomes less "build or buy" and more "buy the durable system, then build the workflow layer that makes it fit how we actually operate."

The first wave is inside the company

The first serious opportunities are not glamorous.

They are the ugly operating seams:

  • spreadsheet-based approval processes;
  • manual account research;
  • copy/paste reporting;
  • exception handling;
  • customer handoff checklists;
  • finance reconciliations;
  • sales territory changes;
  • onboarding workflows;
  • renewal risk reviews;
  • policy interpretation;
  • data cleanup and enrichment.

These are not always worthy of a full product team. They are often too specific for SaaS. They are exactly where operator-builders can create leverage if the company gives them safe tools and clear boundaries.

Internal software still has users

A dangerous mistake is treating internal tools as disposable because the users are employees.

Internal software has users. It has adoption curves. It has trust problems. It has support needs. It changes behavior. It creates dependencies. It can make the business faster or quietly make it more brittle.

The fact that a tool is internal does not exempt it from product thinking. If anything, internal tools require more operational empathy because users cannot simply choose a competitor. They live with the system you give them.

The builder shift therefore needs product discipline, not just automation enthusiasm.

The operating model has to change

A company that wants the upside needs an architecture for building:

  • risk tiers for workflows and data;
  • approved components and APIs;
  • identity, permissions, logging, and audit trails;
  • clear ownership and maintenance expectations;
  • platform support for non-engineer builders;
  • review paths for security, legal, finance, and compliance;
  • standards for documentation and user support;
  • retirement rules for stale tools.

This is not bureaucracy. It is the price of software abundance.

The companies that win will not be the ones that let everyone build anything. They will be the ones that make the right things easy to build and the dangerous things hard to ship casually.

The operator's rule

Do not frame the builder shift as "more software."

Frame it as a new operating capability: the ability to turn local workflow knowledge into safe, maintainable internal systems faster than before.

That capability can remove real drag. It can also create chaos. The difference is not the model. It is the operating architecture around the builders.