Buy or build has become a design decision, not just a product and finance one

With AI, building an internal tool has become as easy as subscribing to one. The real difference now lies in maintenance, the seams between systems, and who controls the data, and that's design work.

For years, the choice between buying an off-the-shelf tool or building one in-house was a matter for product managers and finance. Whoever designed the experience arrived later, inherited the result, and spent years sanding down the rough edges. An article published on October 21, 2026, in UX Collective, written by designer Patrick Neeman, argues that artificial intelligence has changed that math on both sides at once, and that this pushes design into the decision itself, not after it.

The logic is simple to state: building got cheaper with coding agents, buying got easier with the explosion of ready-made AI products. According to Menlo Ventures data cited in the piece, 76% of enterprise AI use cases in 2025 came from buying, up from 53% a year earlier. At the same time, a functional internal tool can be born in an afternoon with a coding agent, before the salesperson even returns the call.

In short: the question is no longer "what costs less," it's "where will the complexity land": in your own code, in a vendor's roadmap, or in the lap of whoever uses the product every day.

Maintenance is the line item missing from the build budget

Andrej Karpathy coined the term vibe coding, in 2025, for this loose style of programming with generative AI. Simon Willison made an important caveat: a prototype can be loose, but code that becomes a product has to be read like any other code. Most internal tools born this way end up becoming real products, with people depending on them, and a product needs an owner, a budget, and someone to call when it breaks.

Neeman says he's been through this himself: an internal workflow application, built before the AI era, looked great at launch and turned into a maintenance nightmare as soon as people started depending on it. Every new approval step required touching code that few people understood. That's where his rule comes from: set aside 30% of the initial build cost, every year, just for maintenance.

The math becomes clear in an example from the article itself: two people spend two weeks building a tool, at a total cost of $150 an hour, which comes to $24,000 in initial investment plus $7,200 a year in maintenance. An equivalent subscription, at $20 per seat for 25 people, costs $6,000 a year.

Only one of the two columns comes with a support team behind it. Black Duck's 2026 report on open source risk, cited in the article, shows the other side of the same problem: open source shows up in 98% of audited repositories, and 93% have components with no development activity for two years. The backdoor found in the XZ Utils library in 2024, the result of years of trust an attacker built up with the maintainer, is the extreme example of code nobody paid to watch over. Google's 2025 DORA Report, in turn, found that AI adoption still hurts teams' delivery stability.

Buying imports the vendor's structure along with it

Buying looks like the cautious choice, and often it is. Research from NANDA, an MIT initiative cited by Fortune, found that purchases from specialized vendors succeeded in about 67% of cases, compared to a third of that for internal builds. There's an obvious selection bias here: companies tend to buy for well-understood problems and build for messy ones, which favors the vendor in the comparison.

Still, a purchase is never just a set of features. Along with it comes the vendor's data model, its release calendar, and its theory of what your users are trying to do. Systems mirror the communication structure of the organizations that design them, as Melvin Conway observed in 1968: buying means importing another company's org chart, tuned for its most important customer, who may look nothing like your audience.

The user is the one who feels the seam between tools

Nobody uses "the build" or "the purchase" in isolation. People live in the seams between systems, and that can be measured the same way clicks are measured in usability testing: pick a real task, follow it across every system, and log every screen switch and every piece of retyped data. A 2022 study of 137 people across 20 teams at three Fortune 500 companies, published by Harvard Business Review, found something around 1,200 app switches a day, costing nearly four hours a week in reorientation, about 9% of work time.

Homegrown tools make that math worse. In the 1990s, entire departments built their own databases in Microsoft Access because waiting for the central technology team took a whole quarter; the databases worked fine until the author changed jobs, and then the data became just one more place nobody could access anymore. The current version of this is drift: visual patterns that stop matching the rest of the product and error states nobody designed.

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

Patrick Neeman, designer and writer for UX Collective

Larry Tesler's law helps name the phenomenon: complexity is conserved, and the only real choice is who absorbs it. Building pushes complexity into your own code; buying pushes it into another company's roadmap; mixing the two without a clear criterion pushes it onto the user, one copy-paste at a time.

The product lives inside another company's chat

In many organizations, the place where people encounter your product is no longer your product: it's Teams, Slack, Claude, or ChatGPT. OpenAI brought apps into ChatGPT conversations in 2025, with the launch of the Apps SDK. In January 2026, the MCP Apps specification began allowing tools connected via Model Context Protocol to return interactive interfaces that render directly inside Claude and ChatGPT.

