Insight

Build vs. Buy

When off-the-shelf software starts costing more than it saves, and what to do about it.

StrategyOps
The question every growing team faces

Every growing team hits the same fork

Keep bending a generic tool to fit how you work, or build something that fits the way you actually operate? It sounds like a technology question. It is really a cost question, and most teams answer it wrong because the cost on the wrong side is invisible until it is very large.

Off-the-shelf software is not bad. For most of what a business does, buying is clearly the right answer. Email delivery, calendar booking, payments, cloud hosting - these are solved problems. A vendor has already spent ten years hardening them. You would be a fool to rebuild them from scratch.

The trap is assuming that logic applies uniformly. It does not. The commodity layer and the differentiation layer have different economics, and conflating them leads to the slow, expensive grind of software that never quite fits.

The decision framework

Buy the commodity. Build the edge.

The parts that make your business different are rarely the parts an off-the-shelf tool does well. Everything else is commodity: proven, cheap, and not worth your engineering time.

BuyOff-the-shelf wins
  • Email delivery
  • Authentication
  • Payments
  • Cloud hosting
  • Calendaring
It dependsFit vs. speed trade-off
  • CRM
  • Reporting
  • Content mgmt
BuildYour edge lives here
  • Your workflow
  • Pricing logic
  • Partner data sync
  • Ops dashboard
  • Business rules

If your tool is shaping your process instead of supporting it, it is probably costing more than the licence.

Four signals to watch

When the calculus shifts

01
Off-the-shelf is great until your process starts fighting the toolGeneric software is built for the average. It handles the common case well and the edge case badly. When your operations drift far enough from that average, you stop using the tool and start working around it.
02
Workarounds and manual glue are a hidden, growing costEvery workaround someone does today will be done again tomorrow and the day after. The spreadsheet bridging two systems, the copy-paste between platforms, the weekly export that gets reformatted by hand. These are not one-off fixes. They compound.
03
Custom pays off where your workflow is the advantageIf how you price, fulfil, or serve clients is what separates you from the competition, that part of the stack deserves to fit exactly. Software built around your process does not fight you. It reinforces the thing that makes you different.
04
You do not have to build everything, just the parts that matterEmail delivery, payments, authentication - buy all of that. The commodity layer exists for a reason. But the logic that runs your business, the rules, the workflows, the data relationships: those are worth owning.
The other trade-off

Cheap, fast, good: pick two

There is an old rule that quietly governs every build decision. You have three things you want: for the work to be cheap, to be fast, and to be good. You can realistically have any two of them, never all three at once.

Cheap and fast, and it will not be good. Good and fast, and it will not be cheap. Good and cheap, and it will not be fast. The trick is not to beat the rule. It is to choose the two that matter most for the part of the stack you are deciding on, and to make that trade with your eyes open.

  • Fast + cheapnot good
  • Good + fastnot cheap
  • Good + cheapnot fast
The takeaway

Owning the right parts of your stack

The businesses that get this right are not the ones that built everything. They are the ones that built the right things and bought the rest without a second thought. They spend their engineering on the parts of the stack that make them different, and they treat the rest as pure infrastructure.

The question is not really build or buy. It is: which parts of your operation are genuinely distinct? Which workflows, rules, or data relationships are yours in a way that no vendor will ever model correctly? Start there. Everything upstream of that answer can almost certainly be bought.

We have helped teams make this call. Sometimes the answer is a targeted custom system that replaces one piece of the stack. Sometimes it is a layer of automation that finally connects two tools that never talked. Sometimes it is a full platform built around the way the business actually runs. The starting point is always the same: map where your process fights the tool, and ask whether that fight is costing more than a better answer would.

  • Buy
    InfrastructureHosting, storage, networking
  • Buy
    Commodity servicesEmail, payments, authentication, calendaring
  • Build
    Your business logicWorkflows, pricing rules, data relationships
    Your edge
  • Build
    Interfaces around that logicDashboards, ops tooling, partner integrations
    Your edge
Buy the commodity layers without a second thought. Spend your engineering on the layers that make you different.

Not sure which side of the line you are on?

Tell us where your current tools are slowing you down. We will help you figure out whether the answer is buying better software, building something targeted, or wiring what you already have together.