企业AI产品买与建的UX决策框架：复杂度归属与维护成本评估

Artificial intelligence made building cheap and buying easy. The trade-off now turns on who owns the upkeep, the seams between tools, the chat surfaces, and the data.

For most of my career, product management owned buy versus build. A product manager wrote the case, finance checked the math, and procurement signed.

Designers arrived after the decision was made, inherited whatever won, and spent years sanding its rough edges. Artificial intelligence changed the math on both sides at once.

Build is cheaper now, but the yearly upkeep never shows up in the business case.

Buy comes with legacy, and that legacy now includes someone else’s model, roadmap, and release calendar. And usually there’s a third option nobody names: replacing the system you already have.

Menlo Ventures found in 2025: The State of Generative AI in the Enterprise that 76% of enterprise artificial intelligence use cases were purchased rather than built, up from 53% a year earlier. Meanwhile, coding agents make a working internal tool look like an afternoon project.

More work happens inside Teams, Slack, Claude, and ChatGPT, surfaces neither option owns.

Don’t ask which option costs less, Ask where the complexity lands: in your code, in a vendor’s roadmap, or on your users.

Budget for Build Maintenance

A designer with a coding agent can now stand up an internal tool before a vendor’s sales team returns the call. Andrej Karpathy named that loose style vibe coding in 2025, and Simon Willison drew the line in Not all AI-assisted programming is vibe coding (but vibe coding rocks). Prototypes can be loose, but code you keep has to be read like any other.

Most internal tools become code you keep, which makes them products. It needs a budget, an owner, and someone to call when it breaks. Most teams don’t think of it that way, because nobody bought anything.

I learned this the hard way.

We built an internal workflow application in one place I worked at, before AI, because nothing we could buy matched how our teams worked. It shipped fast, people came to depend on it, and that’s exactly when it became a nightmare to maintain.

Every new approval step meant changing code few people understood, small fixes broke things elsewhere, and nobody had budgeted time for any of it.

That’s where my rule comes from. I budget 30% of the upfront build cost every year for upkeep: updates, patches, model changes, and new requests.

Run that math and many vibe-coded apps cost more than the subscriptions they replace. Say two people spend two weeks at a fully loaded $150 an hour, which is $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 came with a support team.

Every generated line is a line somebody has to own, and the initial owner usually doesn’t want that responsibility.

Open source taught this lesson first. 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 has the same weakness: nobody paid for it, so nobody budgeted to watch it. Google’s 2025 DORA Report found adoption of artificial intelligence still hurts delivery stability.

Accept the Vendor’s Legacy

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 covered in Fortune’s MIT report: 95% of generative AI pilots at companies are failing.

The fair objection is selection, since companies tend to buy for well-understood problems and build for messy ones, which flatters vendors. Hold the number loosely, but the direction matches where enterprise budgets went.

A purchase is never only a feature set. You also get the vendor’s data model, release cadence, and theory of what your 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. Your users end up inside a product tuned for that company’s largest customers, who may look nothing like yours.

Measure the Tool Gaps

Users don’t experience your build or your purchase on its own. They experience the gaps. You can count those gaps the way you’d count clicks in a usability test: pick one real task, follow it across systems, and log every switch and every retyped value.

The gaps add up fast.

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, according to How Much Time and Energy Do We Waste Toggling Between Applications? in Harvard Business Review and AAPL Leadership.

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.

Complexity always lands somewhere, and the only choice is where.

Complexity is conserved, and the only real choice is who absorbs it. That’s Larry Tesler’s law.

A build moves complexity into your codebase, while a purchase moves it into someone else’s roadmap. A careless mix of both moves it onto your users, one copy-and-paste at a time. Before anyone argues about license fees, ask where the complexity ends up under each option.

Design for Host Surfaces

In many organizations, the place people meet your product is no longer your product. It’s Teams, Slack, Claude, or ChatGPT.

Apps moved inside ChatGPT conversations in 2025 with OpenAI’s Introducing apps in ChatGPT and the new Apps SDK. In January 2026, MCP Apps — Bringing UI Capabilities To MCP Clients let tools return interactive interfaces that render inside Claude and ChatGPT. Build or buy, your most-used screen may end up as a card in someone else’s window.

