Think about this for a second. A company that sells lattes announced it was going to write some of its own software, and shares of IBM, Microsoft, ServiceNow and other software companies fell before most people finished their morning commute.

Nobody lost a contract that day. ServiceNow and Salesforce were not even named in the original report. Starbucks said it was building AI-assisted replacements for a Microsoft inventory system and an IBM maintenance platform as part of a broader review of its roughly $400 million annual software bill. It has also reportedly spent several years developing a point-of-sale system that could replace Oracle Simphony.

So why did the whole application layer flinch?

The market did not merely sell software stocks. It sold a story. For roughly 20 years, enterprise software valuations have rested on one very durable assumption: Large companies will continue to buy software because building it themselves is too slow, too expensive and too risky. You paid for a platform that fit perhaps 70% of how your company worked, then paid consultants to hammer the other 30% into place. Everybody knew the deal. Nobody necessarily loved it, but the alternative—writing and maintaining the application yourself—was often unthinkable.

AI-assisted development just made it thinkable. That is enough to make investors nervous.

For Much of SaaS, the Moat Was Never the Code

Let’s be honest about what a large part of the enterprise software industry has been selling all these years. It was not only the software. It was the fact that most customers could not afford to reproduce it.

The moat was the cost of engineers, the years of development, the integration work and the maintenance burden nobody wanted. SaaS packaged those costs into a predictable subscription and promised that someone else would keep the machinery running.

AI is collapsing enough of that cost to change the calculation. It does not make custom software free, despite what some people selling AI coding tools would like you to believe. But it may make building a narrowly defined internal application economical where it was not economical before.

Suddenly, every per-seat license renewal competes against a new proposal: My own engineers, purpose-built for our business, delivered next quarter.

“Building,” however, does not mean starting with an empty screen and writing every line from scratch. The modern enterprise will assemble cloud services, open source components, commercial APIs and its own proprietary data, with AI generating more of the connective tissue. That combination can produce an application designed around the company’s actual operations rather than a generalized product retrofitted to approximate them.

Starbucks knows its stores, equipment, inventory patterns, employees and customer behavior better than Microsoft, IBM or Oracle ever could. If it can encode that knowledge into its own applications at a reasonable cost, the result could fit Starbucks better than a commercial platform requiring years of customization.

Not every software vendor should be sweating equally. If your product is essentially forms, a database, workflow rules and permissions—and a surprising amount of enterprise software can be reduced to some variation of that—you are exposed. If you possess genuine network effects, a regulatory moat, a deeply embedded ecosystem or domain knowledge accumulated over decades, you have more room to breathe.

Microsoft also illustrates why occupying several layers of the stack matters. Its shares participated in the immediate selloff, but Microsoft can lose an application workload and still win the cloud, model and development-tool spending underneath it. Starbucks’ Green Dot Assist, for example, was built using AI capabilities on Microsoft Azure. Starbucks can replace one Microsoft application while continuing to pay Microsoft elsewhere.

AI does not kill enterprise software. It moves the value. Some of it moves down into cloud infrastructure, models and development platforms. Some moves up into proprietary workflows, data and the customer relationship. The generalized application caught between those layers gets squeezed.

Now for the Cold Water

I have been around long enough to have seen versions of this movie before, and I know how the second act usually goes.

Every build-versus-buy cycle runs on the same fuel: underestimating the boring part. In the old days, companies underestimated what it cost to build. In this new era, they are going to underestimate what it costs to maintain.

AI can write code quickly. It does not automatically attend the 2 a.m. incident call. It does not assume ownership of the application three years from now when the engineer who built it has left and nobody remembers why the inventory logic works the way it does. It does not eliminate testing, integration, security, governance, documentation or technical debt. It merely allows organizations to produce all of them faster if they are not careful.

Starbucks has already given us a preview. Earlier this year, the company abandoned an AI-powered inventory-counting system after it produced unreliable results and returned stores to manual counting. That failure may have taught Starbucks something important about where automation breaks down in actual stores. It is also a reminder that a convincing demonstration is not the same thing as dependable software operating across thousands of locations.

The first wave of AI-assisted internal development will almost certainly leave behind a graveyard of half-maintained tools. Somewhere around 2028, we will begin reading the “why we went back to buying” post-mortems. Book it.

Nor should we be naive about the timing of the Starbucks announcement. It arrived amid a reported $2 billion cost-reduction effort and a review of every technology contract and service the company buys. Some of this is genuine strategy. Some may be a negotiating stick Starbucks can wave at vendors during renewal season. Telling a software supplier that you are prepared to replace its product is a remarkably effective way to reopen the pricing discussion.

Starbucks is not leaving Microsoft. It is building parts of its new operation on Microsoft’s cloud. Both things can be true.

The Part Nobody is Talking About: Open Source

There is another consequence buried beneath this new build-it-yourself economics.

Nobody builds from scratch. When Starbucks—or any large enterprise pursuing this strategy—says it is building its own software, its engineers are likely assembling a stack from databases, event-streaming technology, workflow engines, frameworks, libraries, cloud services and internal data. Much of that foundation will be open source.

Open source could become the raw material of the build-your-own era just as enterprises become less willing to pay for generalized commercial applications. Usage will rise. Whether the contribution rises with it is another question.

AI models learned much of what they know about software development from enormous collections of publicly available code, including open source repositories. AI-generated code can reproduce familiar structures and patterns without creating a pull request, filing a bug report, improving documentation or adding another maintainer upstream.

Consumption accelerates while contribution remains optional.

Commercial open source companies may face pressure from the same economics threatening conventional SaaS. Many of these businesses fund full-time engineering and maintainers by selling managed services, enterprise features and supported distributions. If AI makes deploying, modifying and patching the community version easier, more companies may ask why they should continue paying for the commercial offering.

That sounds efficient until the revenue supporting development begins to disappear.

Dependence on the commons could peak at precisely the moment its funding model weakens. Open source maintainers were already wrestling with burnout, growing security responsibilities and the uncomfortable reality that critical infrastructure is sometimes maintained by one or two people in their spare time. Now imagine every Fortune 500 company becoming a more capable consumer and assembler of open source software without becoming a more responsible participant in the communities maintaining it.

The developers and operators reading this already know where the bodies are buried. They are the ones who will inherit these internal applications when the excitement fades, the consultants move on and senior management discovers that “we built it” also means “we own every problem it develops.” They are also the ones who know that the critical library holding up a new internal platform may be maintained by two exhausted volunteers whose names nobody in procurement knows.

The Starbucks story is not simply that AI can write software more cheaply. It is that owning more of your operations may once again be possible for enterprises willing to do the unglamorous work and honest enough to budget for maintenance long after the launch celebration ends.

The next generation of enterprise software may be cheaper to build, more specialized and more closely owned by the companies that use it. But it will not be created from nothing. Beneath those purpose-built applications will sit cloud infrastructure, AI models and an enormous base of open source software maintained by people whose work remains largely invisible.

AI may make it possible for enterprises to stop renting so much of their software. It does not make the software free. It merely changes who gets the bill—and whether anyone remembers to pay the people holding up the bottom of the stack.