For the last twenty years, most companies solved software problems by buying SaaS.
That was usually the sensible choice. Custom software was expensive, slow, and risky. Unless a workflow was strategic enough to justify a full project, the practical answer was to buy the product that came closest and adapt the company around it.
The result was the SaaS model we all know. One product serves thousands of companies. Every customer gets roughly the same interface, data model, workflow logic, and opinion about how the work should be done. There may be custom fields, integrations, settings, and a few personalization options. But the basic deal is simple: your company uses the same product as everybody else.
That tradeoff made sense when software production was the expensive part.
LLMs are changing the tradeoff.
It is now much easier to create software for one company, one team, or one very specific workflow. A useful internal tool no longer needs a venture-backed product team behind it. It does not need a public roadmap, a marketplace listing, or a pricing page. It only needs to solve the problem inside the company that will use it.
That opens a real opportunity for small and mid-sized companies.
The old custom software model was too heavy
Custom software used to mean a large project before the first useful version appeared.
There would be scoping, design, engineering, infrastructure, testing, rollout, support, and the permanent question of who would maintain it. For many companies, the answer was simple: do not build unless there was no alternative.
SaaS won because it removed most of that burden. You paid a subscription, accepted the product’s assumptions, and got moving. Even if the fit was imperfect, it was usually better than paying for a bespoke system from scratch.
Many internal workflows now sit inside tools that are almost right.
The CRM almost fits the sales process. The project tool almost fits the delivery model. The finance template almost fits the costing logic. The reporting dashboard almost answers the actual management question. The team learns the gaps, creates workarounds, and treats the friction as normal.
LLMs make that normality less acceptable.
If a team can now build a narrow tool much faster, the question changes from “Can we afford custom software?” to “Is this workflow specific enough that custom software would be better than another compromise?” We looked at the related buy-versus-build risk in Should We All Now Build Our Own Internal Tools with AI? .
Vibe coding will create many useful tools
There is nothing wrong with people building small tools for themselves.
Vibe coding is useful. A founder can build a small dashboard. An operations lead can create a document helper. A finance person can prototype a pricing calculator. A sales team can create a quick account-research workflow. The threshold for turning a recurring irritation into a working tool has dropped sharply.
Companies should experiment. People who understand the work often know exactly where the friction is. If they can create a first version themselves, they can test whether the idea is useful before anyone turns it into a larger project.
The problem starts when the workflow stops being simple.
A prototype that helps one person with one task is different from a system that handles real company data, carries business logic, supports approvals, produces outputs others rely on, or drives downstream processes. At that point, the work is no longer just “make an app.” It becomes product design, data modelling, software engineering, security, operations, and change management.
That is where many vibe-coded internal tools will hit a wall. It is the same judgment problem behind Everybody is a developer now. What happens next? : producing software artifacts is getting easier, but architecture, security, UX, data, and operational control still matter.
Complex workflows still need professional structure
The most valuable internal tools are rarely simple forms with a nice interface.
They often involve data pipelines, messy inputs, human review, multi-step processes, exceptions, permissions, calculations, and downstream actions. They may need to clean data from several systems, classify records, run analysis, support costing, generate documents, update a CRM, or prepare decisions for a manager.
That kind of work is not easy just because an LLM can write code.
The hard part is knowing what the system should mean.
Which data source is authoritative? Which fields matter? What happens when a value is missing? Which steps can be automated? Where does a human need to approve? How should the tool explain its result? What should be logged? What happens when the API changes? Who owns the workflow after launch?
These questions are not implementation details. They are the product.
A team can vibe code its way through the first visible layer and still be stuck with the harder parts untouched. The interface exists, but the data model is weak. The demo works, but the edge cases fail. The calculation looks right, but nobody knows how to audit it. The first user loves it, but the second team cannot use it without changes. The tool gets close enough to be exciting, then becomes too fragile to trust.
That is the brick wall. The way around it usually looks more like AI workflows and closed-loop systems : structured inputs, reviewable changes, tests, logs, and controlled feedback loops around the work.
The sweet spot is professional custom software built with LLMs
There is a middle way between old custom software and unmanaged internal experiments.
Use LLMs to move fast, but have professionals design and build the tool. This is where AI consulting and implementation becomes more useful than advice alone.
That means a team comes in, learns the workflow, maps the data, identifies the decision points, and builds software around the specific way the company actually works. The tool does not need to serve a market category. It does not need to please every possible buyer. It only needs to fit this company, this process, this data, and this group of users.
That is a much easier target than building generic SaaS. Generic SaaS has to support many customers, edge cases, integration patterns, permission models, onboarding paths, and conflicting opinions about how the work should be done. Custom internal software can be more focused. The users are known. The workflow is known. The business rules can be explicit. The first version can be small, useful, and built around actual operating context.
LLMs make that approach commercially realistic for more companies.
They reduce the cost of implementation, speed up iteration, and make it easier to move from understanding the workflow to a working tool. But they do not remove the need for judgment. The value comes from combining the new speed of LLM-assisted development with product and engineering discipline.
Is this the beginning of the SaaSpocalypse?
For some SaaS companies, yes.
Low-value SaaS is vulnerable. If a product is mostly a thin workflow wrapper, a generic dashboard, or a slightly awkward process tool, customers will increasingly ask whether a custom internal version would fit better.
But SaaS will not disappear.
Strong SaaS products still have advantages. They serve large audiences with shared needs. They absorb regulatory, security, infrastructure, support, and maintenance work. They benefit from network effects, integrations, and product maturity. If a SaaS tool does exactly what a large audience wants, it will keep being useful.
The pressure is higher where SaaS owns the workflow too tightly. That is the problem we described in Agentic De-Siloing: Moving Work Out of SaaS Silos : companies need more control over the data, rules, and operating memory that agents and internal tools depend on.
The bigger change is the arrival of a new category.
Small and mid-sized companies can now commission internal tools that would previously have been too expensive to justify. These tools sit between SaaS and traditional bespoke software. They are custom, but not bloated. They are fast to build, but not casual. They are specific, but still professionally designed and maintained.
That is a glimpse of where software is going.
More tools will be built for specific people, specific teams, specific partner groups, and specific companies. One-size-fits-all software will still exist, but it will no longer be the only realistic option for many company workflows.
Build around the company, not the category
The important question is not whether a company should build everything itself.
It should not.
The question is where the work is specific enough, valuable enough, and awkward enough that a custom tool would create a better than another SaaS compromise.
Good candidates often have a few things in common:
- the workflow is repeated often
- the current tool fit is poor
- the process depends on company-specific knowledge
- the data comes from several places
- the output drives real decisions or downstream work
- the team already has manual workarounds
- the value of a better fit is easy to explain
Those are the workflows where custom internal software can create leverage.
At XYZ, this is exactly the kind of work we are interested in. We are already working on active cases where LLM-assisted development makes it possible to move quickly, while still treating the data, workflow, and support model seriously.
If your company has a specific internal workflow that never quite fits standard software, get in touch or book a meeting . We can help you work out whether a custom tool makes sense, what the first version should do, and how to build it without turning a useful idea into unsupported internal software.