Build or Buy: The Question Behind Every Integration

A team needs a customer portal. One person has priced a hosted product per seat per month. Another has estimated ten weeks of engineering. The meeting has quietly become an argument about which number is smaller, and it will often produce the wrong answer, because the two numbers measure different things and neither of them contains the item that ends up dominating the bill.

The build vs buy decision is not a price comparison. It is a question about which parts of your operation are allowed to look like everybody else’s, and which parts are the reason a customer picks you at all. Price follows from that answer rather than the other way round. Teams that start with price reliably end up buying the thing that differentiates them and building the thing that does not, which is the most expensive arrangement on the menu.

There is a second reason these meetings go wrong. A build estimate covers building. It rarely covers the years afterwards, which is the whole subject of what it actually costs to maintain what you built. Buying carries an equivalent blind spot, and it is usually the larger one: the integration work nobody scoped, and the question of who is holding your data on the day the relationship ends.

What the build vs buy decision is really asking

Every build or buy question is four questions wearing one coat. Is this thing part of why we win? What does it cost across its whole life rather than its first quarter? What happens when we want out? And can we afford the calendar either option demands? Answer those four honestly and the decision usually makes itself. Answer none of them and you get a spreadsheet with two columns and a coin toss.

We take a position on this, and it is not a neutral one. Most teams should buy more than they do, and build a far thinner layer than they think. Not because building is difficult. Because building is easy and owning is not. The code arrives in a fortnight. The ownership arrives forever, and it arrives quietly, in the form of a person who can no longer take a holiday without a laptop.

The exception is narrow and worth stating precisely. Build when the thing you are building is the reason someone chooses you over the alternative, and when a bought version would force you to work the way the vendor imagined rather than the way you actually work. Both halves have to be true. Only the first is usually checked.

Four tests, in this order

Run them in sequence. The order matters, because a yes on the first test changes what counts as an acceptable answer on the other three. A differentiating component is worth an ugly cost curve. A commodity one is not worth any surprise at all.

One: would a customer notice the difference?

Ask whether a customer would notice if this component behaved differently from the way everyone else’s does. Not whether it is important. Almost everything is important. Payroll is important and nobody differentiates on payroll.

The test is sharper than it sounds, because it separates two things teams routinely merge: work that is central to running the business, and work that is central to winning it. Invoicing is central to running it. A pricing model no competitor offers is central to winning it. The first is a purchase. The second is a build, even where a bought version exists, because the bought version will steadily push you back towards the industry default it was designed around.

One caveat we apply hard: differentiation has to be currently true, not aspirational. "We will differentiate on onboarding one day" is not a reason to build an onboarding system today. The same discipline decides where a model earns its place and where a rule is enough, which is the argument in where AI earns its place.

Two: total cost, which is not the price

The price of buying sits on a pricing page. The cost does not. Add the integration, the data migration, the training nobody books time for, the seats you will add as the team grows, and the renewal increase you accepted without reading when you signed a multi-year term. Buying is a subscription to somebody else’s roadmap as much as to their software.

The cost of building behaves worse. The first version is the cheapest thing about it. Then come dependency updates, the security patches you now own rather than receive, platform and browser changes, the departure of whoever wrote it, and the fact that every future request lands on your backlog instead of a vendor’s. Keeping third-party components current is a standing job rather than a one-off, which is precisely why tooling exists to track vulnerable dependencies at all.

Compare over three years, not one. And include the least visible line of all: the work your team will not do because it is busy keeping this alive.

Three: what does leaving cost?

Ask this while everyone is still friendly, because the answer never improves later. What does a full export produce, in what format, with which relationships intact? Is the export available on the plan you intend to buy, or only on the tier used in the demonstration? Does it include the history, or only the current state? A system with no clean export is a system you have quietly agreed never to leave.

Building has an exit too, and teams forget it exists. The exit from a built system is a rewrite, and its price is set in the first fortnight: whether the data model can be separated from the interface, whether anything else can read it, and whether the interface between the pieces was designed for a stranger. That is the case made in API design for people who will use it in two years, and it applies to internal software far more often than to public products.

Four: time, and what the window is worth

Time is the test everyone quotes and the one they measure worst. The useful question is not how long each option takes. It is what happens in the gap. If a window genuinely closes, buy, and accept the compromises that come with it. If the window is really a preference expressed as a deadline, the time argument is weaker than it sounds in the room.

Buying is also not instant, and this is where estimates flatter it. A bought system requiring six weeks of integration, a data migration and a permissions model that has to be reconciled with the one you already run is not faster than a narrow built component that ships in five. Compare like for like: time to the first real user, not time to a signed contract.

The bill nobody puts in the buy column

Two costs sit on the buy side of the ledger and almost never reach the spreadsheet. Both are structural, which means no amount of vendor goodwill removes them. They are integration and data ownership, and together they explain most of the disappointment that follows an otherwise sensible purchase.

Integration is the product you actually bought

A bought system does not arrive finished. It arrives with an edge, and the edge belongs to you. Everything that has to be true for the product to behave like part of your business, rather than a separate business you now also operate, is work nobody demonstrated.

