Building or Buying - A guide to making the right choice for your business

Here's how to decide what to build, what to buy, and why owning your data and workflows is becoming a competitive advantage.

If you run an enterprise resource planning system, you are only using a fraction of what you bought. Studies disagree on the exact figure: somewhere between a fifth and a half is the honest range. But no serious source puts average utilization above the middle of it. The rest sits there, licensed and unused, billed on the same invoice as the part you actually touch.

And here, the number worth pausing on: in large ERP projects, the bucket consultants call RICE reports, interfaces, conversions, and enhancements routinely runs to sixty or seventy percent of the first-year spend. That is not the license, rather it is the cost of bending a generic platform until it behaves like your business. And it is the part nobody negotiates, because by the time anyone quantifies it, the decision has already been made.

A little shelf-ware would be an unremarkable inefficiency. The real problem is the second-order cost, because the unused portion isn’t inert:

• Employees get trained on modules they’ll never open.

• Upgrade cycles drag those modules along whether anyone uses them or not.

• Integrations get built and maintained to connect features that duplicate things.  

• Configuring the platform match your business eats a share of the budget that surprises most executives when they finally see the line item.
  

The pattern is depressingly consistent: a company buys on the strength of a demo, discovers over the next eighteen months that the platform assumes a business somewhat unlike its own, and pays to close the gap through customization. Then, three or four years on, it gets a notice that the vendor is shipping a major version. All those customizations will need to be redone for migration.

The premise nobody examined

The enterprise software industry was built on a quiet assumption: the sensible way to run a business is to find the software that nearly matches how you operate, then adapt your business to the difference. For thirty years that wasn’t so much accepted as unavoidable: building a system to match the business required an engineering effort only the largest firms could fund. But a mid-market company never faced a real ‘build vs. buy’ decision. It only faced a ‘which one to buy?’ decision.

SAP, Oracle, Microsoft, Infor, NetSuite are genuine engineering achievements. Each encodes decades of business logic and regulatory coverage no single company could reproduce. But what they encode is the median business in an industry. The closer you sit to that median, the better the fit. The further you sit, and any company with a defensible competitive position sits some distance away, as the distance makes the position defensible, the more you spend bending your work for the software. The compromise lands heaviest exactly where your business is most distinctive. Which is to say, exactly where you can’t afford to be generic.

What changed?

Two developments, arriving within a few years of each other, rewrote the math.

Reusable accelerators

The slow maturing of reusable accelerators was unglamorous: pre-built modules for the standard machinery of a business, like order-to-cash, record-to-report, inventory, procurement, and HR. Any firm with a deep accelerator library doesn’t start from nothing. It assembles a working foundation and builds only the twenty or thirty percent that’s specific to the client. Over a decade, that pulled custom-build timelines from roughly eighteen months down toward seven or eight.

AI-generated system design

AI became capable of doing the part that stayed stubbornly manual: taking a thorough description of how a business runs today and generating a future-state system design from it. It goes beyond chatbots to a model seeded with operating patterns, industry practice, and a long history of prior implementations, asked to turn an as-is process map into a tailored architecture. Done well, the generation step now takes days instead of months.

Together, accelerators and AI have brought a full custom build to roughly four months and a five-year cost of ownership on the order of sixty percent below a comparable off-the-shelf implementation. Treat that number with caution, it depends heavily on the comparison. But it has held up across implementations worth watching.

One important caveat: a system can be generated in days, but it cannot be deployed in days. Migrating data takes time. Getting people to trust a system they didn't grow up with takes the most time, and it’s the part the technology helps with least. The four-month figure is a deployment window, not code.

Ask the right question first

The standard ERP evaluation opens with the wrong question: ‘which system should we choose?’. That phrasing has already conceded the point. It assumes the answer is one of the vendor platforms and sends your team into feature comparisons and reference calls useful for selecting among options. It is useless for deciding whether the category is even right.

The better question is: ‘what does the business actually need the system to do?’ described in your own terms and in the order things actually work. Companies that run this exercise usually find two things at once. Their real functional footprint is narrower than any commercial platform’s feature list. And the functions that matter most to how they compete: pricing, fulfillment, customer relationships, owner reporting, are the same functions where a generic platform demands the heaviest customization. That overlap isn’t a coincidence. Distinctiveness and poor fit are the same property seen from two angles.

The competitor test

There’s a blunt test that does most of the work: for any system you’re considering, would it bother you to learn a direct competitor ran exactly the same thing?

