Build versus buy is having a moment, and almost none of the conversation is useful if you run a mid-sized company.
The version getting written about is an enterprise story. A company with two hundred engineers on staff looks at eight figures of annual software licensing, decides it can do better internally, and builds. That’s a real decision with real logic behind it. It’s also completely inapplicable to a $60 million distributor with an IT director, two analysts, and a managed services contract.
The mid-market version of this question is different, and it’s more interesting, because the constraint was never really the one people name.
The objection that actually stops these projects
Ask a mid-market company leader why they haven’t built something custom and you’ll usually hear that it was too expensive. Push a little further and a second answer appears, which is the one that was actually doing the work: and then we’d have to own it.
That’s the real objection, and it has always been more rational than the cost objection. Buying software means someone else employs the team who maintain it, patches it, handles the security advisories, and keeps it running when a dependency deprecates. Building means all of that becomes yours, permanently, with a team that doesn’t exist.
The standard build-vs-buy analysis quietly assumes an engineering organization is standing by. Most mid-market companies don’t have one and shouldn’t build one. Which is why “build” tended to get dismissed before the conversation reached the merits.
So the useful question isn’t whether building got cheaper. It’s whether the ownership burden got smaller. And that one has a more interesting answer.
What genuinely changed on the ownership side?
Two things, neither of which is AI.
#1 – Most of what you used to maintain, you no longer run. A custom application ten years ago meant servers, an operating system, a database you patched, a backup regime someone checked. Today an equivalent application runs on managed services where the provider handles the layer that generated most of the operational work. The surface area you actually own shrank considerably, and the part that remains is mostly your own business logic.
#2 – Apps can be smaller. Not simpler to design – smaller in scope. Focused applications that do one thing – rather than an entire platform. A smaller thing has less to maintain, by definition.
Combine those with the reduction in build cost, and a category of project that was correctly rejected for a decade is now worth a second look. Not because the analysis changed. Because the inputs did.
When buying is still obviously right:
It’s worth being direct about this, because a vendor arguing that everything should be custom isn’t giving you advice.
- Buy when the category is genuinely commodity and your version of it isn’t special: payroll, accounting, email, expense management, helpdesk ticketing.
- Buy when the product has a large installed base and a real roadmap, and your requirements sit comfortably inside it.
If the process isn’t a source of advantage for you, buy it. Nobody has ever won a customer because their general ledger was bespoke.
The situation where buying quietly fails:
The interesting case isn’t buy-versus-build. It’s what happens when you bought something that fits most of the way.
Almost every mid-market company has at least one system that fits about 70%. The system works. Nobody would call it a failure. And around it with a set of workarounds and hacks.
When people say build-vs-buy, they’re usually imagining a replacement decision — rip out the 70% system, build something that fits 100%. For most mid-market companies that’s the wrong project: expensive, disruptive, and it puts you back in the ownership problem at full scale.
The option nobody offers you
There’s a third answer that’s usually the right one, and it’s rarely on the table because it doesn’t suit anyone’s business model. Your incumbent vendor wants a bigger contract. A development shop wants a bigger build. Neither one benefits from proposing something small.
Keep the system of record. Build where the gap is.
The ERP stays. The CRM stays. What gets built is the specific thing closing the specific gap – the integration that eliminates the re-keying, the portal that answers the question your account managers answer forty times a week, the interface that generates a better report.
These projects are bounded, they have a measurable before-and-after, they don’t put a core system at risk and the maintenance requirement is low.
Four questions that resolve most of these decisions
- Is this process a source of advantage, or just necessary? Necessary means buy. Advantage means look harder at building.
- What is the gap costing annually in labor? Count honestly, including senior people handling exceptions. If you can’t name the number, that’s the first piece of work.
- Do we have to replace anything to fix this? If no, the project is far smaller than it appears and the risk profile is different.
- Who maintains it in two years? If there’s no credible answer, the project isn’t scoped correctly yet – and that’s a scoping problem, not a reason to stop.
The last question is where most of these decisions are genuinely won or lost, and it’s the one that gets asked least.
The part that didn’t get cheaper
None of this makes the decision automatic. Production cost came down sharply; judgment cost didn’t move at all. Knowing which of your systems to leave alone, which gap is worth closing first, and what the thing you build has to survive in three years — that’s still expensive, still scarce, and now represents a much larger share of what a project actually costs.
This is roughly why a distinction has started to appear in how these projects get delivered. Descriptions vary, but the common thread is some version of guided AI: senior engineering judgment sets what gets built and in what order, guardrails inside the process govern how it’s built, and decisions stay traceable end to end. The alternative — pointing an autonomous tool at the problem — is fast, and produces systems nobody can maintain, which lands you right back at the ownership objection you started with.
Buy the commodity. Build the advantage. Layer the gap. And be honest about who owns it afterward.
Learn more about Guided AI approach to building software for enterprises and startups.
