Build or Buy: The Small Company's Honest Version of the Question

It starts innocently: the quoting spreadsheet creaks, the off-the-shelf tools do not quite fit the workflow, and the capable person on the team says the sentence that launches a thousand hidden costs: 'I could just build this.'

The build-or-buy question has a famous enterprise version, full of total-cost models and strategic-alignment matrices. The small-company version is simpler and more brutal, because the small company's scarcest resource is not money - it is the one or two people who could build anything, and everything else they would not be doing instead.

The honest version of the question is three questions, in order. They resolve most cases in one meeting.

TLDR

• Small-company build-or-buy math runs on people-hours, not license prices.

• Question one: is this your differentiator? If not, buy.

• Question two: who maintains it in year three, when the builder has moved on?

• Question three: what does 'free to build' actually cost in the builder's other work?

• When you do build, build small and plan the exit.

Question one: is it your differentiator?

The sorting question is strategic, and it is fast: does this system make you different from your competitors, or does it make you run? The quoting workflow that wins your deals might be the former. The time tracking, the HR paperwork, the expense reports are unambiguously the latter.

Systems that make you run are bought, full stop. The market has spent billions optimizing them, and your two-person edge cannot out-build that - it can only out-maintain it, badly, forever.

The gray zone is real but smaller than it feels: most 'unique workflows' are the industry's standard workflow with one custom field, and the off-the-shelf tool with the configurable field wins the honest comparison.

Question two: who maintains it in year three?

The build estimate always covers the building. The costs that decide the question arrive later: the framework upgrades, the security patches, the feature requests from the team that now depends on it, and the bus factor of its single author.

This fictional example shows the three-year ledger for one internal tool. It is an illustration, not a prescription.

	Build	Buy
Initial cost	3 weeks of Maya's time	$6,000/yr
Year 2	4 weeks: patches + requests	$6,000/yr
Year 3	Maya left; 8 weeks of contractor panic	$6,000/yr
3-year total	~$45k + one crisis	$18,000

The year-three row is the argument. Every internally-built tool is a bet on the builder's continued presence and interest, and the person-dependency audit applies to code exactly as to knowledge.

Question three: what else does the builder not do?

The license comparison - 'free to build versus $6,000 a year' - prices the build at zero, which is fiction. The real price is the builder's next-best work: the customer feature not shipped, the integration not finished, the proposal not written.

In a small company this is the whole ballgame. The builder is usually also the fixer, the integrator, and the person who knows why the report runs slow. Three weeks of building is three weeks of all of that, and the substitution is invisible until the quarter reviews itself.

Priced honestly, most builds lose. The ones that win are genuinely small, genuinely differentiating, or genuinely unavailable at any price - and they should win with their eyes open.

When you do build: small and exitable

The surviving build decision comes with two design rules. Build small: the internal tool that does one thing for ten people, not the platform that will 'eventually replace' the vendor. And build exitable: data in open formats, a runbook that exists, and a standing answer to 'what replaces this if the author leaves.'

Those rules make the build a reversible decision, which is the entire strategic point. The trap is never the building; it is the irreversibility discovered two years in.

For leadership, the standing question before any 'I could just build this': what would make us regret this in year three, and has the builder answered it? The consolidation question from tool purchases is the same muscle on the other side of the ledger.

The related discussion of what replaces this if the author leaves is worth your time alongside this one. The related discussion of consolidation question is worth your time alongside this one.

Frequently asked questions

Does 'buy' always mean a big vendor subscription?

No - it means someone else's maintenance burden. A small vendor, a marketplace plugin, even a well-maintained open-source tool with a support option all count as buying, because the year-three row belongs to somebody else.

What about AI tools that let non-developers build?

They move the build cost down and the maintenance question stays exactly the same. A workflow someone vibes into existence still needs an owner in year three - the maintenance question has gotten cheaper to ask, not less important.

How do we unwind an internal tool we should not have built?

The same way you leave a vendor: export the data, pick the replacement, run parallel briefly, and write the retirement date down. The decommissioning discipline applies to homemade systems with extra tenderness - the author is usually still around.

A Defensible Next Step

The next time 'I could just build this' lands in a meeting, ask the three questions in order: differentiator, year-three maintainer, and the builder's other work. Most answers arrive before the coffee cools. Book a Decision-Clarity Call if you want the ledger built for a real case.