The Buy-vs-Build Line Moved. Here Is Where We Draw It Now.
For two decades, buy-vs-build had a default answer. Building meant hiring engineers, so unless software was your product, you bought. Sensible people stopped re-examining it.
The inputs changed and the default did not. So we wrote down an actual test.
- Build when the logic is specific to you and the data is already yours.
- Buy when the vendor carries risk you genuinely do not want — compliance, uptime, money movement.
- Never build a system of record early. Never rent a thin workflow late.
- The real cost of building is maintenance, and it arrives quietly.
- If nobody on your side can maintain it, you did not build it — you borrowed it.
The five questions
1. Whose data is it? If the data already lives in systems you own, a tool that merely displays it is renting you your own information. That is the strongest build signal there is.
2. How specific is the logic? Generic logic — accounting, payroll, tax — is better bought, because thousands of customers have already stress-tested the edge cases. Logic unique to your business is better built, because no vendor will ever prioritise it.
3. Who carries the risk? Some software exists to absorb liability. Payment processing, tax filing, anything regulated. Pay for that. It is the cheapest insurance you will buy.
4. How many humans touch it? A tool with two users and a sharp workflow is a build candidate. A tool with forty users across three departments is a buy, because the coordination cost of internal software scales badly.
5. Can you maintain it on a bad week? This is the one people skip. If the person who understands it is on holiday and it breaks, what happens.
| Situation | Verdict | Reasoning |
|---|---|---|
| Internal workflow over your own data, 1–3 users | Build | Highest specificity, lowest coordination cost |
| Payroll, tax, payments, anything regulated | Buy | You are purchasing liability transfer |
| System of record for customers or inventory | Buy | Migration and audit history are genuine moats |
| Dashboard over an API you already pay for | Build | You are paying twice for the same data |
| Anything needing 24/7 uptime you cannot staff | Buy | Ownership means owning the pager too |
Buy the things that would ruin you if they broke. Build the things that only you would ever want.
The maintenance question, honestly
Internal software does not send an invoice, which makes it feel free. It is not. It costs attention — and attention is the scarcest thing in a small operating company.
Our rule is that any internal tool must have an owner by name, a written note on how it works, and a plausible answer to what happens if that person leaves. If we cannot satisfy all three, we buy instead, even when building would be cheaper on paper.
Where the line sits today
Two years ago we would have bought nearly everything except the most bespoke internal tooling. Today the line has moved decisively toward build for anything narrow, data-adjacent and low-user-count — and has not moved at all for systems of record, regulated software or anything with a compliance surface.
Expect it to keep moving in one direction. Re-run the test at every renewal rather than once at purchase.
LAMPWORK operating framework. Companion piece to "We Rebuilt Our CRM in a Weekend" and "Software in Freefall."
Own a brand this applies to?
We talk to founders at every stage — long before they're ready to sell.
Start a Conversation →