When Building Is Cheap, What Is a Product For?

Every software product is a compromise someone else negotiated on your behalf. Since the mid-1980s, firms have accepted that compromise more and more: packaged products now make up about half of what US businesses invest in software, up from a fifth. AI is repricing the compromise. That changes each firm’s build-versus-buy decision, and it puts pressure on every product built by generalizing its customers’ requirements.

Every product is a bundle of other people’s requirements

A software vendor’s real job is aggregation. It collects requirements from hundreds or thousands of customers, finds where they overlap, and ships one product that covers the common ground. Each customer pays a fraction of what building would cost. In return, each customer accepts that the product was not designed for them.

That gap between the product and the business is misfit. It shows up as the spreadsheet beside the CRM, the approval that happens over email because the workflow engine cannot model it, and the sentence “that’s just how the system works.” Teams reshape their processes around the software, and over time they forget they ever had a choice.

The classic build-versus-buy decision weighed the cost of building and maintaining software against a license fee. Misfit rarely appeared in the spreadsheet because nobody could price it. As products improved and building stayed expensive, more firms chose to buy.

The configurable enterprise suite is this model at its peak. Its settings, modules and rule engines hold the accumulated requirements of thousands of companies, frozen into options. Implementing one often takes a consulting team, because someone has to translate your business into the vendor’s general form.

How firms moved from building to buying

Packaged products are now half of firms' software, up from a fifth in 1985 Share of US private investment in software by type, 1985 to 2025. Packaged rises from 21% to 50%, custom contracted work moves between 31% and 44% and ends at 37%, and software built in-house falls from 47% to 13%. Packaged products are now half of firms' software, up from a fifth in 1985 Share of US private investment in software, by how it was sourced 0% 20% 40% 60% 1985 1995 2005 2015 2025 21% Packaged 50% 32% Custom (contracted) 37% 47% Built in-house 13%
Source: U.S. Bureau of Economic Analysis via FRED, private fixed investment in software, current dollars, 1985–2025. Excludes most SaaS subscriptions.

Firms did not switch from building to buying all at once. Between 1985 and 2000, software built in-house fell from 47% to 23% of US business software investment. The work moved to packaged products and to outside developers. From 2000 to about 2016 the split barely moved, and since then packaged software has climbed to half of the total.

Contracted custom work never went away. Its share has stayed between 31% and 44% since 1990, and it was higher in 2010 than in 2005. The BEA counts the tailoring of packaged software by its providers as custom work, so part of that share is what firms pay to make products fit.

The chart also understates the move to products. National accounts generally record SaaS subscriptions as an operating expense rather than an investment, so most cloud software is missing here. Gartner forecast $299 billion of worldwide SaaS spending in 2025.

AI makes fit cheap

AI lowers the cost of writing software for an audience of one. A small team working with coding agents can turn a well-described workflow into a tested internal tool in days, not quarters. The first version is no longer the expensive part.

The bigger change is the cost of changing software. Custom systems used to decay because every modification needed the engineer who wrote them, and that engineer had usually moved on. Code that an agent can read, explain and safely modify does not go stale in the same way. That weakens the strongest historical argument against building: maintenance.

It also makes misfit visible. Once you can see an exact-fit prototype of your own process, sometimes within an afternoon, the workarounds around your bought software stop looking like the cost of doing business. They start looking like a choice you keep paying for.

What happens to products built on generalization

Follow the logic one step further. If a product’s main contribution was generalization, and generalization was only necessary because fit was expensive, then cheap fit removes much of the product’s reason to exist. The pressure arrives in a particular order.

The long tail goes first. The feature checklist in an RFP was always a proxy for one question: will this cover our odd cases? Those odd cases are exactly what is now cheaper to build than to configure.

Configurability turns into a liability. A product with four hundred settings is effectively a programming language with an awkward syntax and a slow compiler. AI writes code far more easily than people navigate admin screens. The more a vendor invested in configurability, the more its product looks like an inferior way to specify custom software.

Defection starts at the top. Classic disruption comes from below, with cheaper products for less demanding customers. This runs the other way. The first customers to leave are the ones the general product fit worst, and they are often the same customers paying for premium tiers and long implementation projects.

The requirements commons thins out. There is a quieter loss, too. Products were how an industry shared solutions. One customer’s feature request became everyone’s feature. When the most demanding customers build their own, vendors lose the signal that kept their roadmaps improving.

The generalization doesn’t disappear. It moves

It would be easy to conclude that generalized software is finished. It isn’t. The work of generalizing is still being done. It is just being done in different places.