• Identity. Who signs in, with which account, and what happens when someone leaves. Two user directories is a security problem disguised as an inconvenience.
• Data mapping. Their fields are not your fields. Someone decides what a "customer" means in both systems, and that decision outlives the tool.
• Failure handling. Retries, duplicates, partial writes and the question of which system is right when they disagree. This is where most integrations rot.
• Notifications. Their emails, in their template, from their domain, unless you do the work to stop that happening.
• Reporting. Numbers that have to reconcile with the numbers you already publish, or someone will maintain a spreadsheet to bridge them.
• Upgrades. Their release schedule is now partly your release schedule, including the release you did not want.

None of that is a reason to build instead. It is a reason to scope honestly, and to treat the integration itself as a project with an owner rather than a line item in a procurement note. The purchase is the easy half.

This is easiest to see on something that looks trivial. An enquiry form appears to be a form. It is really a routing and triage instrument, an argument our parent company makes directly in a form is a triage instrument, and the routing is the part no product ships with your rules already inside it. You will buy the fields and build the judgement, every time.

Who is holding the data when it ends

The second cost is ownership, and it is not resolved by a clause saying the data is yours. Ownership in practice means three things: you can get it out in a structured form, you can get it out without asking permission, and what you get back is complete enough to run on. Many products satisfy the clause and none of the three.

There is a governance edge to this as well. Where a bought system processes personal data on your behalf, the obligations remain yours in the eyes of anyone asking, so the vendor’s retention rules, sub-processors and deletion behaviour become facts you are answerable for. That is a different sort of cost from a monthly fee, and it does not appear on any comparison table. It is the same trade discussed in what you take on with headless commerce, where the flexibility gained is real and so is the operational weight.

Three cases, and what we would do

Frameworks are easy to agree with and hard to apply. Here are three situations that come up constantly, run through the four tests, with the answer stated rather than hedged.

Case one: enquiry handling for a services team

Enquiries arrive, someone reads them, someone routes them, and follow-up is inconsistent. The proposal is a custom pipeline. Differentiation: no customer chooses this firm because of how a message is stored. Exit: the records are contacts and messages, which every product exports. Time: the problem is current and painful.

Buy, and build one thin thing: the routing rules that encode how this particular firm decides who takes what. That is the only part with judgement in it, and it is a small amount of code sitting between a form and a mailbox. Building the storage, the reminders and the audit trail as well would be several months spent recreating a category of software that already works.

Case two: a pricing engine no competitor has

Quotes depend on a combination of volume, service level and delivery window that nobody else in the sector prices the same way. Sales is doing it in a spreadsheet with three versions in circulation. Differentiation: this is the offer itself. Total cost: high, and worth it. Exit: the rules are the asset, so keep them in a form that outlives any interface. This one is a build, as an application with a real owner, and the first version should do less than the spreadsheet does today.

The mistake in this case is not buying instead. It is building the whole quoting workflow when only the pricing logic is distinctive. Buy the document generation, the approvals and the delivery. Build the rules. A differentiating component does not entitle everything adjacent to it to the same treatment.

Case three: a site for an individual practitioner

A consultant, a clinician or a specialist needs a presence that loads fast on a phone, says who they are and lets someone get in touch. Differentiation: the person is the differentiator, not the page structure. Total cost: any bespoke build here spends its life needing small updates from someone who is not available. Products such as Nichevio exist for exactly this shape, assembling a mobile-first profile site from structured widgets, and buying is plainly correct.

The answer changes the moment that site becomes the primary route to revenue for a growing team, with campaigns, segmentation and a content operation behind it. Then the constraint stops being cost and starts being control. Note the pattern: the component did not change, the business around it did.

What flips the answer later, and how to notice

Every build or buy decision has a shelf life, and the failure is rarely the original choice. It is not revisiting it. Three signals tell you the answer has flipped: you are paying for a product mainly to work around it, the configuration has become an undocumented system in its own right, or the vendor’s roadmap has moved somewhere you are not going.

The reverse signal matters just as much. A built component that nobody has touched in a year, that generates no complaints and that a bought product would now cover, is a candidate for retirement rather than affection. Deciding between repair and replacement is its own discipline, covered in when to rewrite instead of refactor, and the same honesty applies here.

Buy the parts a customer only notices when they break. Build the parts a customer chose you for. Everything else is negotiation.

Where we would start

If this decision is live for you now, the sequence below takes about a week and removes most of the argument. It works because it forces the expensive questions to the front, where they are still cheap to answer.

1. Write the non-goals first. What this thing will never do is more useful than a feature list, and it eliminates half the shortlist before a demonstration is booked.
2. Apply the differentiation test out loud. Say the sentence "a customer would notice if this worked differently" and see whether anyone in the room agrees without qualifying it.
3. Price three years, both ways. Include integration, migration, seats and renewals on one side; maintenance, patching and turnover on the other.
4. Run the export, or design the seam. For buying, export real data during the trial. For building, write down how the data leaves before you write how it arrives.
5. Name the owner and the review date. A component without a named owner is a component that will be discovered by an incident. Put the review in a calendar, twelve months out.

The rule we would hand a team with no time for any of it: buy unless a customer would notice, and when you do build, build the smallest thing that carries the judgement and nothing around it. That single sentence would prevent most of the abandoned internal tools we are asked to look at. If you want a second read on a specific decision, describe what you are weighing up and what the deadline behind it really is. The way we work through it is set out in our approach.