.svg)
.jpg)
By Jason Talley, Managing Director, Launch Consulting Group
The build vs buy software question has come into sharp focus after a recent report on Starbucks' plan to build its own inventory and maintenance software in-house, rather than continuing to license it from vendors like Microsoft and IBM. The move has been framed as a story about a $400 million line item. It isn't. The number is the headline, but it's not the point.
The real story is about who owns the opinion of how your business runs.
Every piece of enterprise software a company buys carries assumptions with it: how inventory should be counted, how maintenance should be scheduled, how a workflow is supposed to move from one desk to the next. Adopt the system, and you adopt its opinion.
When that opinion doesn't match how your business actually operates, there have historically been only two options: bend the business to fit the software, or spend heavily to customize the software to fit the business.
Neither has ever been a satisfying answer.
For the first time, AI-assisted software development makes a third option affordable: build a simpler custom system that reflects your own way of working. That's what's actually happening here. Starbucks isn't only trying to spend less. It's trying to reclaim ownership of its own process.
It's tempting to read this as proof that AI has rewritten the economics of build versus buy across the board.
It hasn't — not entirely.
What AI has changed is the starting cost. For decades, the math was simple: building software in-house was so slow and expensive that buying almost always won. AI has collapsed the cost of writing code, and that genuinely shifts the build-vs-buy calculus for a lot of internal tools. A custom inventory management system that once took years to build can now be stood up in weeks.
That speed is real, but it's only as good as the discipline wrapped around it. The fastest AI-assisted development cycles I've seen still put an experienced engineer in the loop at both ends: someone setting clear intent before the system generates anything, and someone verifying what comes out the other side before it ships. Skip that discipline and a faster development cycle just means accumulating technical debt faster.
What AI hasn't touched is what happens after launch. Ownership is forever. Security patches, compliance updates, edge cases, and the person who knows what to do when the system breaks at 2AM. All that responsibility transfers the moment you stop paying a vendor and start running your own code.
The systems most exposed to this shift are what might be called the commodity middle: internal tools that encode a company's own quirks, don't touch regulated data, and where the vendor's product has drifted away from what the business actually needs. Inventory, maintenance scheduling, approvals, and reporting are all categories worth watching. The systems least exposed are the ones where the vendor's value is a moat that can't easily be rebuilt: deep regulatory compliance, a payments network, decades of security hardening, a dense web of integrations.
When a company licenses software, the upgrades, patches, compliance updates, and around-the-clock support all show up automatically. That's the deal — you're renting stability.
The day a company replaces that system with something it built itself, that entire burden lands on its own payroll. It's a real cost, but it doesn't arrive as a line item on an invoice, which is exactly what makes it easy to underestimate.
Starbucks has already had a preview of this risk. The company rolled out an automated inventory-counting system and later pulled it back across North America after it produced inaccurate counts.
That's the risk in miniature: not that AI-built software can't work, but that once it's your software, its failures are your problem. There's no vendor to escalate to, and no external roadmap coming to fix it.
The honest way to evaluate a build decision isn't to compare the license fee to zero. It's to compare that fee to the fully loaded cost of owning the system (its total cost of ownership) for its entire life, including engineering, security, compliance, and the people who have to keep the operational knowledge in their heads.
If the tool is core to how a company competes and the vendor's product doesn't fit, owning it can be worth the tradeoff. If it's a solved problem the vendor already does well, rebuilding it to shave a line item just trades a predictable cost for an unpredictable one.
The organizations that get this right tend to build the same muscle regardless of which tools they use: someone directing what the system should do, someone verifying what it actually produced, and a clear owner accountable for what happens after handoff.
That discipline is what turns AI-generated code into something a business can run on for years, rather than a pile of commits nobody wants to inherit.
This story matters more for mid-market companies than it does for Starbucks, precisely because most companies can't absorb an ownership cost the way a business with a $400 million software budget can.
Three lessons are worth taking from it.
First, this isn't a license to rebuild everything. Starbucks is bringing specific, non-differentiating tools in-house — not its payments infrastructure, not its core platform. Copy the discipline, not the ambition.
Second, the real question was never build or buy. It's where does owning our own process actually matter? Build where a vendor's assumptions are actively fighting the business, and that friction is costing real money or speed. Buy where a vendor has already solved a hard, regulated, or commodity problem better than an internal team ever will.
Third, respect the maintenance tail. Generating the application is now the cheap, fast part. The expensive part is the years of software maintenance, security, and support that follow. A company that doesn't know who owns, secures, and maintains what it builds hasn't saved money — it's just moved the bill somewhere harder to see.
The opportunity here is real. For the first time, a smaller company can own software shaped exactly to how it works, instead of contorting itself around someone else's defaults. The trap is mistaking a smaller invoice for a lower cost. Those are not the same thing, and the companies that win this shift will be the ones that understand the difference before they start building.
Jason Talley is Managing Director at Launch Consulting Group, where he advises enterprise and mid-market clients on AI-driven technology strategy and the build-versus-buy decisions reshaping how companies own their operations.
By Jason Talley, Managing Director, Launch Consulting Group
The build vs buy software question has come into sharp focus after a recent report on Starbucks' plan to build its own inventory and maintenance software in-house, rather than continuing to license it from vendors like Microsoft and IBM. The move has been framed as a story about a $400 million line item. It isn't. The number is the headline, but it's not the point.
The real story is about who owns the opinion of how your business runs.
Every piece of enterprise software a company buys carries assumptions with it: how inventory should be counted, how maintenance should be scheduled, how a workflow is supposed to move from one desk to the next. Adopt the system, and you adopt its opinion.
When that opinion doesn't match how your business actually operates, there have historically been only two options: bend the business to fit the software, or spend heavily to customize the software to fit the business.
Neither has ever been a satisfying answer.
For the first time, AI-assisted software development makes a third option affordable: build a simpler custom system that reflects your own way of working. That's what's actually happening here. Starbucks isn't only trying to spend less. It's trying to reclaim ownership of its own process.
It's tempting to read this as proof that AI has rewritten the economics of build versus buy across the board.
It hasn't — not entirely.
What AI has changed is the starting cost. For decades, the math was simple: building software in-house was so slow and expensive that buying almost always won. AI has collapsed the cost of writing code, and that genuinely shifts the build-vs-buy calculus for a lot of internal tools. A custom inventory management system that once took years to build can now be stood up in weeks.
That speed is real, but it's only as good as the discipline wrapped around it. The fastest AI-assisted development cycles I've seen still put an experienced engineer in the loop at both ends: someone setting clear intent before the system generates anything, and someone verifying what comes out the other side before it ships. Skip that discipline and a faster development cycle just means accumulating technical debt faster.
What AI hasn't touched is what happens after launch. Ownership is forever. Security patches, compliance updates, edge cases, and the person who knows what to do when the system breaks at 2AM. All that responsibility transfers the moment you stop paying a vendor and start running your own code.
The systems most exposed to this shift are what might be called the commodity middle: internal tools that encode a company's own quirks, don't touch regulated data, and where the vendor's product has drifted away from what the business actually needs. Inventory, maintenance scheduling, approvals, and reporting are all categories worth watching. The systems least exposed are the ones where the vendor's value is a moat that can't easily be rebuilt: deep regulatory compliance, a payments network, decades of security hardening, a dense web of integrations.
When a company licenses software, the upgrades, patches, compliance updates, and around-the-clock support all show up automatically. That's the deal — you're renting stability.
The day a company replaces that system with something it built itself, that entire burden lands on its own payroll. It's a real cost, but it doesn't arrive as a line item on an invoice, which is exactly what makes it easy to underestimate.
Starbucks has already had a preview of this risk. The company rolled out an automated inventory-counting system and later pulled it back across North America after it produced inaccurate counts.
That's the risk in miniature: not that AI-built software can't work, but that once it's your software, its failures are your problem. There's no vendor to escalate to, and no external roadmap coming to fix it.
The honest way to evaluate a build decision isn't to compare the license fee to zero. It's to compare that fee to the fully loaded cost of owning the system (its total cost of ownership) for its entire life, including engineering, security, compliance, and the people who have to keep the operational knowledge in their heads.
If the tool is core to how a company competes and the vendor's product doesn't fit, owning it can be worth the tradeoff. If it's a solved problem the vendor already does well, rebuilding it to shave a line item just trades a predictable cost for an unpredictable one.
The organizations that get this right tend to build the same muscle regardless of which tools they use: someone directing what the system should do, someone verifying what it actually produced, and a clear owner accountable for what happens after handoff.
That discipline is what turns AI-generated code into something a business can run on for years, rather than a pile of commits nobody wants to inherit.
This story matters more for mid-market companies than it does for Starbucks, precisely because most companies can't absorb an ownership cost the way a business with a $400 million software budget can.
Three lessons are worth taking from it.
First, this isn't a license to rebuild everything. Starbucks is bringing specific, non-differentiating tools in-house — not its payments infrastructure, not its core platform. Copy the discipline, not the ambition.
Second, the real question was never build or buy. It's where does owning our own process actually matter? Build where a vendor's assumptions are actively fighting the business, and that friction is costing real money or speed. Buy where a vendor has already solved a hard, regulated, or commodity problem better than an internal team ever will.
Third, respect the maintenance tail. Generating the application is now the cheap, fast part. The expensive part is the years of software maintenance, security, and support that follow. A company that doesn't know who owns, secures, and maintains what it builds hasn't saved money — it's just moved the bill somewhere harder to see.
The opportunity here is real. For the first time, a smaller company can own software shaped exactly to how it works, instead of contorting itself around someone else's defaults. The trap is mistaking a smaller invoice for a lower cost. Those are not the same thing, and the companies that win this shift will be the ones that understand the difference before they start building.
Jason Talley is Managing Director at Launch Consulting Group, where he advises enterprise and mid-market clients on AI-driven technology strategy and the build-versus-buy decisions reshaping how companies own their operations.
