Most enterprise technology decisions begin with a seductive premise. The belief that the business is different and nobody else has solved this exact problem before.
A business finds a gap and decides their version of the problem is unlike anyone else’s, so they build from scratch. The early results usually look promising, the prototype works and leadership signs off. Then the reality sets in. What follows is less visible but far more expensive. The team that built it becomes the team that maintains it, and the capacity that was supposed to go toward the next initiative gets absorbed by the last one.
Most organizations budget for a project and inherit an operation.
Scott Kinka, Chief Strategy Officer of Bridgepointe Technologies and a 30-year technology veteran, has watched this dynamic play out across thousands of enterprise engagements. On a recent episode of the In Other Words podcast, he identified the two fallacies that consistently get in the way of sound decision-making on this topic.
“I think the first fallacy is this idea that they’re the most unique business in the world, and no one’s ever had the same problem as them. The other challenge that businesses have is believing that building is a one-time event. Because it just never is.”
When the balance sheet changes shape
Internal builds make sense on paper at the project level. Across the enterprise, the economics are far less obvious. A prototype requires a handful of engineers, a few months, and a manageable budget. Scaling that same system across regions, compliance frameworks, and business-critical workflows requires something fundamentally different.
MIT’s GenAI Divide report studied more than 300 publicly disclosed AI initiatives and found that roughly 95% of organizations were seeing zero measurable return from their generative AI pilots. Only about 5% were capturing meaningful value.
The researchers found that purchasing AI tools from specialized vendors and building partnerships succeeded about 67% of the time, while internal builds succeeded only one-third as often. The dividing line was not model quality or regulation but approach.
Phrase CEO Georg Ell made a related argument in Forbes earlier this year. “They think they are deciding whether to keep building or buy a vendor product. They are actually deciding whether to put a new class of operational obligation onto the enterprise balance sheet.”
That distinction matters because it changes who owns the consequences. A project has a sponsor, a budget, and an end date, while an operational obligation has none of those boundaries. It requires ongoing governance, compliance, staffing, and funding that grows year over year. And because the original project was approved as a capital expenditure, the recurring operational cost often lacks a clear owner. The team that built the system becomes its maintenance crew by default, and their capacity for new work shrinks accordingly.
Elaine Barsoom, who built Nike’s first AI Center of Excellence and previously co-led digital ventures at American Express, has observed this pattern from the inside as she shared on a recent episode of In Other Words.
“When you build, you own every decision the software touches. The governance, the compliance, the workflows that grow around it, and the people maintaining it years later without the context of why it was built that way.”
The uniqueness trap
Scott’s hierarchy for approaching technology decisions is disarmingly simple. Start from the question of whether you can commercially buy the capability you need. If you can, but it is not close enough, ask whether you can customize or build on top of something that already exists. Only if the answer to both is no should you consider building from scratch.
“Businesses that are not themselves tech businesses should never start from a build idea. You may land there because you found out you really were the most unique business in the world. But don’t start there.”
The one-time-investment assumption is more dangerous because it tends to be reinforced by how organizations approve spending. A build gets the green light as a project with a fixed budget. But the costs that follow, including support staff, upgrade cycles, and integration work, arrive incrementally and rarely face the same level of scrutiny. By the time the true cost is visible, the sunk cost is too large to walk away from comfortably.
Scott uses an analogy his clients tend to remember.
“I consider it a hamster wheel. When you get on, you can’t dismount.”
The strategic cost nobody budgets for
The financial cost of maintenance is measurable, but the strategic cost is harder to quantify and often more damaging.
There is tech debt, ongoing support, uptime, integration work, and the constant requirement to keep the system aligned with the business around it. Each carries a recurring cost that accumulates rather than diminishes, and each draws engineering talent away from work that could be creating differentiation elsewhere in the business.
Over the past five years, the role of IT leadership has changed substantially. Post-COVID, many CIOs and IT directors earned a seat in the boardroom by proving their strategic value during a period of forced transformation. That seat came with an expectation that technology leadership would continue to drive business value rather than just keep systems running.
An IT leader who spends hard-won influence maintaining internally built systems risks being seen once again as a cost center. Every engineering hour devoted to upkeep is an hour not spent on the initiatives that justified the strategic role in the first place. The irony is that the decision to build, which often originates from a desire for control and competitive advantage, ends up consuming the capacity for both.
This pattern is especially visible in categories where the underlying technology keeps moving. In global content operations, for example, AI models are updated at a pace that makes any internal build a moving target, regulatory requirements vary by market and change without warning, and quality benchmarks evolve as customer expectations in each market rise independently. An internal build that performs well in month six can fall behind by month eighteen, and the team maintaining it may not realize it until the gap becomes visible to customers.
Georg’s recommendation is to
“Build only the differentiating layer. Buy or partner for the layers where liability weight grows faster than competitive advantage.”
FunPlus, the global gaming company behind titles including State of Survival and DC: Dark Legion, experienced what happens when operational complexity outpaces the systems supporting it. With a 17-person content team managing updates across ten live titles in more than 30 languages, the company had been relying on manual file transfers, Google Sheets, and email to coordinate global releases.
After restructuring its content operation around the Phrase Platform, FunPlus now handles 30% more content with the same team size, and efficiency savings outweigh the platform cost by roughly ten times. What had been an operational expense became a measurable profit driver.
FunPlus shows how quickly operational complexity becomes a business cost when teams are forced to manage growth through manual coordination. The engineering and project management resources consumed by coordinating files, tracking updates, and chasing vendors were resources that could have been directed toward improving the player experience for millions of users worldwide.
The question worth asking this quarter
Most executives have watched this cycle play out at least once, where a capable team builds something impressive and then the years of maintenance quietly consume the capacity that was supposed to go toward the next thing.
The issue worth examining is whether your organization is currently maintaining a system that a commercial platform could handle. And if it is, would the people responsible for maintaining it tell you so, given that they are also the people who built it.
Sunk cost has a way of becoming institutional identity, where the build becomes something the team is proud of, then something they defend, and eventually something nobody is willing to revisit even as the opportunity cost grows.
Scott summarizes the underlying discipline with a characteristic phrase.
“Every tool that does everything doesn’t do anything particularly well,” he said.
The organizations that navigate this well are the ones that resist the temptation to own every layer and instead concentrate their resources where ownership creates genuine competitive separation. They build the differentiating layer and partner for everything else.
The question is not whether your team can build it. The question is whether maintaining it is the best use of the strategic capacity you have.
Watch the full conversation
Building tech internally? Scott Kinka calls it a hamster wheel you can never get off. In this episode of In Other Words, Scott shares why build vs. buy matters more as businesses expand into new markets. They cover partner ecosystems and where AI is creating value for organizations investing in platforms they can build on.
