Build vs Buy Software: Why It's Really a Three-Way Choice

Sit in the room where this actually gets decided and the question sounds simple: do we build it, buy it, or keep what we have? A system that runs part of the business — billing, underwriting, claims, fulfilment, the thing customers touch — is aging past comfort. Finance wants a number. Engineering wants to stop firefighting it. Someone frames it as “build versus buy,” a whiteboard gets a line drawn down the middle, and the debate starts.

That line down the middle is the first mistake.

This series is about making this decision honestly, and it reads in order. This first part is the frame — the paths that are actually on the table and what each is genuinely for. It does not tell you which is cheaper or hand you a scoring sheet; those come next, and they only work once the framing is right. Get the frame wrong and you will run precise math on the wrong set of options — which is the most expensive way to be wrong, because it looks rigorous the whole way down.

Why “build vs buy” is the wrong frame

The two-way framing carries a hidden assumption, and the assumption is usually false. Both “build” and “buy” quietly assume that the system you are replacing is disposable — that its behavior is understood well enough to reproduce somewhere else, so the only real question is whether you reproduce it or a vendor does.

For a greenfield capability you have never had, that assumption is fine. There is nothing to preserve, so build-or-buy really is the whole decision. But that is not the situation most leaders are actually in when this comes up. The system on the table already works. It has run the business for years. And in doing so it has absorbed thousands of rules, exceptions, and “we always do it this way for this account” decisions that live nowhere except the code and a few people’s heads. That accumulated behavior is not overhead. For the systems that matter, it is the business.

Here is why that matters concretely. When a team says “buy,” they picture a clean swap: turn off the old thing, turn on the new thing. What actually happens is that the new package does 80% of what the old system did out of the box — and the missing 20% is precisely the part that made the old system yours. That 20% becomes a customization backlog, a data-migration project, and a parallel-run period where the business quietly discovers all the rules nobody remembered until the new system got one of them wrong. “Buy” did not remove the hard part. It relocated it, and stripped away the working reference implementation that would have told you what “correct” looked like.

“Build” has the mirror problem. The blank repository feels like freedom, but every one of those undocumented rules now has to be re-derived, argued about, and re-implemented — under a deadline, without the person who wrote the original in 2011, and with production as the place you find out what you missed.

So the moment there is a working system in the picture, “build or buy” has silently deleted the option that keeps that reference implementation alive: modernizing it. Leaving it off the whiteboard is not a simplification. It is a decision made by omission — and, as we will see, it is the omission that has no one in the room whose job is to object to it.

The real choice, whenever there is an existing system worth talking about, is three-way: build, buy, or modernize.

The three paths — and what each is genuinely for

Each path is a right answer to a different question. The skill is matching the path to what the capability actually is, not to which option is loudest in the room. Take each in turn, with the situation it is actually for.

Build: when the software itself is the advantage

Build is the right call when you need something genuinely new that no product offers and that the business competes on. Here, building is the point — the software is a source of advantage, not a cost to minimize.

Picture a logistics company whose entire edge is a routing model that schedules drivers better than anyone else in its region. No off-the-shelf product encodes that model, and if one did, the company’s advantage would evaporate the moment a competitor bought the same license. That is a real build: the capability does not exist as a product and owning it is the moat. Building it is not an expense to avoid; it is the reason the company wins.

The trap is misjudging “new.” A great deal of what teams are itching to build is a commodity wearing a fresh coat of paint — an internal chat tool, another dashboard framework, a homegrown auth system, a bespoke feature-flag service. A greenfield build of undifferentiated software is simply how you manufacture a brand-new legacy system three years from now: it launches to applause, then becomes the two-person maintenance tax nobody wants to own, perpetually behind on the edge cases and compliance that mature products handle for free. Build when the thing genuinely does not exist and genuinely matters. Otherwise you are paying to reinvent a wheel you could have rented.

Buy: when the capability is a commodity

Buy is the right default for commodity capabilities — functions that look essentially the same across your whole industry, where a mature product almost certainly does the job better than anything you would build. Payroll, email, expense management, generic CRM and ERP modules, identity and single sign-on, standard document storage, observability: the vendor spreads development across thousands of customers, maintains it, patches it, and keeps it compliant while you sleep.

