Build or Buy: the Crossover Hiding Under a Business-School Checklist

Mon, 29 Jun 2026 12:59:49 +0800

i learnt the build-versus-buy framework in my NUS information systems module (TCX2005, on the progress page). the business-school version is a checklist of considerations, which is useful but feels like a lot of words. underneath it is a much smaller idea: one cost line crossing another. i had my AI help me turn the checklist back into that picture and draw the crossover. the personal note at the bottom is mine to write after.

the question

you need a piece of software (or a kitchen, or a skill, or a website). do you build it yourself, or buy something that already exists?

the textbook answer is a checklist: strategic value, resources, market solutions, risk, compliance, time. all real. but a checklist hides the one number that actually moves first, so let us find that number, then put the checklist back on top.

it is two cost shapes, and they cross

the two options have different cost shapes, not just different totals.

a quick key:

symbol	what it means
$F$	the fixed cost of building: the big one-off to develop it yourself
$m$	build’s running cost per period (maintenance, hosting, the one engineer who knows how it works)
$s$	buy’s running cost per period (the subscription, the per-seat licence)
$t$	time, in periods you keep using the thing

build is a large lump now, then a small trickle: $F + m,t$. buy is nothing now, then a steady meter running: $s,t$. one starts high and barely rises; the other starts at zero and climbs forever. so they cross. set them equal and solve for the moment they do:

$$ F + m,t = s,t \quad\Rightarrow\quad t^{\ast} = \frac{F}{s - m} $$

that $t^{\ast}$ is the whole decision in one symbol: the break-even horizon. plan to use the thing for less time than that and buying is cheaper; plan to keep it longer and building wins. with a 100k build, 10k a year to keep it alive, and a 35k a year subscription, the lines cross at four years:

Build is a lump now and a trickle after; buy is a meter that never stops. Before the break-even horizon, the meter is cheaper. After it, the lump was. The only inputs are how big the lump is and how fast the meter runs.

notice this is the same machinery as the marginal-cost note: a fixed cost is only ever expensive per unit of use when you do not use it much. stretch $F$ over a long enough horizon and it stops mattering, which is exactly why long-lived, heavily-used systems drift towards build, and short-lived or lightly-used ones stay bought.

the sticker price is the smallest number

all of that assumes you actually know $F$, $m$, and $s$. the most common way this decision goes wrong is not the maths, it is the inputs: people weigh the price tag on one option against the full cost of the other.

and the price tag is the smallest part of what you pay. the licence fee, or the developer’s quote to build it, is the tip. under the waterline sits everything that never reaches the invoice: integration, data migration, training, the support contract, the security and compliance work, the downtime when it breaks, and one day the cost of ripping it out again. add up that whole iceberg over the years you will really use the thing and you get its total cost of ownership. that, not the sticker, is what $m$ and $s$ were always supposed to be.

the trap even has a direction. a build’s iceberg is bigger and better hidden: the one engineer who knows how it works is a salary that never stops, and maintenance compounds quietly for as long as the thing lives. a vendor’s iceberg is mostly the vendor’s problem, already priced into $s$. so setting a one-off build quote against a subscription almost always flatters building, because you are putting a tip next to an iceberg. the honest fix is small: compare iceberg to iceberg, lifetime to lifetime, and only then read the crossover.

cost is the first word, not the last

the crossover tells you when the money flips. it does not tell you whether money should decide. three things can override it:

strategic value. if the thing is your actual edge, the part competitors cannot copy, you build it even when buying is cheaper, because the point was never to save money. if it is plumbing everyone has (email, payroll, an office suite), you buy it even when building looks close, because owning plumbing wins you nothing.
risk and compliance. a mature vendor has already paid for the reliability, the security, and the regulatory box-ticking (PDPA, GDPR, and friends). building means buying all of that yourself, in time and in liability.
time. the crossover assumes you can build. if the market window closes before your version ships, the cheaper line on the chart is irrelevant.

a clean way to hold all of this at once is to sort the task: is it strategic (your edge, lean build), critical (must not fail, but standard, lean buy the proven thing), or routine (commodity, buy the cheapest that works)? the cost crossover then decides the close calls within a bucket, not across them.

a real one: how NUS stopped building its own

the cleanest case is one i am literally sitting inside. NUS ran its own learning platform for two decades: IVLE from 1999, then a second in-house build, LumiNUS. both were built. in 2022 it gave up and moved everyone to Canvas, a SaaS product the rest of the world already uses.

nothing about the maths changed; what changed was the answer to the checklist. a learning-management system stopped being a place NUS could out-compete anyone, so its strategic value fell to zero. once it was plumbing, the only question left was the crossover, and an off-the-shelf subscription beat paying engineers to maintain a bespoke platform forever. build to buy, exactly when the thing stopped being your edge.

why this is not really about software

the shape is everywhere you spend. cooking versus eating out: the kitchen is $F$, each restaurant meal is $s$. learning a skill versus hiring it out. owning a car versus grabbing one. self-hosting versus paying for the service. the question is always the same two-parter: how long will i lean on this, and is doing it myself actually my edge? if the honest answers are “not long” and “no”, buy it and feel nothing. if they are “for years” and “yes”, that is the rare case worth building, and the upfront cost was never the real number.

there is one exception that swallows the whole chart: if the thing you would be building is a network, the cost lines stop mattering. an existing network’s head start is its own kind of moat, and rebuilding it from zero means dragging a cold network all the way to critical mass while the incumbent sits comfortably past it. that is the most expensive build there is, which is why you almost always buy into the network rather than recreate it.

a personal note

wip …

sources and further reading

raymond mcleod & george schell, management information systems, and laudon & laudon, managing the digital firm: the textbook framing of make-versus-buy and the acquisition process (RFP and all).
my marginal cost and sunk cost note: where the fixed-versus-variable cost machinery under this crossover comes from.
my network effects note: the one case where the crossover stops mattering, because an existing network is the most expensive thing to rebuild.
my NUS progress page: the module (TCX2005) this came out of.

Break-Even on ENKR's Blog | Jing Hui PANG