Build vs buy for software: a decision framework

In short: build when the software is part of what makes your business different, or when no product fits your core process; buy when the need is generic and a product already does it well. Both mistakes cost roughly the same, in opposite directions: building what already exists wastes months, and buying your differentiator makes you a customer of your own advantage. Here is a five-question framework and the costs people forget.

The five questions

1. Is it your differentiator? If customers choose you because of how this works, own it. If nobody would notice whether you built or bought it (payroll, email, invoicing), buy.
2. Does a product fit at least 80% of the need? If yes, buying plus a small extension usually beats building. If the best product forces you to change the process that earns your money, that is a sign to build.
3. Can you maintain it? Software is not finished when it ships. Security updates, dependency upgrades, support and small changes continue indefinitely. A custom system needs a named owner.
4. How fast do you need it? A product is usable this week. A custom build takes months before the first user.
5. What is the exit? Can you export your data from the product? Can another team take over the custom code? Lock-in exists on both sides.

Costs people forget

	Build	Buy
Up front	Specification, design, development, testing, migration	Licence, configuration, integration, training
Ongoing	Hosting, security updates, bug fixes, a person who understands it	Subscription growth per user or volume, price changes
Hidden	Key-person risk, documentation, the features nobody priced	Workarounds for what the product cannot do, data export, vendor roadmap

Examples from my own work

• Build: a car-garage management product needed quotes mixing new, used and exchanged parts, labour and subcontracted work, each with its own discount and VAT rules, plus local legal identifiers on documents. Generic invoicing tools did not cover it, which justified building (see ToliMaster).
• Build around an existing system: for a health-insurance platform, replacing a legacy Oracle system was not the answer; isolating it behind a read-only API and building the new portals around it was (see LAMAS).
• Buy and extend: for a recruitment firm, the applicant tracking system stayed; only two slow tasks were added on top as services, so recruiters' habits did not change (see Werin Sourcing).

When both options look wrong

That is the moment for an independent view. A founder once asked whether a 45-day vendor estimate for a multi-tenant backend was real; it was not, because the estimate assumed a single-tenant data model. One prepared hour caught about 25 developer-days of hidden work.

A simple decision rule

• Differentiator + no fitting product: build.
• Generic need + good product: buy.
• Generic need + product forces bad process change: buy and extend, or build the thin part you need.
• Differentiator + good product exists: prototype both, then decide with numbers.

Get the decision written down

The Architecture Power Hour is built for this: one prepared hour, one question, and a one-page decision record with the reasoning and the conditions that would change it. If you decide to build, write the scope first (PRD template) and compare vendors against it (how to compare quotes).