The economics are lopsided for a reason. A payroll vendor employs specialists who do nothing but track tax-table changes across every jurisdiction you operate in. You cannot match that with a fraction of one engineer’s attention, and you should not try. Hand-building or hand-maintaining software for these functions is the classic waste — you take on the cost and the maintenance forever to reproduce something you could license for a fraction of it. Buy the plumbing. Nobody wins on plumbing, and the effort you sink into owning it is effort stolen from the work customers actually pay you for.

The one thing to check before buying is fit at the seams: a bought product that needs to be bent hard to match a process you refuse to change is not really “buy” anymore — its economics quietly slide toward the build column, and it belongs in the reversibility conversation in Part 4. If the process is context, change the process to fit the product. If the process is core, you may be looking at the wrong product — or at a different path entirely.

Modernize: when the system already knows something

Modernize is the right call when a working system already encodes differentiating logic — the accumulated, often undocumented rules that make your pricing, your underwriting, your claims handling, or your fulfilment work your specific way.

Consider a mid-size insurer’s rating engine (an illustrative composite, but a familiar one). Twenty years of underwriting judgment is fossilized in that code: how a particular class of risk is priced, which combinations of factors trigger a manual review, the special handling for a book of business acquired in some long-ago merger. None of it is written down as requirements. It exists as behavior. That tribal knowledge is the asset — and it is the one thing both building and buying throw away.

A new build has to re-derive every one of those rules. A bought package has to be bent, customized, and integrated until it can approximate them. Either way you are betting a fresh system can re-earn, under deadline, everything the old one already knows — the same bet a full rewrite makes, and a large part of why so many transformation projects fail to deliver on their objectives. Modernizing starts from the working behavior and carries it forward onto a current stack, so the knowledge is preserved rather than rediscovered in production. When the embedded logic is genuinely the value, modernize is not the timid option — it is the only path that does not begin by setting fire to the asset.

Put the three side by side:

Path	Best when the capability is…	The trap	You are betting that…
Build	Genuinely new and something you compete on	Building a commodity with a coat of paint	The thing truly doesn’t exist as a product
Buy	A commodity every company in your industry needs	Bending the package to a process you should keep	A little standardizing beats a lot of customizing
Modernize	A working system whose embedded logic is the asset	Treating a real differentiator as disposable	Preserving known behavior beats re-deriving it

Core vs context: the question underneath the question

There is an older, cleaner way to say all of this, and it predates the current debate. Geoffrey Moore’s distinction between core and context asks one thing: is this capability part of how you compete, or is it plumbing that every company in your industry needs but nobody wins on? Core is what customers would notice if it were worse than a rival’s. Context is everything else that simply has to work.

The rule that falls out of it is short. You buy context. You build or modernize core. Buying context frees your best people from maintaining undifferentiated software so they can spend their time on what customers actually pay you for. Building or modernizing core keeps the thing you win on under your own control instead of a vendor’s roadmap. Most of the expensive mistakes in this whole category are a core/context mix-up: buying a package for something that turned out to be core and spending years fighting it, or building something that turned out to be context and paying a permanent tax to own it.

The hard part is that “core” and “context” are not obvious from the outside, and they drift over time — yesterday’s differentiator becomes today’s table stakes. So test it deliberately. A capability is closer to core the more of these are true:

• A customer would notice, and care, if it were merely as good as a competitor’s rather than better.
• If it stopped improving for two years, you would start losing deals.
• You would hesitate to describe exactly how it works to a competitor.
• The value lives in the specific rules, data, or judgment it has accumulated — not in the generic function it performs.

And it is closer to context the more of these hold:

• Every company in your industry needs essentially this same thing.
• Several mature vendors already sell it, and their versions are broadly interchangeable.
• “Better” would not win you a single customer; only “reliable and compliant” matters.
• You could hand a competitor a full description and give away nothing.

Run a capability through those and the path usually declares itself. Pure context: buy. Pure core with nothing built yet: build or partner. Core that already lives in a working system: modernize. The interesting cases are the ones that split — a commodity base with a differentiating edge on top — and those point to the hybrid paths below rather than to any single column.

Notice that core-versus-context is not a question about the whole company. It is a question about one capability at a time — which is the thread that runs through the rest of this series.

“New to us” is not “new to the world”

The single most expensive framing error inside the build decision is confusing new to us with new to the world. A capability your company has never had feels novel, and novelty feels like a reason to build. But “we don’t have it yet” says nothing about whether a product already does it well. Most of what a growing company lacks is not genuinely new — it is standard capability the company simply hasn’t bought yet.