For payroll, tax, benefits administration — no. You wouldn’t lose a minute of sleep over a competitor using the same payroll engine. Buy those, integrate them, stop thinking about them. For the systems where the answer is yes—where a competitor running your software would mean a competitor running your way of operating; you are looking at something you should own rather than rent.

Understanding the build/buy line

‘Build or buy’ is not one decision. It is a portfolio of them, and the recurring error is treating the whole ERP question as a single purchase.  

You should build anything that touches the operating model. Generic systems approximate that work rather than express it, and approximation degrades. The team starts working around the parts that don't fit, the system drifts out of step with how the business runs, and the gap quietly fills with spreadsheets nobody admits maintaining.  

And buy anything whose value is keeping pace with an external regulatory clock. Avalara and Vertex employ people whose only job is tracking tax-code changes down to the municipal level; recreating that isn't ambition, it is wasteful. The same logic applies for payroll (ADP, Gusto) and benefits (Guideline): where the value is a network you can’t otherwise reach, like a payment rail or carrier ecosystem, you buy the access and build the surrounding workflow.

Before committing either way, run the five-year cost of ownership properly; including the costs that never appear in the proposal: the license multiplied across the term, implementation and integration fees, customization, the recurring tax of maintaining those customizations against every upgrade, and the opportunity cost of paying for a platform you use a third of. Then ask your prospective vendors what their last few major upgrades cost existing clients. That number is rarely in the deck, and it’s frequently the one that decides the question.

The factors  that never makes the scorecard  

There is a dimension that almost never shows up in an evaluation framework and may matter more than anything that does: ownership of the IP and the data underneath it.

License an ERP and your data lives on the vendor’s infrastructure. Reaching it at scale runs through their API; moving it requires their cooperation; building on it requires their permission. When the relationship ends, your choice or theirs, through acquisition, a pricing change, or a sunset product, what you get back is a file. Build the system and the code, data, and operating logic are yours.

This has gotten sharper as companies try to put AI to work. An agent or automated workflow is only as good as the data it runs on. A company with clean, structured, owned operational data can build agents that automate real work; a competitor reaching the same data through a vendor API (shaped for the vendors data model rather than its own) cannot move as fast or as far. The accumulated record of how a business operates is becoming one of the more durable competitive assets a company holds, and handing custody of it to a software vendor is a choice whose cost arrives later than the decision.  

And its ownership shows up at the point of sale, too. Technology you own is a balance-sheet asset that can be valued, transferred, and run by an acquirer on its own terms. Licensed software is a cost the buyer inherits, visible in both the multiple and the integration headache. And there is plain vendor risk: enterprise software companies get acquired, sunset products, revise pricing, and force reimplementation on schedules set without reference to your interests.  

Where the case is weakest?

It would be dishonest to lay all this out without being equally direct about where the custom path is genuinely harder.

The reference base is thin: a firm building custom operating systems this way has done a few dozen, not a few thousand. A buyer reassured by long incumbent client lists will not find an equivalent. The honest response isn’t to pad the list. It is to review the contract: a fixed price, a money-back provision tied to a four-month delivery, and code written in ordinary constructs with nothing proprietary, so any competent developer could maintain it if the original firm vanished. The short delivery window is itself protection: you learn within two months whether it’s working, looking at the actual system rather than a status report.

Change management is the hard part. This is where the custom path is least proven and where success is most often decided. There are builds where every subject-matter expert signed off, the soft launch went live, and the organization quietly revolted. When rollouts that should take three months stretching past a year with half the users still refusing, the technology is rarely the problem. What separates fast adoptions from slow ones is whether leadership commits to the change before the build begins, rather than hoping the organization agrees afterward. Be honest with yourself about which describes your culture before signing anything.  

The shift for the future  

The subscription-software model was a real advance. It put capable systems within reach of companies that could never have built or maintained their own, and for two decades it created enormous value. But it also created dependencies that look more conspicuous as the stakes of AI adoption rise.

The companies best positioned now own their data, control their workflows, and can build on their own foundation without asking permission. The most exposed are those whose operational intelligence is scattered across a dozen licensed platforms, reachable only through interfaces they don’t control.

Everything rests the fact that the economics now enables a build or buy choice. And the competitive cost of getting it wrong is compounding in a way that will be plain within a few years. The companies handling this well aren't the largest ones with the most elaborate IT functions. They’re the ones whose leadership asks what the business needs the system to do before asking which system to buy, andlets the rest of the decision follow from the answer.