Should you build it or buy it?
Build when the thing is your differentiator. Buy when it is a job. The cost model rarely changes that answer, and when it does it is usually because upkeep was left out.
Reach a defensible build-or-buy decision, with a number you can show somebody and an assumption you can name.
How Should you build it or buy it? works, in one picture
The same argument as the text, as a chain. Each step is what makes the next one possible.
- 1
Ask whether it is a differentiator or a job
If the thing being automated is how your company is different from its competitors, build it. Nobody will sell you your own advantage, and buying it means renting the one part of the work that was yours.
If it is a job that has to happen and nobody will ever ask you about at a conference, buy it. Chasing invoices is a job. Categorising support tickets is a job. Almost everything is a job.
The failure mode is calling something a differentiator because it is interesting to build. Those are different feelings and they are easy to confuse at the whiteboard.
- 2
Put a loaded day rate on the build, then apply your own multiplier
The calculator on this page, and at /tools/build-vs-buy-calculatorA loaded day rate is the number your finance team uses to compare a contractor to an employee. It is usually between 1.4 and 2 times salary divided by working days, and it is the honest input.
Then multiply your estimate by whatever your last four internal tools actually took. If they each took twice their estimate, your input is twice your estimate. This is not pessimism, it is your own data.
- 3
Put upkeep in, because it is the line that decides it
A bought listing is a subscription that stops when you stop paying. A built one is a subscription paid in engineer days that never stops, and on software that calls a model it is unusually heavy: models are deprecated, an upstream API changes shape, a dependency gets a CVE with a weekend attached.
One to two days a month is normal for something calling a model and a third-party API. Zero is not a number, it is a wish, and every build case that wins does so by quietly setting it.
Set upkeep to zero in the calculator and building always wins. That is the whole argument, visible in one drag.
- 4
Read the payback month against a horizon somebody will commit to
If the build pays back in month 31 and nobody in the room can commit to anything past a year, the build does not pay back. That is not a rhetorical trick. The person who wrote it will have moved teams, and the upkeep figure was theirs.
Where the two lines are close, buy. A close result means the money is not the deciding factor, and everything else in the comparison favours the option you can cancel.
- 5
If you buy, buy something you could leave
The About table on any listing pageCheck the refund window before you commit, and check whether the listing publishes the source or an export path for whatever it accumulates. A cheap purchase you cannot exit is a build with a delay on it.
Every listing in the catalogue carries its licence, its data handling disclosure and its refund window on the page, because those three fields are the difference between a purchase and a dependency.
You have a payback month, a named upkeep assumption, and a one-line answer to whether this is a differentiator or a job.
Read next
Build when the thing is your differentiator. Buy when it is a job. The cost model rarely changes that answer, and when it does it is usually because upkeep was left out.
The near-monopolies and the commodities, side by side, because they look identical from outside and they are not.