Build or buy: deciding properly

The decision is made at the wrong altitude

Companies ask "should we build or buy a CRM?" and the question has no good answer, because a CRM is eight components and the honest answer differs for each. Contact storage: buy. Pipeline reporting: buy. The lead scoring logic that encodes how your particular business qualifies a lead: possibly build. The integration between the CRM and your operations system: almost certainly build, because nobody sells it.

Asking at the system level forces an all-or-nothing answer and produces the two classic failures: a bought platform being tortured into a shape it was never designed for, or a team building a worse version of something that already exists in order to get the one feature they actually needed.

What to count on each side

Both columns are routinely mis-costed, and in opposite directions. Buying looks cheaper than it is because integration and workaround costs are invisible at purchase. Building looks cheaper than it is because maintenance is a liability you renew every month for as long as the system lives.

The line people skip is maintenance. A system that costs a certain amount to build costs roughly a sixth to a quarter of that every year to keep alive, and that cost starts the day it ships and never stops. Any comparison that omits it is not a comparison.

When building is genuinely right

The bar is higher than most teams apply, and only two of these on their own are usually sufficient.

• It is your actual differentiator. If a customer would notice and care that it works differently from a competitor's, build it
• Nothing on the market fits without distortion. Not "nothing is perfect", but nothing fits without changing how the business fundamentally operates
• The integration is the product. Connecting systems you already own is work no vendor sells you
• Per-seat economics break at your scale. Usage-based pricing that is comfortable at 20 users and ruinous at 500 is a real build case, but do the arithmetic rather than assuming
• The data cannot leave. Regulatory or contractual constraints that rule out hosted options settle the question

When buying is right, which is most of the time

Buy anything that is a solved problem for an industry rather than a question for your business. Authentication, payments, email delivery, accounting, document storage, helpdesk, calendars. These are commodities in the precise economic sense: mature, well-understood, and available from several vendors at a price no internal team can match.

The test I use is uncomfortable but effective: if this component worked exactly as well as a competitor's, would anything about your business be worse? If not, you are proposing to build a commodity, and the correct response to a commodity is to buy the cheapest adequate one and spend the attention elsewhere.

The hybrid trap

The most expensive outcome is neither building nor buying but heavily customising something bought. It presents as pragmatic, because you get the platform's foundation and your specific requirements, yet it accumulates the disadvantages of both.

You carry the licence cost and the development cost. Your customisations break at every vendor upgrade, so you either stop upgrading, which slowly becomes a security problem, or you pay to re-fix them repeatedly. And the customisation layer is invariably undocumented, because it never felt like a real system while it was being written.

Configuration is fine. Extension through a supported API is fine. Modifying the vendor's own code, or building substantial functionality inside their extension framework, is where this goes wrong.

How to actually run the decision

Break the system into components and decide each one separately. For each, write down the five-year cost of both paths using real quotes and a real estimate rather than a feeling. Ask whether a customer would notice the difference. Then choose, and write down why.

That last step is what makes the decision survivable. In two years someone will ask why this was bought and that was built, and "it was decided before I joined" is how a company ends up rebuilding something for no reason.

Frequently asked

How do you calculate the five-year cost of building?

Development cost, plus annual maintenance at roughly 15 to 25 per cent of the build, plus the opportunity cost of the engineering time. Then add the cost of the second version, because if the system matters there will be one, and it usually arrives sooner than the plan assumes.

Is custom software always more expensive?

No. It is more expensive far more often than teams expect, but per-seat pricing at scale, or a workflow that no product supports, can genuinely invert the arithmetic. The point of running the numbers is that both intuitions, "building is cheaper" and "buying is cheaper", are wrong about a third of the time.

What if we buy and later outgrow it?

That is a normal and acceptable outcome, provided you can get your data out. Check the export path before buying, not when leaving. Outgrowing a tool in four years having shipped in four weeks is a considerably better result than building for eight months to avoid a migration that might never happen.

Should we build to avoid vendor lock-in?

Rarely a sufficient reason on its own. Building substitutes vendor lock-in for key-person lock-in, which is often worse because it is undocumented and cannot be escaped by paying someone. The better mitigation is a clean data model and a working export, whichever path you choose.

Who should make the build-versus-buy call?

Someone with no stake in the outcome. An agency has a reason to prefer building and a software vendor has a reason to prefer buying, so neither is a neutral party. If nobody internal can evaluate it, that neutrality is precisely what a fractional CTO is for.