Custom Software vs Off-the-Shelf: How AI Changed the Math

Buy off-the-shelf software when a vendor spreads its engineering cost across thousands of customers and the product fits how you work. Build custom when the license runs six figures a year, out-of-the-box fit is below about 70%, and the system sits close to how you win. For twenty years the second category was a minority call, reserved for companies with deep engineering benches and high risk tolerance. AI-assisted delivery moved the line. Design, code, and test costs dropped far enough that vertical point solutions, the systems with few vendors and heavy licenses, now clear the build threshold routinely. Commodity tools did not move at all. The decision now runs on category, fit, and ten-year cost, and you can model yours in about five minutes with our build vs buy calculator.

The three regimes of enterprise software

Most build vs buy arguments go wrong because they treat all software as one market. There are three, and they behave differently.

The first is commodity software: email, documents, chat, office suites, basic HR and accounting tools. Vendors amortize engineering across millions of seats, which is why the price lands at $10 to $30 per user per month. That price is not beatable. At 10,000 seats, a $20-per-user tool costs $2.4 million a year, which sounds like a build case until you price what it takes to replicate, secure, and continuously improve a product that Microsoft or Google funds with a nine-figure annual engineering budget. Nobody wins that trade. Commodity software stays bought at any scale.

The second is market-leading platforms: Salesforce-class CRM, SAP-class ERP. The trap here is feature parity. Companies convince themselves they need everything the platform does, then discover that matching a mature product's feature set is a treadmill rather than a project, because the vendor ships faster than an internal team can chase. The right move in this regime is to buy the platform and build only the thin layer that differentiates you, usually around 20% of what you originally scoped.

The third regime is where the change happened: vertical point solutions and true differentiators. Policy administration and claims systems in insurance. Loan origination and servicing in financial services. Manufacturing execution and plant scheduling. These markets have a handful of vendors, licenses that run from the low six figures into the millions, and products built for an average process that fits nobody exactly. Companies have tolerated 50 to 70% fit and heavy per-customer customization because building was riskier. That tolerance is what AI-assisted delivery is ending.

What AI actually changed

Three costs moved. Design and build labor dropped because AI agents now do the repetitive engineering, code generation, migration scaffolding, and boilerplate testing, under senior review. Timeline compressed for the same reason: work that needed a team of twelve for a year is increasingly a team of four for a season. And testing depth stopped being a luxury. Historically, custom projects failed in the edge cases the business could not articulate up front; exhaustive AI-generated test coverage attacks exactly that failure mode.

Be clear about what did not change. Requirements still have to be right, and getting them right is discovery work no model does for you. Data migration still makes or breaks go-live, and the only honest test is running full production data through the new system before cutover. And custom software still needs a support model after it ships, which is where most build business cases quietly fall apart. AI moved the cost curve; it did not repeal the reasons projects fail. Most stalled AI initiatives stall on exactly these fundamentals, a pattern we covered in why AI pilots stall.

The ten-year math

Run the comparison over ten years, because that is roughly the realistic life of both paths, and the shapes differ. Buying starts cheap and compounds: an implementation, then a license that grows 8 to 12% a year in most enterprise renewals, with a step change at the mid-life upgrade. Building starts expensive and flattens: the design-and-build investment up front, then maintenance, infrastructure, and AI token costs that grow with labor inflation rather than with a vendor's pricing strategy.

A worked example at the scale where this decision usually lives: a 500-seat vertical system carrying a $500,000 annual license, a $1 million implementation, and a mid-life upgrade lands around $9 to 11 million over ten years. An AI-assisted replacement built for $3 to 5 million, running at 15 to 25% of build cost per year, lands around $8 to 10 million, and the cumulative lines usually cross between year three and year six. What drives the answer is the license size, the license growth rate, and the run cost you commit to after go-live. Small licenses never cross. Compounding six-figure licenses almost always do.

Those are illustrative ranges, not quotes. The point of the exercise is which side of the line your initiative sits on, and the calculator will show you the crossover year on your own numbers.

What custom software costs in 2026

Custom software development cost used to start around $250,000 for anything serious and climb past $10 million for core systems, mostly labor. AI-assisted delivery compressed the middle of that range. A focused internal workflow application now lands roughly between $150,000 and $600,000. A departmental system with real integrations runs $500,000 to $2 million. A point-solution replacement, a policy administration system, a servicing platform, an MES, typically runs $2 to 6 million depending on integration count and migration complexity. The spread inside each band is driven by three things: how many systems it must talk to, how messy the data being migrated is, and how much of the old system's behavior nobody wrote down.

Two cost lines deserve more scrutiny than they get. First, AI compute is now a real line item: token costs for agentic development during the build, and inference costs in production if the system itself uses models. Second, SaaS-versus-custom comparisons often hide the internal cost of operating the SaaS: administrators, integration upkeep, and the customization backlog. Put both on the table or the comparison flatters whichever side left its costs off.

The run cost is the decision

Every failed custom system we have assessed died the same way: it shipped, the team that built it dissolved, and five years later it was undocumented legacy nobody could safely change. Price the run before you build. A maintained custom system costs 15 to 25% of its build cost per year across maintenance, enhancements, infrastructure, and AI tokens, and it needs that spend under a defined support model with SLAs, not a hero developer. If your organization will not commit to the run cost, buy the product, because an orphaned custom system is more expensive than any license.

When off-the-shelf still wins

Buying wins more often than building, and a fair analysis says so. It wins when out-of-the-box fit is excellent, because heavy customization of a bought product erodes the savings and recreates lock-in. It wins when the timeline is under six months, because a ready product beats any build to market. It wins when internal capability to operate software is thin. It wins when the vendor's compliance posture, SOC 2, HIPAA, FedRAMP, is doing work you would otherwise have to do yourself. And it always wins at commodity per-seat prices. When the answer is buy, the advantage comes from implementation speed and integration quality, which is delivery work we do every week.

How to run the decision

The analysis that survives finance scrutiny has five parts:

• Classify the system: commodity, market platform, or point solution. The category decides more than the spreadsheet.
• Score off-the-shelf fit against requirements ranked by differentiation, and name the 20% actually worth owning.
• Model ten-year cost both ways, with real license growth rates and an honest run cost on the build side.
• Price the risks: delivery, migration, edge-case testing, and what happens if the build team leaves.
• Write the recommendation with the drivers stated, so the decision can be defended and revisited when inputs change.

The math changed in favor of building a specific class of software. It did not change in favor of building everything, and a firm that tells you otherwise is selling you engineering hours. If you are weighing a specific system, start with the build vs buy assessment: run the calculator, then bring the result to a working session and we will pressure-test it against real delivery data.