Build or buy: the three numbers that decide it
Buying is usually right and building is usually wrong, so the useful question is not which you prefer but where the arithmetic flips. Three numbers decide it, and none of them is today's sticker price: licence drift, the integration tax and the cost of the workaround. This article shows how to work each one out.
By Saveez IrfanUpdated
In short
- Buy by default. Build only when your own numbers over your own horizon say so, or when the process is what makes you different.
- Licence drift is the seats you expect in each year multiplied by the annual seat price, plus the tier upgrades you will be pushed into.
- Integration tax is the hours spent each month making several tools behave as one system, multiplied by what those hours cost, over the horizon.
- Workaround cost is the recurring price of every step that exists only to compensate for the tool's shape.
- Often the best answer is neither: buy the platform and build only the component that does not exist.
Should you build or buy software?
Buy by default. Build only when the cost of licence drift, integration tax and workarounds over your planning horizon exceeds the cost of building and running the software, or when the process is what makes your business different.
A product you buy has already absorbed the edge cases you have not thought of, carries a support obligation, and improves without you paying for each improvement. Software you build has none of that until you pay for it. For most business functions, such as email, payroll, storage and a standard CRM, building is indefensible. The question is whether your process is one of the few where the numbers have flipped.
What is licence drift?
Licence drift is what per-seat pricing costs across your planning horizon of headcount growth, rather than today's invoice. Multiply the seats you expect in each year by the annual price per seat, add any tier upgrades you will be pushed into, and sum the years.
The calculation flips most often in two situations: many low-intensity users who each need a seat to do one small thing, and a vendor whose tiering forces an upgrade for a single feature. A form product charging per seat for people who submit one form a month is the classic case. The FormCraft build started there: the incumbent charged per seat, kept uploaded files on its own servers and was awkward to drive from an automation platform. The replacement is a self-owned application with its own file storage and a token-secured API.
What is the integration tax?
The integration tax is the recurring effort of making several products behave as one system: syncs to maintain, fields to map, duplicates to reconcile, and a spreadsheet in the middle that has quietly become load-bearing. It is the number most often missed.
To price it, measure the hours a month spent keeping the systems in agreement, multiply by what those hours cost, and by the number of months in your horizon (years x 12). If that figure is comparable to building the thing the tools are imitating, you are already paying build costs, but paying them indefinitely and getting a worse result.
The trading ERP is the plainest case we have. Supplier invoices arrived on paper and were re-keyed by hand into both a desktop ledger and a stock spreadsheet, and the two disagreed constantly. When a figure was wrong there was no way to establish who had changed it, when, or what it had been before. In that case there was no platform to keep: the ledger was a single-machine desktop application whose export produced nothing usable, so building was the route to getting the books into one place.
- How many hours a month go into reconciling systems that should agree?
- How many spreadsheets exist only because two products cannot talk?
- How often does a data problem come down to which system was right?
- How much of your automation spend exists purely to paper over a gap?
What does a workaround cost?
A workaround is a recurring step that exists only to correct or compensate for the shape of a tool. Price it per month, multiply by the months in your horizon, and put it next to the build cost.
The diagnostic is simple. If a process has a step that exists only to correct an earlier step, that step is the cost of the tool's shape. Typical forms are a step performed twice, a field used for something it was not designed for, and a report rebuilt by hand each month because the product cannot express the question.
On the solar ops platform the existing system allowed one site per deal. A rollout across six depots is one negotiation but six roofs, so the team either raised six deals for something negotiated once, or recorded one and left five buildings off the system. Each of those is a standing workaround, and the second one means the records are wrong in a way nobody sees.
There is a harder-to-price version: the things the business does not do because the system makes them painful. That cost is real and rarely appears in any comparison.
When does building win even if the numbers are close?
Build when the process is what makes you better than your competitors, because a generic implementation of it makes you the same as them. That is the one case where building is justified even when the arithmetic is marginal.
The inverse holds just as strongly. If the process is undifferentiated, and doing it slightly differently from everyone else has no commercial value, then building it is spending money to acquire maintenance.
Is there an option between building and buying?
Yes, and it is usually the right one: buy the commodity platform and build only the component that does not exist. This spends engineering only where the gap is, so it costs less than a full build and does more than a full purchase.
The fleet order automation is this shape. The client kept monday.com. We built a parser that turns inbound orders into board rows, a portal where installers see only their own jobs without a licence, and a two-business-day SLA engine that escalates on its own. Nothing the platform already did well was rebuilt.
The same pattern applies elsewhere: keep the accounting product and build the capture pipeline in front of it, keep the work platform and build the portal it cannot provide, keep the database and build the interface your team needs. A full build is right when there is no platform worth keeping, as with the desktop ledger above.
Common questions
When licence drift, integration tax and workaround cost, summed over the years you plan to keep the system, together exceed the cost of building and running it, or when the process is a genuine competitive differentiator. For commodity functions such as email, payroll and storage, buying is almost always right.
A focused automation or integration is typically two to four weeks. A full application, such as an ERP module set, a portal or a platform, runs eight to twelve. The mapping and prototyping phases at the start are short on purpose, so that a wrong assumption surfaces before it is expensive.
This is the right thing to worry about, and the answer is ownership rather than promises: your repository, infrastructure accounts and domain from the first commit, plus a runbook covering the schema, deployment and known sharp edges. If a build cannot be handed to another competent engineer without an introduction, it was built badly.
Sometimes, for the right shape of problem. You are trading speed now for a ceiling later and limited portability. It works well when the process is simple and stable, and badly when the process is your differentiator, because you will eventually need something the platform does not permit.
Drafted with AI assistance (Claude). Published under Saveez Irfan’s name, who is accountable for it. Editorial policy