Build versus buy

The comparison is made on total cost over a horizon fixed before any numbers are gathered — usually three to five years. A one-year comparison flatters subscriptions and a ten-year one flatters building, so choosing the horizon after seeing the figures is the single easiest way to make an analysis reach a predetermined answer.

The buy path is costed with the items that do not appear on a quote: implementation, data migration, integration with what is already in place, training, the internal hours consumed running the rollout, and the annual escalation written into the contract that nobody reads until the third renewal.

Workflow change is costed as a real line, not assumed away. Every tool carries a model of how the work is supposed to happen, and the distance between that model and how the business actually operates gets paid for — either in customization that has to be maintained, or in people permanently doing something in a less sensible order.

Exit cost is estimated before entry, which is the item skipped most often and regretted most sharply. What it takes to get the data out, in what format, whether history comes with it, how long the export takes, and what stops working the day the contract lapses. A vendor unwilling to describe their exit path in writing has answered the question they were avoiding.

The build path is costed with the parts that are easiest to leave out. Not the initial build, which everybody estimates and most people estimate reasonably, but the maintenance, the dependency upgrades, the second person who eventually has to understand it, and the standing fact that a built system has nobody to call when it breaks at an inconvenient hour.

Build estimates are treated as optimistic by default, and the report says by how much instead of leaving the reader to apply their own discount. An estimate presented as a single number is a wish; the range is what makes the two paths comparable.

The commercial conflict is disclosed in the document, at the top, in the reader's own language. This firm builds things, so it profits from the build answer. Writing that down is not a formality — it is the precondition for the rest of the analysis being worth reading at all.

What makes the disclosure more than a gesture is that the numbers are checkable. Every figure carries its source, and the assumptions are stated as assumptions, so a reader who thinks one of them is wrong can substitute their own and watch the conclusion move. An analysis that cannot be re-run by its reader is asking for trust it has not earned.

Keeping what already exists is costed as a third option, not treated as the absence of a decision. The current system has a running cost, a risk profile, and a remaining useful life, and comparing two futures against each other while leaving the present uncosted is how organizations talk themselves into replacing something that had four good years left in it.

Time to value is a cost line with a number attached. A tool live in three weeks and a build delivered in nine months are not the same purchase even at identical totals, and the difference is whatever the business loses by waiting — which is sometimes very little and occasionally the entire reason the decision is being made at this moment rather than next year.

Who carries the risk of being wrong is stated, because it differs between the paths and rarely gets said aloud. Buying transfers some categories of risk to a vendor — they maintain it, patch it, and are contractually on the hook when it breaks — while introducing others the business cannot control, principally that the product's direction, pricing, and continued existence are decided by somebody else. Building keeps every category in-house, which is worse when the team is thin and better when the thing genuinely matters.

Hybrid answers are considered explicitly, not treated as a failure to decide. Buying the commodity part and building only the piece that is genuinely specific to the business is frequently the correct answer, and it is proposed less often than it should be because it suits neither a software vendor's story nor a development firm's.

Buy is the right answer considerably more often than a firm that builds things is naturally inclined to say. Anything a business does in essentially the same way as every other business — payroll, email, accounting, card payments, calendars — is a solved problem with mature products, and building one is a decision to maintain something forever in exchange for very little.

Building earns its cost in a narrower set of cases: where the process is the actual competitive advantage rather than overhead, where no product fits without distorting the work in ways that matter, where the data cannot leave for a defensible reason, or where the available products are priced against a scale the business does not have.

Reversibility is weighed alongside cost rather than mentioned after it. Between two options at similar prices, the one that can be undone is worth more, and that premium is stated as a number, not left as a feeling. One-way decisions deserve more scrutiny than their price alone would justify.

The decision is written down together with the assumptions it rests on. When it is revisited in two years — and it will be — the question then becomes which assumption stopped being true, which is a productive conversation, rather than who made the call, which is not.

The report recommends one option by name and states the strongest case against it. An analysis that lays out three paths with balanced consideration and declines to choose has handed the decision back to the person who paid to have it made, and has done so while appearing thorough.