I’ve worked inside this arrangement before. I designed the developer documentation site for Myspace, whose 2008 developer platform let third-party applications run on member profiles. The host set the box size, the permissions, and what an app could know about the person looking at it. Every app was designed inside that frame, and chat surfaces are drawing it again.

The host draws the frame, and your job is deciding what fits inside it.

The rules are specific, and they belong to the host. An inline card in ChatGPT gets at most two actions, no nested scrolling, the system font, and a logo the host adds for you, per OpenAI’s UI guidelines for the Apps SDK.

A Slack message holds up to 50 blocks under Block Kit. Microsoft’s Types of Cards & their Usage names Adaptive Cards the recommended card type for new Teams development.

People expect your product to work like the places where they spend most of their time, which is Jakob Nielsen’s Jakob’s Law of Internet User Experience. Inside a chat surface, that stops being advice, because the host’s patterns are the only ones on offer. So design the card as its own product, with one job, one primary action, and a handoff to your full application when the task outgrows it.

Count the Replacement Cost

Most of these decisions aren’t made on empty ground. Something already exists, and the real question is whether to replace it. Replacement carries costs that appear in neither column.

The first cost is lost expertise. Task time falls with repetition, which is the Power Law of Practice covered on my UX Guidelines site (@usabilitycounts), and your power users have years of repetitions in the old tool. Replace it, and they start the curve over, usually in the busiest quarter.

The second cost is hidden rules. You shouldn’t tear down a fence until you know why it went up, as G. K. Chesterton argued in 1929. Old enterprise software is full of fences, and each one was a rule somebody once needed.

The new thing always wins the demo against the tool people already know.

The third cost is our own bias. People value their amateur work about as highly as experts’ work, according to Michael Norton and his co-authors in The IKEA Effect: When Labor Leads to Love. Melissa Perri described the organizational version in The Build Trap: building is the easy part, and teams get rewarded for shipping instead of for learning what customers need.

Not invented here makes it worse. Not invented here is the reflex of rejecting an outside solution because someone else made it. Ralph Katz and Thomas Allen tracked 50 research and development project groups for An empirical test of the Not Invented Here (NIH) Syndrome, a 1980 MIT working paper.

Groups that had worked together five or more years performed significantly worse, and they talked less with professionals outside the team. Coding agents lower the price of acting on that reflex, because rebuilding a vendor’s feature now takes a weekend instead of a budget cycle.

Coding agents also distort the estimate. Experienced developers took 19% longer on real tasks with the tools, yet estimated afterward they had been 20% faster, in METR’s randomized trial Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity.

It’s one study of 16 developers, and METR now flags it as out of date. Still, price your own prototype the way you’d price a stranger’s.

Buy Commodities, Build Differentiators

The clearest test I know comes from Simon Wardley (@swardley). In Finding a path, he sorts components from genesis to custom built to product to commodity.

His shorthand for building commodities yourself is Thomas Thwaites, the designer who spent nine months trying to build a toaster from raw materials. A coding agent shrinks the nine months to a weekend, which matters less than it seems, because you still own every repair after it ships.

Coding agents change the toaster math, not the toaster.

For products built on artificial intelligence, the map has a clear split. The model is sliding toward commodity, rented by the token. The experience around it is still custom: how a suggestion explains itself, how someone corrects it, and whether people trust it. A competitor can’t copy that by signing the same contract.

Building still wins in a few places. Build when your own data is the advantage and a vendor would have to hold it to use it.

Build when regulation rules out every product on the market, and build the moments you compete on. If a feature would look the same in every competitor’s product, though, it’s probably a commodity.

Those cases also assume you have the people, and most organizations don’t. Vibe coding gets you a demo, not the skills a production artificial intelligence application needs: retrieval over messy records, evaluations, permissions, and monitoring.

