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.
The comparison fails in both directions. It understates the cost of buying, because the licence fee is the only line that makes it into the spreadsheet — the workarounds, the integration glue and the workflow compromises never do. And it understates the value of building, because an asset that gets better every quarter doesn't fit in a cell that was designed to hold a subscription price. Two numbers, both wrong, argued about in a meeting where the loudest voice wins.
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.
The rent has hidden clauses
The licence fee is the visible part of the price. The invisible parts are worth naming, because they are the ones that hurt at exactly the moments you can least afford it. Per-seat pricing is a tax on growth — the tool costs the most in the quarter you hire the most. Price escalation follows lock-in — renewal quotes have a way of doubling once your data, your integrations and your team's habits live inside the product. The roadmap isn't yours — the feature your operation depends on can be deprecated, repriced into a higher tier, or simply never built, and your only recourse is a support ticket.
Then there is data gravity. After three years, the switching cost of a deeply embedded SaaS tool is often larger than the cost of having built the capability in the first place — not because the software is good, but because leaving it means an export, a migration, a retraining and a quarter of operational risk. Lock-in is not a conspiracy; it's the business model. It just deserves a line in the comparison spreadsheet, and it never gets one.
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.
The loop is concrete. The system captures your data in your shape, which makes the next integration a week instead of a month. The integration brings a new workflow under one roof, which surfaces the next automation candidate. Each increment lands on top of the last instead of beside it. Five years in, the difference between a rented stack and an owned platform isn't a feature list — it's that one of them has been accumulating your operating knowledge the whole time and the other has been accumulating someone else's roadmap.
The second-order effects are underrated. New hires onboard against your actual process, not a generic tool plus a folder of workaround documents. Due diligence in a sale or a raise goes faster when the operation is legible in one system — acquirers pay for operations they can read. And the software itself is an asset with a value, which is more than can be said for a stack of subscriptions.
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.
Two of the quadrants deserve a note. "Buy, then customize" is where most mid-size companies should live more often than they do: keep the commodity core, and build only the thin layer that encodes what makes you different — the pricing engine on top of the standard CRM, the exception handling on top of the standard ERP. And "buy the best" is worth taking literally: for commodity workflows, the premium tool is almost always cheaper than the cheap tool plus the friction it generates.
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.
Run the ledger with real numbers, not hopes. On the cost side: the build estimate, then maintenance — a sensible planning figure is 15–20% of the build cost per year — plus hosting and the internal time to own it. On the return side: the fully loaded hours the workflow currently consumes, the cost of the errors it produces, and the revenue that faster cycle times unlock. If the return side is dominated by a soft "strategic value" line and the hard numbers don't carry it, that's the ledger telling you to buy.
Three failure modes to avoid. Building commodity software out of pride — "we're special" is not true for payroll, and the build will be competing against products with a thousand-person head start. Buying differentiating software out of impatience — the subscription starts fast and then the spreadsheet layer grows around it until the speed advantage is gone. And building the right thing with the wrong scope — a v1 that tries to cover everything ships late and lands on an operation that has already stopped believing in it. V1 should be embarrassingly narrow and genuinely used.
The common objections, answered honestly
"We're not a software company." You don't need to be. You need an owner on your side of the table and a partner accountable for the rest — the same way you own a building without being a construction firm. What you should not do is build without securing the maintenance question in writing.
"Custom software becomes legacy." Badly built custom software does. So does every SaaS tool you outgrow — except you can't refactor a vendor. Software built on boring, mainstream technology, documented and covered by tests, stays maintainable for a decade. That's a vendor-selection criterion, not an argument against owning.
"What if the vendor ships our feature next year?" Then your rented tool improves — for you and for every competitor who rents it the same afternoon. The features a vendor ships are, by definition, the ones that don't differentiate you. The capability that makes customers choose you is precisely the one you can't wait for.
How the decision ages
Build-vs-buy is not a decision you make once; it's a portfolio you rebalance. A workflow that was commodity three years ago may be where you now compete — customer onboarding often makes this journey — and a capability you built in 2019 may since have become a commodity that three vendors sell better. Put the portfolio on an annual cadence: for each owned system, ask whether it still passes the compounding test; for each significant subscription, ask what the spreadsheet layer around it now costs.
Be as willing to retire owned software as to build it. Sunsetting a custom tool whose workflow has become commodity is not an admission of failure — it's the portfolio working. The failure mode is inertia in either direction: renting your differentiation because building feels risky, or maintaining your legacy because it was expensive once. The balance sheet doesn't care what anything cost to learn; it cares what compounds from here.
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. The list will be longer than your appetite, which is the healthy state: rank by payback, build from the top, and let each project's measured return fund the will for the next one.
And when a build does clear the bar, hold it to the standard that made the case for it: a metric named before the first line of code, working software in weeks not quarters, and a scope narrow enough to be embarrassing. Owned software only compounds if it ships, gets used and keeps absorbing the operation around it. That part is not a strategy question. It's an execution one.