Every operator eventually faces the question in a budget meeting: should we build this, or buy it? It sounds like a cost comparison. It almost never is. The spreadsheet that compares a licence fee to a build estimate is comparing two different kinds of objects — an expense and an asset — as if they were the same thing.
Here is the frame we use with our own clients, and with the companies where our own equity is at stake: don't ask what's cheaper. Ask what compounds.
Rented software depreciates the day you sign
A SaaS subscription solves today's version of your problem with today's version of their product. That's often exactly right — payroll, email, CRM for a standard sales motion. These are commodity problems, and commodity problems deserve commodity solutions. Buying them is not a compromise; it's discipline.
But notice what you're really renting: a workflow designed for the average of all their customers. Every quarter your operation drifts from that average — a pricing rule here, an exception process there — you pay a second, invisible fee: the spreadsheet layer. Exports, re-keying, workarounds, "the file Sanja maintains." Nobody budgets for it, and it grows in exact proportion to how differentiated your business is.
Owned software compounds — if you build the right things
Custom software behaves differently on the balance sheet and in the operation. Every workflow it absorbs, every integration it gains, every exception it learns to handle makes the next improvement cheaper. That's compounding — the same mechanism as retained earnings, applied to process knowledge.
Build only where your process is the product. Buy everywhere your process is the same as everyone else's.
The test is one question: if this workflow were twice as good as the industry standard, would customers notice? If yes — quoting speed at a freight company, claim turnaround at an insurer, intake experience at a clinic group — that workflow is a compounding asset and deserves owned software. If no, buy the commodity and move on.
The arithmetic that actually decides it
When the workflow passes the test, the build decision becomes a payback question, and it should be calculated honestly: build cost plus running cost, against hours removed, errors avoided and revenue unlocked. In our own proposals, if that payback exceeds twelve months, we recommend against building — and we put that recommendation in writing.
Three failure modes to avoid: building commodity software out of pride ("we're special" — you're not, for payroll); buying differentiating software out of impatience (and then drowning in the spreadsheet layer); and building the right thing with the wrong scope — v1 should be embarrassingly narrow and genuinely used.
Where to start
Inventory your spreadsheet layer. Every workaround is a vote — your operation telling you where it has already outgrown its rented tools. Price those hours honestly, apply the compounding test, and the build-vs-buy decision usually makes itself.