IBM surveyed 8,584 technology professionals for Data Suggests Growth in Enterprise Adoption of AI is Due to Widespread Deployment by Early Adopters, published in January 2024. Limited skills and expertise topped the barriers at 33%, with data complexity next at 25%. The more data an application touches, the wider that gap gets.

Map Where Data Lives

A model can only answer from what it can see, so the experience follows wherever your data lives. Buy a tool and your records sit in the vendor’s schema, reachable on the vendor’s terms.

Build one and the data stays yours, along with the job of governing it. When Anthropic announced the Model Context Protocol in 2024, it described models cut off from data trapped behind silos and legacy systems.

So run the landing test a second time, aimed at the data. A card in Teams is only as useful as the permissions behind it, and an assistant that can’t reach the contract can’t summarize it.

Whoever holds the records decides what any surface can show.

Regulation is starting to price this in. The law has applied since September 12, 2025, and switching charges between data processing providers, including data egress fees, end entirely on January 12, 2027, according to the European Commission’s Data Act explained.

Leaving a vendor is getting cheaper on paper. In practice, a migration is mostly a data project with a UX bill attached: renamed fields, lost history, and reports that no longer match.

Before any contract, ask where the data will live, who can export it and in what format, and whether the surfaces your people already use can reach it.

Those answers shape the experience more than the feature list does.

Prepare for Model Retirement

Either way, part of your product now runs on something you don’t control. Build on a model and that model will be retired. Anthropic promises at least 60 days’ notice before retiring a publicly released model.

Its Model deprecations page lists the Claude Sonnet 4.5 snapshot from September 2025 as deprecated on September 30, 2026, with retirement set for November 30, 2026.

Buy a product built on a model and the same thing happens, one layer removed and on the vendor’s schedule. Tone shifts. Refusals move. Summaries grow or shrink, and edge cases that used to pass start failing. A vendor’s release notes may not mention a model change at all, so ask in the contract how much notice you’ll get.

A model swap is a redesign nobody scheduled, and now happens on a frequent basis. Maintenane is now a real time activity.

The exit plan belongs to design, not only to procurement. Keep a set of real user tasks with known good outcomes, run them against every new model or vendor release, and review the results the way you’d review a usability study. Twenty or thirty tasks is enough to start, as long as they include the common requests, the expensive mistakes, and the cases where the correct response is to decline.

Decide Where Complexity Lands

Buy versus build used to end at the signature or at launch. Now neither choice finishes, because the parts keep moving after the decision. Building got cheaper and stayed expensive to own. Buying got easier and arrived carrying more of someone else’s history than the demo let on.

So the decision can’t stay with product management and finance. The numbers in that spreadsheet are real enough. They just leave out the costs users feel most: drift in tools nobody maintains, expertise lost when an old system goes away, data stuck where new tools can’t reach it, and chat surfaces whose layout rules you don’t set.

Designers, product managers, and researchers are the people who see those costs first. They can also measure them, in task time and in the moments where someone gives up. Bring that evidence to the decision before it’s made, not after it ships.

The landing test won’t tell you whether to buy or build. It tells you where the complexity will go, so somebody can be standing there on purpose. Most of the time, that points toward buying the commodity and building the difference. The seams between the two are yours either way, so design them.

Action Items

• Test vendors against prototypes. Run a hands-on bake-off with real tasks, using the scenario-based method in The Right Way to Select Technology by Tony Byrne and Jarrod Gingras. Enter your current system and a quick internal prototype alongside the vendors, and ask the current system’s heaviest users why each odd step exists.
• List every system touched. Pick one real task and follow it from start to finish. Write down each system it passes through, where each value is stored, and who can export it, then put that list in the business case next to the license fee.
• Budget 30% for upkeep. Before a build ships, name the person who maintains it and set aside 30% of its build cost every year. Treat that line as fixed, the way you would a subscription, so fixes and library updates don’t wait for spare time.
• Retest after model changes. Keep 20 to 30 real tasks with known good answers, including the common requests and the costly mistakes. Run them whenever a model or vendor release changes what’s underneath, and review the results like a usability study.

Buy vs. build is now also a UX decision, especially in enterprise was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.