Two quick tests cut through it. First, name three vendors who sell something adjacent. If you can rattle them off, the capability is almost certainly context, and the build instinct is really an instinct to have it exactly your way — which is a customization requirement, not a novelty one. Second, separate the capability from the configuration. Very often the capability itself is a pure commodity (a workflow engine, a document store, a scheduler) and only the rules you feed it are special. When that is the situation, the answer is rarely a from-scratch build; it is buying or modernizing the commodity engine and keeping your rules as your own — the buy-then-extend and modernize patterns the later parts get into.

The reason this matters at the framing stage is that “we can just build it” is more available than ever. AI-assisted development made writing code faster and cheaper, so the typing part of a build looks trivial — which makes it dangerously easy to greenlight builds of things that are context. But a build was never mostly typing. It was specification, edge cases, security, integration, and the decade of maintenance after launch, none of which got cheaper. The cost curve of a build is largely unchanged; only the most visible, least expensive part of it moved. Treat “we can build it faster now” as true and almost entirely irrelevant to whether you should. (Part 2 puts real numbers behind exactly this.)

What “modernize” actually is

Because modernize is the path most people have never actually run, it helps to be concrete that it is not one thing — it is a spectrum, from lightest touch to heaviest:

• Refactor — restructure the code without changing behavior, to make it safe to change again. Cheapest; buys you room, not a new platform.
• Re-platform — move the same system onto current infrastructure, runtime, or language with minimal behavior change. Kills the “unsupported and unhirable” risk without a redesign.
• Re-architect — reshape the system’s structure (break a monolith into services, replace a dead UI layer) while carrying the business logic forward.
• Incremental replacement — stand up new components alongside the old system and move functionality across slice by slice, each slice proven to behave identically before the old one is retired.

That last one is what makes modernize competitive with build and buy on risk, not just on cost. Done incrementally, modernization recovers the system’s rules from the code itself and re-implements them one small, reversible slice at a time — each slice proven to behave identically to the legacy before it goes live — rather than betting the business on a single big-bang cutover. The choice between keeping-and-transforming versus ripping-and-replacing is a whole decision of its own; we treat it in depth in Modernize vs Replace, and it is where the series ends up. For now, the point for the frame is narrow: “modernize” is not a synonym for “leave it alone” or “another multi-year rewrite.” It is a real, gradable path with a real risk profile — which is exactly why it belongs on the whiteboard next to build and buy.

The fourth paths are real: partner, white-label, low-code

Even “build, buy, or modernize” understates the options, because build and buy are the ends of a spectrum, not a switch. A lot of the smartest answers live in the middle, and searchers who type “build vs buy vs partner” already know it. Treat these as first-class paths, not fallbacks:

• Partner / co-development. You bring the domain and the differentiating requirements; a specialist builds and often co-owns the delivery. You buy expertise and velocity you do not have to hire permanently, without buying a fixed product that fits someone else’s problem. Right when the capability is core but your team cannot staff it fast enough — a company that needs a differentiating build but has no bench to do it, and no appetite to spend a year hiring one. Wrong when the capability is pure context (just buy it) or so core and so central that you would never want the knowledge to live outside your walls.
• White-label / OEM. You license someone else’s engine — a payments rail, a mapping layer, a document engine, a KYC service — and put your brand and workflow on top. You reach market fast and skip building undifferentiated infrastructure. Right when the engine is context but building it yourself would be a distraction from the actual product. Wrong when the engine is the differentiator, because you have just outsourced your moat to a vendor whose roadmap and pricing now set yours.
• Low-code / no-code. Platforms like Retool, Airtable, Quickbase, or Power Apps let you assemble internal tools and line-of-business apps far faster than a full build. They shine for the context layer — internal workflows, admin panels, approval flows — where speed matters and the app will never leave the building. They become a trap when a genuinely differentiating, high-scale product gets jammed onto them and then cannot grow past the platform’s ceiling, at which point you are rebuilding it for real, a year late, having outgrown the thing that was supposed to save you time.

The best answers are frequently hybrids: buy the platform, partner on the hard slice, low-code the tooling around it, and modernize the core that ties it all together. One important property separates these paths from the pure ones, and it is worth flagging now even though it gets its own part later — how easily you can unwind the choice. A white-label dependency and a from-scratch build fail in opposite ways, and neither shows up in a cost estimate. Reversibility, exit cost, and the buy-then-extend pattern that preserves the most optionality are the subject of Part 4; for the frame, just note that “which path” and “how hard is it to leave” are two different questions, and a path that scores well on the first can be a trap on the second.

