Build or buy is the first real software decision a growing enterprise makes, and it’s the one most often made for the wrong reason. Teams reach for off-the-shelf because it’s fast and cheap to start, or for custom because it feels more “serious” — when the decision should turn on a single question: does this capability differentiate your business, or not?
Get that question right and the economics, the risk, and the roadmap all fall into place. Get it wrong and you either pay forever for a generic tool your team routes around, or you burn a custom-build budget on something you could have bought for a fraction. This is a build-vs-buy decision framework for mid-market enterprises — the honest version, including when not to build — with the CFO-readable economics underneath it.
The Real Question Isn’t Custom vs Off-the-Shelf
Off-the-shelf software (COTS) is built for a broad audience and optimized for the average case. Custom software is designed around your operations. Neither is universally better — they solve different problems. The mistake is framing it as a preference (“we like owning our stack”) or a budget line (“custom is expensive”) instead of a strategic one.
The strategic frame is differentiation. If a capability is how you compete and win — the workflow, the customer experience, the data advantage that makes you you — then molding it to a generic product means competing on someone else’s terms. If a capability is table stakes that every company needs and no customer rewards you for doing differently, building it custom is a waste of scarce engineering budget. Everything else in this decision is downstream of that.
The Build-vs-Buy Decision Framework
Run each capability through this before you spend a rupee, dollar, or dirham.
- The capability is a commodity, not a differentiator
- A mature product covers 80%+ of your needs
- Your requirements are conventional, not unusual
- Speed and low upfront cost matter most right now
- The problem is one thousands of firms have already solved
- The process is a source of competitive advantage
- Off-the-shelf forces you to change how you operate
- Deep integration or data ownership is essential
- Per-seat licensing punishes you as you scale
- Your workflow is genuinely different from the norm
One test cuts through all of it: does this capability differentiate us? If yes, lean build. If no, lean buy.
When Off-the-Shelf Is the Right Call
Let’s be honest about this, because credible advice cuts both ways. For commodity functions — email, accounting, payroll, standard HR, conventional CRM — off-the-shelf almost always wins. The market has converged on good answers, the products are mature and maintained by the vendor, and you inherit the accumulated problem-solving of every other customer. Building these custom means paying to reinvent a solved problem and owning its maintenance forever. If a packaged product covers most of your needs without forcing awkward process changes, buy it and move on. Save the engineering budget for where it actually matters.
When Custom Wins for Mid-Market Enterprises
Mid-market companies hit the custom threshold for a specific reason: they’ve grown past the generic tools that served them early, and those tools now constrain them. The signals are consistent — the workflow is genuinely different from the market norm, off-the-shelf forces expensive workarounds, integration across systems is a first-class need, or the process in question is precisely what wins business. When the way you operate is your edge, bending it to fit a generic product hands that edge back. Those are the same symptoms of outgrowing your software — when the team is building spreadsheet workarounds around a tool, the tool has become the constraint.
The CFO-Readable Economics
The build-vs-buy argument usually stalls on “custom is more expensive.” It’s more expensive upfront and frequently cheaper over time — which is why the only honest comparison is total cost of ownership, not sticker price.
| Cost dimension | Off-the-Shelf | Custom |
|---|---|---|
| Upfront cost | Low — subscribe and go | Higher — you fund the build |
| Ongoing cost model | Recurring subscription, forever | Lower, predictable maintenance |
| Cost at scale | Climbs with every seat added | No per-seat multiplier |
| Customization | Limited; add-ons cost extra | Built to fit; no workarounds |
| Switching / lock-in | High — data and process trapped | You own the code and data |
| Balance sheet | Operating expense you rent | An asset you own |
The pattern the numbers reveal: off-the-shelf optimizes the first year, custom optimizes the fifth. A subscription is cheap to start and never stops — and it grows with your headcount, so the tool gets more expensive precisely as you succeed. Custom front-loads the cost into a one-time build, then carries a lower, predictable run rate with no per-seat tax, and leaves you owning an asset instead of renting one. The more users you add and the more differentiated the capability, the sooner the TCO lines cross in custom’s favor. For a commodity function at small scale, they may never cross — which is exactly why the differentiation test comes first.
Weighing a custom build?
Our custom software development team helps mid-market enterprises scope the differentiating capability, model the TCO honestly, and build only what earns its place.
It’s Rarely a Pure Binary
The sharpest teams don’t choose build or buy for the whole business — they choose it per capability. Between the two extremes sit the options that usually win in practice:
- Configure or extend. Buy a mature platform for the base, and build only the differentiating extensions on top of it.
- Buy the commodity, build the core. Compose off-the-shelf products for everything that doesn’t differentiate you, and spend custom-development budget only on the capability that actually wins business.
Both follow the same discipline: spend custom effort only where it creates advantage, and buy everything else.
The Other Decision: Who Builds It
Once you’ve decided to build, a separate question follows — build with your own team, hire, or engage a partner. That capacity decision has its own framework, which we cover in build vs hire vs partner for mid-market CTOs. And if you go the partner route, vetting them well is its own discipline — our 12 questions to ask before you sign with a software development partner is the companion to this piece. Build-vs-buy decides what to build; those two decide who builds it and how you choose them.
Conclusion: Differentiation Decides
Custom software isn’t better than off-the-shelf, and off-the-shelf isn’t cheaper than custom once you count the whole bill. The right choice falls out of one question asked capability by capability: does this differentiate us? Buy the commodity, build the difference, model the TCO honestly rather than on the sticker price, and reserve your scarce engineering budget for the software that actually wins you business. For mid-market enterprises that have outgrown their generic tools, that discipline is what turns software from a cost center into a competitive advantage.
Figure out what to build and what to buy
Bring us the capability you're weighing. We'll run the build-vs-buy framework, model the total cost of ownership, and help you invest custom development only where it pays off.