Into the model. A capable AI model is itself a vast generalization of requirements and implementations. It has absorbed how thousands of CRMs, ticketing systems and approval flows work. When a team asks it for “our CRM,” it starts from that accumulated pattern and bends it to their case. The generalization happens once, upstream, and the product is instantiated per customer.

Into the parts that must be identical. Some things are valuable precisely because everyone does them the same way: ledgers, payments, identity, tax, regulatory reporting, data exchange formats. Sameness here is not a compromise forced by cost. It is the feature. Interoperability and auditability depend on it.

Into compliance. Regulated work needs implementations that auditors and regulators already recognize: financial reporting, tax, privacy, healthcare records, card payments. A vendor earns the certification once, whether a SOC 2 report, HIPAA safeguards or PCI DSS, and every customer inherits it. Generating the code is cheap. Proving to a regulator that it is correct is not, and that proof is a cost worth sharing.

Into what only exists across customers. Benchmarks, fraud signals, threat intelligence and pricing data get better as more companies contribute. No single custom build can produce them.

Into accountability. Uptime commitments, security response and someone to call at 2 a.m. are operational work rather than code. Many companies will keep paying others to carry them.

What products become

The likely result is a split. Vendors own the substrate: the system of record, the hard infrastructure, the shared data and the guarantees. Customers, or the AI agents working for them, own the layer on top, where workflows, screens and rules encode how that particular business operates.

That changes what a good product looks like. It exposes clean primitives instead of finished workflows. Its data model is documented well enough for an agent to build on correctly the first time. It treats a customer’s custom layer as the expected way to use it, not as an unsupported hack. And it charges for usage, data or outcomes, because a per-seat price for a generic interface is hard to defend when the customer can generate its own.

Some vendors will go further and ship reference implementations rather than finished applications: a working starting point that each customer’s AI forks and adapts. The product becomes a template with a guarantee behind it.

The vendors that struggle will be the ones whose advantage lived in the interface and the encoded workflow, and the ones that keep customer data hard to reach. Both are bets that customers cannot easily build around them. That bet is getting weaker.

The case against building everything

Cheap building has its own failure modes, and they are worth taking seriously.

Sprawl. When any team can produce a tool in a week, a company can end up with hundreds of them. Each has its own data, its own logic and one owner who will eventually leave. This is shadow IT at machine speed.

Correctness. Generated code still has to be specified precisely, tested against reality and reviewed for security. Cheap code can produce expensive mistakes quickly, and nobody notices until the quarter closes wrong.

Requirements are still the hard part. Most custom software projects did not fail because the code was difficult. They failed because nobody had agreed on what the process actually was. AI does not settle that argument for you.

Bought software came with an opinion. A good product encodes a view of how the work should be done, and that view is often better than what a company would invent on its own. When you build exactly what you asked for, you lose the benefit of being told you were asking for the wrong thing.

Regulation raises the price of building. In regulated areas, every custom system is one more thing to validate, document and defend in an audit. AI has made code cheaper, but not the evidence that it complies. A bespoke tool that touches patient data or financial reporting puts you in a vendor’s position, without spreading the cost across other customers.

None of this argues for buying by default again. It argues for choosing deliberately.

Sameness or fit: a practical test

The useful question is no longer what building costs. It is whether this capability gets its value from being the same as everyone else’s, or from fitting you exactly.

Capability Where the value comes from Lean
General ledger, tax, payroll rules Sameness: auditors and regulators expect a standard Buy
Payments, identity, access control Sameness: interoperability and security guarantees Buy
Fraud, benchmarking, threat signals The network: data pooled across many customers Buy
System of record for customers or orders Mixed: shared data model, local workflows Buy the core, build the workflows
Internal approvals, reporting, ops tooling Fit: it mirrors how your teams actually work Build
The workflow that sets you apart from competitors Fit: it is the advantage Build and own

Two checks apply to every row. First, decide who will own and maintain each thing you build after launch. Second, make sure you can take your data with you from everything you buy. Teams that do both can move a capability from one column to the other later.

The new question

Since the mid-1980s, build versus buy has mostly been a question about cost, and firms have moved steadily toward buying. AI has not reversed that answer. It has changed the question.

The new question is where sameness should live, and where fit should live.

Products will keep winning where sameness is the point: shared rules, shared data, shared trust. Fit becomes the customer’s to build, and it is cheaper than it has ever been.

The products under real pressure are the ones in the middle. They sold generalization as a substitute for fit, and their customers can now get fit directly.

Sources