The framing mistakes that decide the answer before you do

By the time most teams start scoring options, the answer is already half-decided by how the question got framed — usually without anyone noticing. These are the framing failures that quietly pick the path for you:

Deciding for “the system” instead of per capability. The most common and most costly error. A system is a bundle of capabilities with different core/context profiles; picking one verb for all of them guarantees you buy something that’s core or build something that’s context somewhere in the bundle. The fix is the next section.

Letting the loudest default win. Every function has a reflex. Engineers default to build — it’s the interesting work and it flatters the team’s capability. Finance defaults to buy — it’s a predictable line item and it fits a procurement process. Product defaults to whatever ships fastest this quarter. None of those defaults is about the capability; they’re about the incentives of the person holding the pen.

Modernize has no champion. This is the subtle one, and it is why the third path gets omitted so reliably. Build has engineering behind it. Buy has finance and procurement behind it. Modernize has no natural owner in the room — it’s not a purchase, so procurement isn’t interested; it’s not a shiny new build, so engineering isn’t excited; it looks like “maintenance,” which no roadmap funds. The strongest option frequently loses not on merits but because nobody’s job is to argue for it. If you take one operational habit from this article, make it this: whenever there’s a working system involved, appoint someone to make the modernize case before the framing hardens, or it will be dropped by default.

Confusing “new to us” with “new to the world” — covered above, but it belongs on this list because it’s a framing error, not a scoring one. It biases the whole exercise toward build before a single number is run.

Anchoring on sticker price. The license quote and the “we could build it in a quarter” estimate are the two most visible and least reliable numbers in the whole decision. Build hides its cost in the maintenance tail and opportunity cost; buy hides it in seat growth, integration, and implementation. Framing the choice around the sticker price frames it around the two numbers most likely to be wrong. This is exactly what Part 2 exists to fix.

Treating the decision as permanent. Every one of these paths is also a bet on being wrong, and they cost wildly different amounts to unwind. A framing that ignores reversibility over-weights the cheap-looking option and under-weights the one you can actually back out of. Part 4.

It’s not one decision — it’s one per capability

Here is the single most important thing to take from the frame: this is almost never one estate-wide decision. The teams that get it wrong pick a path for “the system” and apply it uniformly. The teams that get it right run the question — build, buy, or modernize? — capability by capability, and end up with a deliberate blend.

Walk a familiar estate to see how differently the same company should answer for its different parts. Take that mid-size insurer again (illustrative, but the shape is real):

Capability	Core or context?	Path	Why
Payroll, email, expense management	Context	Buy	Commodity; a vendor does it better and keeps it compliant
The rating / underwriting engine	Core, already built	Modernize	Twenty years of pricing judgment is the asset — carry it forward
A new AI-assisted claims-triage tool	Core, doesn’t exist yet	Build or partner	No product offers it; it’s a genuine edge — build it, or partner if you can’t staff it
Customer document generation	Context	White-label / OEM	A mature document engine under your brand beats building one
Internal broker-onboarding workflow	Context	Low-code	Speed matters, it never leaves the building, no scale ceiling in sight

One company, five capabilities, five different verbs — and every one of them defensible. Pick a single path for “the modernization project” and you would have gotten at least three of these wrong: rebuilt a document engine you should license, bought a rating package that can’t hold your underwriting rules, or hand-coded a broker workflow a low-code tool would have shipped in a fortnight.

Drawing that line — which parts are core and which are context, which logic is worth carrying forward and which is worth abandoning — is the actual work. It is why context-specific versions of this exact decision exist on their own: a database platform like Oracle Forms, or a core insurance system, each land differently because the mix of core and context is different. The frame is the same everywhere; the answer moves with the estate.

The rest of this series

You now have the frame: three real paths plus hybrids, matched to whether a capability is core or context, decided one function at a time rather than once for the whole estate, and protected from the framing mistakes that otherwise settle the question before you do. That is enough to stop drawing the wrong line down the middle of the whiteboard. It is not yet enough to choose.

The first question anyone asks is which path costs less — and it is the one you cannot honestly answer without real numbers in front of you. Part 2, Build vs Buy: The Real Cost, puts a genuine total cost of ownership on each path, line by line, across three- and five-year horizons — the maintenance tail that build hides, the seat growth and integration that buy hides, and the incremental spend that modernizing runs against a system already earning its keep.