Memorandum
- From
- Caroline Mercer via UX Collective
- Date
- Filed
- Business·5 min to read
- Re
AI Reshapes Enterprise Buy vs. Build as UX Becomes Deciding Factor
ReAI Reshapes Enterprise Buy vs. Build as UX Becomes Deciding Factor
Artificial intelligence has lowered the cost of building software and made purchasing easier, pushing design and user experience to the center of enterprise technology decisions. A new analysis argues that companies must weigh maintenance costs, vendor lock-in, and workflow gaps rather than just upfront price.
Artificial intelligence has upended the traditional buy-versus-build calculus in enterprise software, making user experience and long-term ownership the decisive factors rather than initial cost alone. According to an analysis published on UX Design, product teams are now weighing purchased tools against internal builds at the same table, a shift driven by AI's dual effect of making code generation cheaper and vendor offerings more accessible.
For years, product management owned the buy-versus-build decision. A product manager wrote the business case, finance checked the math, and procurement signed off. Designers typically arrived after the decision was made, inheriting whatever system won and spending years smoothing its rough edges. AI has changed the math on both sides simultaneously, but the yearly upkeep of internally built tools rarely appears in the original business case, and purchased software now carries the legacy of a vendor's model, roadmap, and release calendar.
Data from Menlo Ventures' 2025 State of Generative AI in the Enterprise report shows that 76% of enterprise AI use cases were purchased rather than built, up from 53% a year earlier. Meanwhile, coding agents allow a designer to stand up a working internal tool in what feels like an afternoon, a practice Andrej Karpathy dubbed «vibe coding» in 2025. But prototypes and production code are not the same thing. Most internal tools become code that must be maintained, which makes them products requiring a budget, an owner, and support when they break.
The analysis recommends budgeting 30% of the upfront build cost every year for upkeep, including updates, patches, model changes, and new feature requests. A simple calculation illustrates the trap: two people spending two weeks at a fully loaded $150 per hour costs $24,000 upfront and $7,200 annually in maintenance. A subscription at $20 per seat for 25 people runs $6,000 a year. Over three years, the build costs $45,600 against $18,000 for the subscription, and only the purchased option comes with a support team.
Open source software offers an early warning. Black Duck's 2026 Open Source Security and Risk Analysis Report found open source components in 98% of audited codebases, with 93% containing components that had no development activity in two years. In 2024, a backdoor reached the widely used XZ Utils library after an attacker spent years earning the maintainer's trust. Generated code carries a similar risk: nobody paid for it, so nobody budgeted to monitor it. Google's 2025 DORA Report also found that AI adoption still hurts delivery stability.
Buying is not a guaranteed safe harbor either. Research from MIT's NANDA initiative, covered in Fortune, found that purchases from specialized vendors succeeded about 67% of the time, while internal builds succeeded about a third as often. The comparison is imperfect because companies tend to buy for well-understood problems and build for messy ones, but the direction matches where enterprise budgets have gone. A purchase also imports the vendor's data model, release cadence, and assumptions about users, effectively embedding another company's organizational chart into your workflows, as Melvin Conway observed in 1968.
Users do not experience a build or a purchase in isolation. They experience the gaps between systems. A 2022 study of 137 workers on 20 teams at three Fortune 500 companies found that employees switched between applications and websites roughly 1,200 times a day, losing just under four hours a week to reorientation, about 9% of their working time. Homegrown tools can widen those gaps through drift, as patterns stop matching the rest of the product and error states go undesigned. The practical advice is to measure those gaps by following a single real task across systems and logging every switch and retyped value, then deciding where the complexity should land: in your code, in a vendor's roadmap, or on your users.
3
