Build or Buy? Either Way, You Pay for Something

Here is a hypothetical example, with invented figures. Your support team has outgrown a shared inbox and needs a ticketing tool. Engineering estimates one engineer for two months to build a simple one. A vendor offers a hosted product for $500 a month. Two months of salary against $6,000 a year looks like an easy comparison, and it is tempting to decide on those two numbers.

Then the details arrive. The tool needs your customer accounts and order history, so someone has to build an integration. Its reply templates do not handle right-to-left text, and half your customers write in Arabic. Every ticket your customers ever send will live in the vendor's database, and nobody has asked how to get it out. And the two months is an estimate, not a commitment, from a team whose roadmap has no two spare months in it.

Compare lifetime cost, not build hours

The build estimate and the subscription price are the smallest lines on each side of the ledger. Building also means hosting, monitoring, security patches, upgrades, on-call, and keeping the system current after its authors have moved on. Buying also means integration, workarounds for what the product does not do, adapting to the vendor's API changes on their schedule, price rises, and the cost of leaving later. Here is the same invented example over three years, at an invented $10,000 per engineer-month:

Source: invented for this example.

Over the same three years, the two opening numbers, $20,000 against $18,000, looked even. The lifetime view says buying is cheaper here, and that the largest line on the build side is upkeep, which never appeared in the estimate. Everything you build starts to carry technical debt from its first release, and nobody else pays the interest. Change one assumption and the answer moves: if the $500 is really a price per seat and your support team triples, the subscription line triples with it, and building comes out cheaper.

Build what sets you apart, rent the rest

Cost decides less than it seems. Martin Fowler's utility versus strategic dichotomy (2010) asks one question: is the business function behind the software a differentiator? If it is not, it is a utility, like payroll, and he recommends buying a package and changing your process to fit it rather than customising it heavily. If it is, a package your competitors can also buy cannot set you apart, so he favours custom software. He also notes that functions move between the two over time.

So the real decision is which responsibilities, dependencies and risks you want to own. Building means owning uptime, security, data and the knowledge of how it all works, and a component that only one engineer understands gives you a bus factor of one. Buying means owning a dependency: the vendor's roadmap, outages and prices become part of your product. At Vezeeta I worked on integrations with Fawry, Payfort and Salesforce. Integrating a payment provider is a decision to rent that capability: you accept its API, its contract and its availability as part of your own service, and in return you do not build payment processing.

Why the room leans towards building

Two findings suggest why a build-or-buy meeting can tilt one way. In four studies published in the Journal of Consumer Psychology in 2012, Michael Norton, Daniel Mochon and Dan Ariely had people assemble IKEA boxes, fold origami and build Lego sets. The IKEA effect they describe is the higher value people place on what they made themselves. Participants rated their amateur work close to experts' work, and expected others to agree. The effect disappeared when they failed to finish, or built something and then destroyed it.

In R&D Management in 1982, Ralph Katz and Thomas Allen investigated the not-invented-here syndrome in 50 R&D project groups at a large laboratory. Performance rose with group tenure up to about a year and a half, held for a while, and had fallen noticeably by five years. The best explanation they found was a sharp fall in communication: members talked less with each other, and with critical sources of information outside the group.

Neither study looked at software build-or-buy decisions, so I treat them as questions for the room rather than proof. Would we value this as highly if another team had built it? When did we last look at what already exists outside? The people estimating the build are often the people who would enjoy building it. That is no criticism, only a reason to have someone else check the upkeep line.

A decision table to reuse

When the answer is not obvious, I would put these questions to the people in the room and write the answers down:

Source: my own checklist.

Whichever way it goes, design for the exit on day one. Put the vendor behind an interface you own, so its API does not spread through your code. In a .NET codebase that might be one ITicketGateway interface with a single adapter class for the vendor; changing vendors then means writing one new class, not chasing their types through every module. Keep your own copy of the data you could not afford to lose. Run the export once before you sign, not when you are leaving. And if you build, put the upkeep line from the table above into the budget as a running cost, because it will arrive whether or not anyone approved it.

Either way, a bill arrives every month. When you buy, it comes as an invoice. When you build, it comes as your own team's time, and nobody itemises it. Choose the bill you want, then make sure someone reads it.

Written by Eslam Hamed, a Technical Lead and AI Solutions Architect working on enterprise software delivery, from pre-sale to handoff.