Starbucks is reportedly building its own alternatives to software it currently buys from Microsoft and IBM.
That sounds like a “SaaS is dead” story. It isn’t.
According to reporting based on an internal Starbucks presentation, the company is developing a replacement for a Microsoft inventory system and an IBM maintenance-management tool. Starbucks has also spent several years building a point-of-sale system that could replace Oracle Simphony. Some of the new software may not reach stores until the end of 2027, and only if it passes testing.
Starbucks is reviewing every technology contract and service, but it continues to use third-party software, including Microsoft products. This is a selective build strategy, not an attempt to eliminate commercial software. The original report is quite explicit about that distinction.
The interesting part of the story is not that Starbucks has discovered custom software.
The interesting part is that AI-assisted development has changed where Starbucks draws the line between what it buys and what it builds.
Starbucks operates at a different scale
Starbucks reportedly spends about $400 million a year on software. At that level, even a modest reduction in licensing or professional-services costs can finance a substantial internal technology team.
It also operates 40,990 stores across company-operated and licensed locations, according to its latest fiscal-year reporting. A system that improves inventory accuracy, equipment uptime, order flow, or labor planning can create value across tens of thousands of locations. Starbucks FY2025 results
That changes the economics.
A typical company might buy maintenance software because the cost of building, securing, operating, and supporting its own system would exceed the subscription. Starbucks can spread those development costs across a huge operating footprint.
Its workflows are also unusually specific. Starbucks is not maintaining generic office equipment. It is coordinating espresso machines, refrigeration, store inventory, mobile orders, drive-through demand, delivery orders, staffing, recipes, and supply-chain replenishment across a global retail network.
At some point, heavily adapting general-purpose software becomes more expensive than owning the application.
Starbucks has the resources to test that point. It can hire software engineers, product managers, infrastructure teams, security specialists, data engineers, support teams, and site-reliability engineers. It can build an internal product organization around software that most companies should simply buy.
That doesn’t make Starbucks the new blueprint for every enterprise.
It makes Starbucks an example from one end of a continuum.
Vibe coding changes the first cost, not the total cost
Vibe coding has made software dramatically cheaper to start.
A small team can now move from idea to working application in days. AI can help generate interfaces, write integration code, create tests, document systems, find bugs, and accelerate routine engineering work.
That matters. It changes which ideas are economically testable.
But the cost of writing the first version was never the full cost of enterprise software.
Production software has to be secured, monitored, supported, documented, upgraded, tested, audited, and maintained. It needs identity management, access controls, backups, incident response, data retention, deployment pipelines, observability, and a team that knows what to do when it fails on a Sunday morning.
Vibe coding lowers the cost of creation. It does not eliminate the cost of ownership.
It may even increase that cost if companies create dozens of applications without clear owners, shared architecture, documentation, or retirement plans.
The question is not whether AI can generate the software.
The question is whether the organization can operate it.
Starbucks has already seen the other side of the experiment
There is a useful warning inside the Starbucks story.
In May, Starbucks retired a separate AI inventory-counting program only nine months after deploying it across North America. The tool, developed with NomadGo, used cameras and LiDAR to count milk, syrups, and other items. Workers reported miscounts, mislabeled products, and an experience that sometimes took longer than entering the inventory manually. Reuters reporting
That system was not the new in-house replacement described in the July report. It was a different product and a different approach.
But it demonstrates the same TCO lesson.
The cost of a failed inventory system is not limited to the invoice. It includes employee time, bad data, unavailable products, retraining, store disruption, manual reconciliation, support, and the cost of returning to the previous process.
Buying did not remove those risks.
Building will not remove them either.
Real TCO is the cost of the entire operating model.
Build versus buy is no longer a binary choice
Enterprise software decisions now sit on a continuum:
- Buy the application and use its native interface.
- Buy the application and configure its workflows.
- Buy the governed system but build a better interface around it.
- Combine several systems inside a customer-owned application or agent.
- Replace a commercial application while continuing to buy cloud infrastructure, identity, databases, observability, and other services.
- Build and operate most of the system internally.
Starbucks is moving selected operational systems toward the fifth position.
Most enterprises should spend more time in the middle.
This is where BYO-UI becomes useful.
A company may still need its CRM, CDP, marketing automation platform, analytics platform, consent system, or digital asset manager. Those systems maintain data models, permissions, integrations, histories, and domain logic that are expensive to reproduce.
What the company may no longer need is for every employee to work through the interface the vendor designed.
The marketing team can keep the governed customer data platform and build a better audience-review workspace.
The revenue team can keep the CRM and create an account-priority application around its own process.
The CMO can receive a board-ready narrative assembled from CRM, campaign, finance, and analytics systems without forcing an analyst to export and reconcile five dashboards.
The systems remain. The experience changes.
That is a different TCO calculation from replacing the underlying platform.
MarTech leaders need to decide which layer they are buying
MarTech has traditionally bundled several decisions together.
When a company bought a marketing platform, it bought the data model, workflows, integrations, administration, and interface as one package.
Vibe coding makes those layers separable.
A MarTech buyer can now ask:
- Does this system own important data, permissions, consent, or operational history?
- Are we unhappy with the underlying capability or merely with the interface?
- Can the platform expose what we need through APIs, events, queries, SDKs, or MCP?
- Is this workflow distinctive enough to justify owning it?
- How much customization are we already paying for?
- Can we support the custom application after the original team moves on?
- What happens when an API changes, a model is replaced, or a security incident occurs?
- Are we reducing TCO or moving costs from software licenses into engineering and operations?
These questions produce different answers for different systems.
A consent-management platform carries regulatory logic that few marketing teams should casually recreate.
A custom campaign exception queue built over that platform may be completely reasonable.
A global retailer may justify owning its point-of-sale application.
A regional business may be better served by buying one and concentrating its development resources on the customer experience that differentiates it.
Buy what is expensive to get wrong
The Starbucks news is important because it shows that the build line is moving.
AI-assisted development makes custom software viable in more places. Companies with large software budgets, specialized operations, and strong technical organizations will move further toward ownership. SaaS vendors will face more pressure when customers pay large subscriptions for applications they already have to reshape around their business.
But this is not the end of SaaS.
Even Starbucks is not walking away from every external platform. Its current technology strategy includes custom internal tools, commercial software, outside providers, and new customer interfaces such as its beta Starbucks app in ChatGPT. Starbucks’ own description of its AI strategy
The future is not build or buy.
It is deciding what to buy, what to build, and where the boundary belongs.
Vibe coding expands the available choices. BYO-UI makes the middle of the continuum more practical. TCO determines whether the result survives after the demo.
Buy what is expensive to get wrong.
Build what is valuable to make your own.