For most of software history, companies had to make a basic choice.
Buy software off the shelf, or build something yourself.
In practice, that decision was often less open than it sounded.
Building custom software used to be such a labor-intensive, slow, and expensive investment that many companies barely treated it as a real option. Unless the workflow was strategically critical, unusually large, or impossible to support with standard software, the default answer was usually to buy.
Buying usually meant faster setup, lower upfront risk, and fewer engineering decisions. Building usually meant more flexibility, but also more cost, more maintenance, and more ways to get things wrong.
AI changes that equation.
It is now much easier for a company to build narrow internal software for its own use. A team can create a workflow tool, a quoting assistant, a reporting layer, a meeting-prep tool, a document pipeline, or a lightweight operations dashboard much faster than before. That software does not need a pricing page, a sales motion, a customer success team, or a polished market narrative. It only needs to work for the internal team using it.
That is a real shift. It lowers the threshold for custom internal tooling so dramatically that building is no longer a rare edge-case decision. In some teams, it will now be the first instinct. That is exactly why the old buy-versus-build debate needs to be revisited.
But the easy part is not the important part.
The hard part is still knowing what to build, how to structure it, where it should connect, how much control it needs, and who is responsible when it starts to break.
AI makes custom tooling cheap. It does not make it good.
The new temptation is obvious.
If a team can generate a workable internal app in a day, why keep bending the business around generic software that only partly fits? Why live with awkward CRM workflows, clumsy reporting exports, scattered meeting notes, or repetitive manual handoffs if a custom tool can close the gap?
In many cases, that instinct is right.
There are plenty of workflows where buying a large platform is excessive and waiting for a vendor roadmap makes little sense. A small custom tool can be the right answer when the workflow is specific, repeated, and closely tied to how the business actually operates.
The problem is that AI makes software generation feel like software completion.
A team gets a working interface. The core prompt behaves well enough in a demo. A few integrations are wired together. The result feels useful, so the organization quietly starts depending on it.
That is where the trouble starts.
The tool may still have weak permissions. The edge cases may not be handled. The workflow may rely on one person who understands the prompts. Logging may be thin. Failure modes may be invisible. The data model may have no sensible route to version two. The tool may solve one pain while creating three new maintenance obligations around it.
Cheap production is not the same thing as good engineering.
This is the same judgment problem we described in Everybody is a developer now. What happens next? . AI lowers the cost of generating software artifacts. It does not automatically improve architecture, operational discipline, or ownership.
The real risk is internal tool sprawl
The obvious fear used to be that companies would build too little because custom software was expensive.
The new fear should be that companies build too much because custom software feels almost free.
One team builds a lead-routing helper. Another builds a customer-summary assistant. Someone in operations builds a scheduling layer. Marketing builds a content workflow. Finance experiments with invoice extraction. Soon the company has a growing stack of internal tools, small automations, prompts, connectors, and that nobody sees as one system.
Each tool may be useful on its own.
Together, they can become a mess.
The organization ends up with half-documented workflows, unclear ownership, duplicated logic, inconsistent permissions, scattered data handling, and tools that work just well enough to keep running while quietly becoming operational dependencies.
That is the turbocharged version of the old problem.
AI lets a team dig a much deeper hole much faster. It can create internal tooling leverage, but it can also create a whole estate of half-working software that nobody fully owns and everybody is nervous to touch.
This is one reason we keep pushing AI workflows and closed-loop systems . If internal tooling is going to multiply, it needs structure, reviewability, and controlled feedback loops around it.
Internal tools still need product thinking
A common mistake is to treat internal software as if it does not need proper product thinking because it is “just for us.”
That is backwards.
Internal software usually sits closer to the actual operations of the business than public-facing software does. It touches approvals, records, documents, scheduling, customer handling, reporting, and recurring execution. If an internal tool is confusing, unreliable, or badly permissioned, the damage lands directly inside the company.
The fact that it is not sold externally does not make it low stakes.
Good internal tools still need:
- a clear workflow owner
- a defined job to be done
- clear inputs and outputs
- human approvals where risk exists
- sensible permissions
- support and maintenance responsibility
- a plan for edge cases, logging, and failure
Without those basics, the company is not building capability. It is building fresh operational debt.
The buy-versus-build question has changed shape
The old version of the question was mostly about software economics.
Is it worth paying engineers to build something custom when a vendor product already exists?
The new version is more operational.
Is this workflow important enough, specific enough, and stable enough to justify internal ownership?
That leads to a more useful split.
Build when the workflow is close to your real operating advantage, crosses too many awkward tool boundaries, or needs a very specific combination of automation, judgment, and internal context.
Buy when the workflow is commodity infrastructure, heavily standardized, or better handled by a mature product with established support, compliance, and maintenance.
Many companies will do both at once. They will buy the large system of record and build narrow layers around it. They will keep core platforms for CRM, accounting, documents, or support, but add internal AI tooling where the business needs better orchestration, better retrieval, faster drafts, or cleaner operational follow-through.
That hybrid model is likely to become normal.
The mistake is not building. The mistake is building without a model for ownership.
Someone still has to support what gets built
This may be the least glamorous part of the whole conversation, but it matters the most.
Every internal tool becomes someone else’s future problem if no owner is named.
Prompts drift. APIs change. business rules evolve. Teams change. Data sources get renamed. A workflow that seemed obvious in April stops making sense in October. A tool that saved time for one quarter becomes confusing six months later because nobody maintained the assumptions it was built on.
That means the AI era may create a more common internal role that many smaller teams have not had before.
Not necessarily a full software department. Not necessarily a classic IT role. But a practical internal tooling owner, or a small tooling function, responsible for keeping the organization’s custom software, automations, and agentic workflows usable over time.
Large enterprises already have internal platform teams, workflow teams, and tooling specialists. Smaller companies may increasingly need lighter versions of the same idea.
If custom software becomes cheap enough, support responsibility becomes the real scarcity.
Guardrails matter more, not less
This is where AI has created a strange illusion.
Because building is easier, some teams assume less discipline is needed.
The opposite is true.
If a team can spin up internal tools quickly, it needs stronger guardrails around what gets built, what data can be touched, which workflows need approval, who can ship changes, and how failures are surfaced. Faster production raises the value of governance because the volume of possible mistakes goes up with it.
That does not require heavy bureaucracy. It does require operating standards.
Before a team builds ten internal AI tools, it should have a view on questions like:
- Which workflows are safe to automate?
- Which ones need human approval?
- Which tools can touch customer or employee data?
- Where should logs and outputs live?
- Who reviews a workflow before it becomes a dependency?
- Who fixes it when it breaks?
This is exactly where a Company-Wide Agentic Workflow , tighter agentic coding workflows , or a stronger security review can be more useful than another shiny AI demo. The hard part is not finding one more way to generate software. The hard part is creating an environment where useful tools stay useful.
What this may lead to
The positive version is clear.
Smaller companies can finally justify custom internal tooling that used to be out of reach. Teams can remove repetitive manual work, support better decisions, and create software that fits the way they actually operate instead of forcing themselves into generic workflows.
The negative version is also clear.
Some companies will fill themselves with brittle internal apps, disconnected agentic workflows, and under-supported tools that nobody wants to own.
So the question is no longer only whether you should buy software or build it yourself.
The better question is whether your team can build internal tools with enough judgment, structure, and support discipline to keep them from turning into a second layer of operational chaos.
AI has made custom internal software dramatically easier to produce. It has not made it self-maintaining, self-governing, or self-justifying.
That is why the next serious advantage will not come from building the most internal tools. It will come from building the right ones, with clear ownership, good controls, and a plan to support them after the first demo.
If your team could build almost any internal tool this year, which ones should still be bought, which ones should be built, and who should own the software you create for yourselves?