Neeman has lived through this logic before: he designed the developer documentation for Myspace's third-party app platform, launched in 2008, in which the social network set the box size, the permissions, and what an app could know about the profile being viewed. Today's rules are just as specific, and they belong to the host, not to whoever builds the app:

• An inline card in ChatGPT has a maximum of two actions, no nested scrolling, system font, and a logo added by the host itself, according to OpenAI's interface guidelines for the Apps SDK;
• A Slack message supports up to 50 blocks, under the Block Kit standard;
• Microsoft recommends Adaptive Cards as the default card type for new development in Teams.

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

Patrick Neeman, designer and writer for UX Collective

The practical recommendation that follows: treat the card as a product in its own right, with a single task, one primary action, and a clear exit path to the full application when the task outgrows what the host can hold.

Before you replace it, measure what already exists

Most of these decisions don't start from scratch: something already exists, and the real question is whether it's worth replacing. Research by Michael Norton and coauthors, published at Harvard, describes the IKEA effect: people value their own amateur work almost as much as an expert's work, which pushes teams to prefer keeping what they built even when it isn't the best option.

"Not invented here" syndrome makes things worse. A 1980 MIT study by Ralph Katz and Thomas Allen tracked 50 research and development groups and found that teams that had worked together for five years or more performed significantly worse and talked less with outside professionals. Coding agents lower the cost of acting on that reflex, because rebuilding a vendor's feature now takes a weekend instead of a full budget cycle.

And estimation deceives too. A randomized trial from METR found that experienced developers took 19% longer on real tasks when using AI tools, but afterward estimated they had been 20% faster. It's a small study, of 16 developers, and METR itself already classifies it as outdated, but it still serves as a warning: price your own prototype the way you'd price a stranger's.

Buy the commodity, build the differentiator

The clearest criterion cited in the article comes from Simon Wardley, who organizes product components on a spectrum running from genesis to commodity, passing through custom-built and product. It can be summed up like this: build where your own data is the advantage, where regulation keeps any off-the-shelf product from serving the need, and in the moments where you're actually competing. If a feature would look the same in any competing product, it's probably already a commodity.

That assumes having skilled people, and most organizations don't. An IBM survey of 8,584 technology professionals, published in January 2024, found a skills shortage as the top barrier to enterprise AI adoption, cited by 33% of respondents, with data complexity in second place at 25%. Vibe coding delivers a demo, not the skills a production AI application demands: search over messy data, continuous evaluation, permissions, and monitoring.

Whoever holds the data decides what the screen can show

A model can only respond based on what it can see, and the experience follows wherever the data lives. Buying a tool means your records sit in the vendor's schema, accessible on its terms; building keeps the data with you, along with the obligation to govern it. Anthropic, when introducing the Model Context Protocol in 2024, described exactly this problem: models isolated from data trapped behind silos and legacy systems.

Regulation is starting to put a price on this. The European Union's Data Act has been in force since September 2025, and data-switching fees between providers end entirely in January 2027. Leaving a vendor is getting cheaper on paper; in practice, a migration is a data project with a UX bill built in: renamed fields, lost history, reports that stop matching up.

Models retire, and that's an unscheduled redesign

Whether bought or built, part of the product ends up running on something the company doesn't control. Anthropic promises at least 60 days' notice before retiring a publicly released model; the company's 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. Buying a product built on a model suffers the same effect, just one layer removed and on the vendor's own calendar, which may not even mention the model swap in its release notes.

The way out the article recommends is to keep a set of real user tasks with results already known to be correct, run those tasks against every new model or vendor version, and review the results the way you'd review a usability study. Twenty or thirty tasks are enough to start with, as long as they cover the most common requests, the costliest errors, and the cases where the right answer is to refuse.

What changes for whoever designs the product

The decision to buy or build used to end at the contract signature or the launch. Now neither option ends there, because the pieces keep moving afterward. The product and finance spreadsheet captures license cost and development hours, but leaves out what the user feels first: drift in unmaintained tools, lost expertise when a system exits the scene, data stuck where the new tool can't reach, and chat cards whose layout another company decides.

The test the article proposes, following a real task across every system it touches, doesn't say whether the answer is to buy or to build. It says where the complexity will land, so that someone is there on purpose, not by accident. The question worth bringing to the next roadmap meeting isn't which option costs less, it's: if we choose this, who's going to take care of the seam a year from now?