New York Thursday, October 22, 2026

Boldest Voice

Search

Technology

AI Is Turning Buy vs. Build Into a UX Decision for Enterprise Software

Artificial intelligence has made building internal tools cheaper and buying enterprise software easier, but product teams now face a harder question: where does the complexity land — in their code, a vendor's roadmap, or on users? A new analysis argues that design and user experience must be part of the buy-versus-build calculation from the start.

Buy vs. build is now also a UX decision, especially in enterprise

Enterprise product teams weighing whether to buy software or build it internally are being forced to add a new voice to the conversation: the user experience designer. Artificial intelligence has simultaneously made building cheaper and buying easier, but the trade-off now hinges on who owns the upkeep, the seams between tools, the chat surfaces where work actually happens, and the data itself.

For most of their careers, product managers owned the buy-versus-build decision. A product manager wrote the business case, finance checked the math, and procurement signed off. Designers arrived after the choice was made, inherited whatever system won, and spent years smoothing its rough edges. AI has changed the math on both sides at once, and that old sequence no longer holds.

The shift is visible in enterprise spending. Menlo Ventures found in its 2025 State of Generative AI in the Enterprise report that 76% of enterprise AI use cases were purchased rather than built, up from 53% a year earlier. At the same time, coding agents make a working internal tool look like an afternoon project. More work also happens inside Teams, Slack, Claude, and ChatGPT — surfaces that neither a purchased nor a built option owns.

The central question is no longer which option costs less. It is where the complexity lands: in your own code, in a vendor's roadmap, or on your users. Building is cheaper now, but the yearly upkeep never shows up in the business case. Buying comes with legacy, and that legacy now includes someone else's model, roadmap, and release calendar. There is also a third option that often goes unnamed: replacing the system you already have.

One practitioner budgets 30% of the upfront build cost every year for upkeep — updates, patches, model changes, and new requests. The math is not as straightforward as it seems. Two people spending two weeks at a fully loaded $150 an hour comes to $24,000 up front and $7,200 a year after. A subscription at $20 a seat for 25 people runs $6,000 a year. Over three years, the build costs $45,600 against $18,000, and only one of them comes with a support team.

Every generated line of code is a line somebody has to own, and the initial owner usually does not want that responsibility. Open source offers an early warning. Black Duck's 2026 Open Source Security and Risk Analysis Report found open source in 98% of audited codebases, and 93% held components with no development activity in two years. In 2024, a backdoor reached the widely used XZ Utils library after an attacker spent years earning its maintainer's trust. Generated code carries the same weakness: nobody paid for it, so nobody budgeted to watch it. Google's 2025 DORA Report found that AI adoption still hurts delivery stability.

Buying looks like the cautious choice, and often it is. Purchases from specialized vendors succeeded about 67% of the time, while internal builds succeeded about a third as often, according to research from MIT's NANDA initiative. The fair objection is selection bias, since companies tend to buy for well-understood problems and build for messy ones, which flatters vendors. But the direction matches where enterprise budgets went.

A purchase is never only a feature set. Buyers also get the vendor's data model, release cadence, and theory of what users are trying to do. When you buy, you import another company's organization chart. Systems mirror the communication structures of the organizations that design them, as Melvin Conway observed in 1968. Users end up inside a product tuned for that vendor's largest customers, who may look nothing like them.

Users do not experience a build or a purchase on its own. They experience the gaps. Those gaps can be counted the way clicks are counted in a usability test: pick one real task, follow it across systems, and log every switch and every retyped value. People in a 2022 study of 137 workers on 20 teams at three Fortune 500 companies switched between applications and websites roughly 1,200 times a day. Reorienting after each switch cost them just under four hours a week, about 9% of their working time.

Homegrown tools widen the gaps too. In the 1990s, departments built their own Microsoft Access databases because waiting on the central technology team took a quarter. The databases worked until their authors changed jobs, and then the data inside them became one more place nobody could reach. Today's version is drift: patterns that stop matching the rest of the product and error states nobody designed.

7Views

Blake Kendall

Author

Science Correspondent

Blake Kendall covers public affairs, politics, business, culture and daily news for Boldest Voice. The role focuses on verification, context, and clear explanations for readers.

Read on