AI is changing the economic boundary between the software an organization should buy and the software it should own.
Joan Westenberg makes a strong case for managed software in “The bread paradox: why convenience always wins, and why SaaS isn’t doomed”. Cheap code does not remove the work of security, support, maintenance, integration, compliance, and accountability. A company can generate an application quickly and still end up owning a fragile operational problem.
The warning is sound. The bread analogy draws the decision boundary too narrowly.
Bread is a standardized product for most buyers. Software that runs a business often carries the company’s decision rules, customer workflows, scheduling priorities, and quality controls. It can also carry pricing logic, production constraints, and ways of handling exceptions. When software holds those things, the organization is deciding who will shape its operating model and how quickly that model can change.
The practical question is larger than whether a company can recreate Jira or Notion with an AI coding tool. Leaders now have to decide which capabilities are generic enough to buy, which can be configured or composed from existing services, and which are important enough to own.
The Bread Analogy Works for Commodity Software
Companies should keep buying a large amount of software.
Standardized capabilities benefit from shared scale. Payroll, identity management, commodity email delivery, file storage, and basic accounting are common examples. A provider can spread engineering, infrastructure, compliance, security, and support costs across many customers. Most organizations gain little by recreating those capabilities themselves.
The value of the subscription comes from dependable execution. The provider keeps the service running, responds to security issues, and maintains integrations. It supports users and accepts responsibility for a defined part of the operation. The customer pays to direct its attention elsewhere.
Westenberg is right that lower coding costs do not erase that value. Organizations still need reliable systems, accountable owners, and people who understand what happens after the first version ships.
The analogy weakens when the software carries a distinctive business process. A generalized product may force the company to work the way the vendor designed. Employees then fill the gaps with spreadsheets, duplicate data entry, and manual reconciliation. Disconnected approvals and permanent workarounds become part of daily operations.
At that point, convenience has a cost too.
Opportunity Cost Runs in Both Directions
The make-or-buy calculation usually puts internal development time on one side and the subscription price on the other. A serious comparison also has to count the cost of leaving the workflow as it is.
That cost can show up as slower decisions, repeated handoffs, process errors, and delayed customer response. It can also limit production capacity and leave the organization dependent on a vendor’s product roadmap. People may spend years operating around software that never fit the work particularly well.
Leaders should compare four real options:
- Buy a standard product.
- Configure or extend an existing platform.
- Compose a solution from managed services, application programming interfaces (APIs), and open-source components.
- Build and govern a custom application.
Each option has a different cost, risk, and ownership model. The right choice depends on the economic value of the workflow, the degree of differentiation it creates, and the organization’s ability to support what it owns.
The return calculation needs both sides. Total cost includes design, implementation, hosting, testing, and security. It also includes documentation, training, maintenance, operational ownership, and future migration. Economic benefit can include less repetitive work, additional throughput, fewer errors, and faster revenue. It can also include lower risk, stronger customer retention, and institutional knowledge captured in a system people can inspect and improve.
Westenberg’s argument gives appropriate weight to total cost of ownership. I think it gives too little weight to the value an organization may create by designing software around its own way of working.
AI Changes the Cost Curve
AI reduces more than the time required to type code.
A capable team can use agents to help analyze requirements, explore architecture, generate tests, and refactor code. Agents can also help document decisions, build integrations, troubleshoot failures, and prepare migration work. The people still have to direct and verify that work. Their capacity can increase across much more of the development lifecycle.
That changes which projects are economically possible. Software that once required a large team and a long implementation may become manageable for a smaller group with strong domain knowledge, engineering judgment, and a disciplined delivery system.
The organization still pays for ownership. AI changes the shape and level of that cost. A make-or-buy decision based on the staffing and delivery assumptions of the last software era will miss projects that have moved from impractical to attractive.
This is why I see the bread machine as the wrong unit of analysis. AI is starting to change the economics of operating a small bakery. The organization can combine managed infrastructure, open-source components, SaaS APIs, and agent-assisted engineering into a system designed for its own work.
Vibe Coding and Agentic Engineering Carry Different Risks
Westenberg’s warning describes a real failure mode. Someone prompts an application into existence, checks the visible behavior, and puts it into operation. Requirements live in a chat history. Architecture decisions go unrecorded. Tests cover the happy path. The original builder becomes the only person who understands the system.
That application can become an expensive liability even when its first version was nearly free.
Disciplined agentic engineering uses AI inside an engineering system. The team defines the problem, models the domain, and records architecture decisions. It protects security and data boundaries, writes testable acceptance criteria, and reviews changes. The same team controls deployment, monitors production, and assigns lifecycle ownership.
The agents add execution capacity. People retain responsibility for direction, judgment, review, and consequences.
I have written before that agents still need engineering discipline. That discipline matters directly to the SaaS decision. The relevant comparison puts a managed product beside a governed internal product capability. That internal capability uses people, agents, platforms, open-source software, and managed services together.
The quality of the internal engineering system determines whether ownership creates an advantage or another fragile dependency.
Mature Software Carries Intelligence and Burden
Westenberg also points to the institutional knowledge inside mature codebases. That knowledge can be a deep source of value. Years of domain logic, edge cases, integrations, and operating experience are difficult to reproduce.
Age and complexity can also preserve obsolete assumptions, old dependencies, and former customer requirements. They can preserve technical debt and product decisions made for an earlier technology environment.
Leaders need to distinguish accumulated domain intelligence from accumulated implementation burden. The first can create a durable advantage. The second can slow adaptation and make every change more expensive.
AI gives new entrants and internal teams better tools for studying existing workflows, extracting the domain rules that still matter, and implementing those rules in a cleaner system. That work still requires expertise and validation. Its cost is falling.
The same pressure applies to integration ecosystems. Proprietary connectors and high switching costs have protected many SaaS products. Agents can already help interpret schemas, transform data, and generate integration code. They can also reconcile records and operate across several systems. These capabilities can reduce the value of owning a large collection of rigid, point-to-point connectors while leaving the integration risk in place.
SaaS Will Be Unbundled
I share Westenberg’s conclusion that managed software will remain valuable. I expect the traditional SaaS bundle to come under much more pressure.
A SaaS subscription often combines the user interface, workflow, data model, automation, and reporting. It may also combine integrations, hosting, support, security, and maintenance. AI makes it easier to separate those layers.
An agent can become part of the interface. The company can own the workflow and business rules. A managed database can hold the data. APIs can supply commodity capabilities. A small internal team can govern the application while external providers supply infrastructure and specialized controls.
The customer may no longer need one vendor to own the entire stack.
Durable providers will earn their place through operational responsibility, trusted data, regulatory standing, and deep domain models. Transactional infrastructure, reliable APIs, and accountability for outcomes will also matter. Products built around a thin interface, a basic transformation, a generic dashboard, or one narrow automation will face stronger pressure.
The middle of the market will feel it too. Vendors whose products require customers to reshape important work around a generalized model will have to prove that their convenience still outweighs the cost of compromise.
Own the Design of the Production System
Industrial equipment gives me a more useful analogy for this shift.
A manufacturer buys standard motors, sensors, controllers, and machines when the production need is common. It commissions or builds specialized equipment when the process itself creates an advantage. The company assembles proven components into a production system designed around its own constraints.
Software organizations can make the same choice. Cloud services provide infrastructure. Open-source libraries provide standard components. SaaS APIs provide purchased subsystems. AI agents add engineering capacity. Specifications describe the intended system. Tests and review gates provide acceptance controls. People own the architecture, process, and economic outcome.
Organizations do not need to own every layer. They need enough control over the business rules, data, workflow design, integration logic, and change velocity that shape their advantage.
The future will include a great deal of SaaS. It will also include more organizations that develop an internal product capability and make deliberate choices about the complexity they are prepared to own.
AI makes that choice available in places where it was previously too expensive. The leaders who understand their workflows, measure the full opportunity cost, and govern software as a long-lived product will be able to use it.