Architecture Files #30 · Part of Binary and Beyond. LinkedIn newsletter edition follows.
Build versus buy is a meeting that feels decisive and often decides nothing useful.
One side wants control, differentiation, and "we can make it fit." The other wants speed, a vendor roadmap, and "we should not reinvent this." Slides appear. Total cost of ownership models get optimistic. Someone picks a winner. Eighteen months later the organisation is still paying for the same pain: change is slow, ownership is fuzzy, and the system does not move at the pace the business needs.
The binary was the wrong frame. The real question is which risks, capabilities, and change costs you want to own versus rent. Build and buy are delivery modes. They are not strategies for what you are accountable for when the business shifts.
The platform that was "bought" and still felt built
Picture a mid-market operator that bought a packaged suite for orders, inventory, and billing because building would take too long.
Year one looks like a win: go-live, training, green status reports. Year two, every regional exception becomes a configuration project. Year three, "configuration" includes custom code on top of the package, shadow spreadsheets beside it, and a small internal team that exists only to translate vendor releases into local reality.
They bought the license. They still own the integration debt, the exception logic, the reporting gaps, and the political cost of saying no to a sales promise the package cannot keep. The buy decision did not remove ownership. It relocated where ownership is exercised and made some of it harder to see.
The opposite failure is familiar too: a team builds a commodity workflow because vendors felt constraining, then spends years staffing a problem the market already solved, while the differentiating product work waits.
Both failures share a root. The debate named the procurement verb and skipped the ownership portfolio.
What you are actually choosing
Every software decision places three kinds of burden somewhere: on your payroll, on a vendor invoice, or in an unowned gap that becomes incident theatre.
Risks. Who absorbs outage risk, compliance risk, roadmap risk when a regulation changes, concentration risk if the vendor pivots or sunsets a module? Buying does not delete risk. It converts engineering risk into vendor and contract risk, plus the residual risk of whatever you still glue around the edges.
Capabilities. Which abilities must stay sharp inside the company because they are how you compete: pricing logic, fulfilment promises, underwriting rules, customer-specific workflows? Which abilities are fine to rent because they are table stakes: identity plumbing, email delivery, generic CMS, commodity HR flows?
Change costs. When the business wants a new exception next quarter, who pays in calendar time: your team changing code you own, a vendor ticket queue, a systems integrator, or a brittle workaround that never enters the architecture diagram? The Economics of Technical Debt frames debt as unpaid options on future change. Build versus buy is often an argument about where those options live and how expensive they are to exercise.
If you cannot say which risks, capabilities, and change costs you intend to own, "build" and "buy" are labels on an empty box.
Why the binary debate persists
It maps cleanly to budgets and org charts. Capex versus opex. Headcount versus license. Architecture board versus procurement.
It also flatters both tribes. Builders get to talk about craft and control. Buyers get to talk about focus and speed. Neither has to inventory the seams, the exceptions, or the people who will still be needed after the decision.
Why Enterprise Software Feels Slow (and Why That's Often Correct) argued that slowness often comes from real coordination and risk, not only from bad engineers. The same lens applies here. A buy can be slow because contracts, integrations, and exception governance are the work. A build can be slow because you took on change cost you did not staff. Speed fantasies on either side are how programmes get green until they are not.
Why CRUD Stops Scaling Before Databases Do is a reminder that "we already have tables for this" is not a capability strategy. Commodity storage is easy to own. Business workflow differentiation is not the same as having rows.
A mental model: own, rent, or explicitly decline
Replace build/buy with a three-way portfolio for each capability slice:
- Own: you staff the skill, you control the change path, you accept the incident and roadmap burden because the capability is strategic or too entangled to rent safely.
- Rent: you pay a vendor (or a platform team) for a bounded capability, you accept their change cadence, you invest in contract, integration, and exit options instead of feature code.
- Decline: you refuse to pretend the capability exists as software yet. Manual process, narrower product scope, or "not this year" beats a fake system that creates false confidence.
Most painful estates are full of accidental owns: customisations on bought suites, home-grown tools for commodity problems, and critical spreadsheets that are owned by nobody on the org chart. Accidental owns are how buy programmes recreate build cost, and how build programmes recreate vendor-shaped neglect (no roadmap, no docs, one maintainer).
The useful executive question is not "should we build or buy X?" It is "for X, which of own / rent / decline matches our strategy, and what residual work does that choice still leave us?"
How this shows up in modernisation
On legacy application modernisation programmes, the productive cut is rarely "replace everything with a package" or "rewrite everything in-house." It is separating strategic ownership from rented commodity, then paying down the accidental owns that tax every release.
Sometimes the right move is to keep a bought core and rewrite the exception layer you actually compete on. Sometimes it is to extract a built capability into a product boundary and stop treating a vendor module as infinitely configurable. Sometimes it is to decline a workflow softwareisation that only exists because a slide promised "automation."
Modernisation fails when it inherits the binary: big-bang buy, or multi-year rewrite, without a portfolio of what must remain owned.
Implications for how you decide
Run the decision as an ownership design review, not a tribal vote.
That means:
- Slice the domain. Orders is not one decision. Pricing rules, tax, fulfilment promises, and invoice presentation might land differently.
- Name residual work for both options. Buy still needs integration, data contracts, exception handling, reporting, and exit planning. Build still needs product management, support, security, and a roadmap that survives the first launch.
- Price change, not only launch. The second year of exceptions is usually the real bill.
- Staff the seam either way. Unowned integration between a package and your world is how "we bought it" becomes "we accidentally built a second system."
- Write an exit or rewrite trigger. Vendor lock and internal lock both get expensive when nobody predefined the off-ramp.
Also be honest about differentiation theatre. Not every custom request is strategic. Some are preferences that should lose to a standard. Buy programmes die when every preference becomes a customisation. Build programmes die when every commodity becomes a craft project.
Questions that replace build vs buy
Use this in the architecture board before anyone opens a make-or-buy slide.
- Which risks must we keep on our balance sheet of attention (compliance, uptime, roadmap, concentration), and which are we willing to convert into vendor and contract risk?
- Which capabilities are how we compete next year, and which are table stakes we should rent or decline?
- When the next exception arrives, who pays in calendar time under own versus rent, and is that team actually staffed?
- What residual systems will we still own after a buy (integrations, reports, overlays), and are they funded as products?
- What would we stop doing if we decline this as software for now?
- What trigger forces a revisit: volume, regulation, vendor direction, cost of change crossing a line?
- If we choose rent, what is our exit sketch? If we choose own, what is our boring-operations plan after launch?
If the room cannot answer these, it is not ready to choose a vendor or a repo. It is still discovering what it is trying to be responsible for.
Fingerprint
Build versus buy survives as a debate because it is easy to schedule and hard to falsify in a meeting.
Strategy shows up in the ownership portfolio: which risks you carry, which capabilities you keep sharp, which change costs you staff, and which work you explicitly decline. Delivery mode follows that. When delivery mode comes first, you get packages that behave like unfinished internal products, or internal products that behave like neglected vendors.
The organisations that move cleanly are not the ones that always build or always buy. They are the ones that can say, slice by slice, what they are on the hook for when the business changes.
Do not ask only whether to build or buy.
Ask which risks, capabilities, and change costs you intend to own, rent, or decline. Then pick a delivery mode that matches.
Related reading
- The Economics of Technical Debt
- Why Enterprise Software Feels Slow (and Why That's Often Correct)
- Why CRUD Stops Scaling Before Databases Do
Architecture Files #30 · Part of Binary and Beyond. LinkedIn newsletter edition follows. Designing an own-versus-rent portfolio instead of a proxy build/buy fight? Start a conversation.