Who Hears About the Failure First: Five Ways to Buy the Same Integration

Mostafa Dhouib·6 min read

Who Hears About the Failure First: Five Ways to Buy the Same Integration

The short answer. When you buy an integration between two systems, you are buying code and you are also buying an answer to one question nobody asks during procurement: when the boundary breaks quietly, who finds out, how, and how long does it take? The code is comparable across all five ways of buying it. The answer to that question is not, and it is the difference between a problem discovered in a weekly report and one discovered by a customer six weeks later. Price the options on that, because the engineering difference between them is usually smaller than the detection difference.

Somebody needs payments on their existing site, or a data feed into their platform, or two internal systems talking to each other.

There are five ways to buy it, the quotes differ by a factor of ten, and the comparison is almost always made on price and timeline. Both are easy to compare and neither is the thing that decides whether this hurts in a year.

The five

A platform or plugin. Cheapest, fastest, and the boundary is handled by somebody who has solved it many times. The limit is that it handles the boundary their way. When their way does not match your need, there is no adjustment available, and when it breaks you are one of many tickets.

A generalist agency. They will build it, it will work on the happy path, and the failure modes at the boundary are outside what they were asked to think about. Detection is typically nil, because the engagement ended at delivery.

A specialist in one side. A payments specialist, a data specialist. Deep on their half and structurally uninterested in yours, which is exactly where the seam is. They will tell you, correctly, that their side is fine.

A generalist who owns both sides. Fewer assumptions crossing a boundary nobody owns, because one party is accountable for both halves. More expensive per hour and usually cheaper per incident.

In-house. Full control and full ownership, and the boundary competes for attention with everything else your team is responsible for. Detection depends on whether anyone is tasked with it, which in practice means whether somebody remembered.

The question procurement does not ask

For each option, work out the answer to this: a payment succeeds at the processor and never reaches your records. Who finds out, how, and when?

Platform. Possibly never, unless they reconcile and expose it. Some do, which is a genuine reason to choose one, and it is worth asking rather than assuming.

Generalist agency. Nobody. The engagement is over. You find out when a customer asks why they were charged.

One-side specialist. They will confirm their side is correct, and they will be right, and the problem is on the boundary which is not their side.

Owner of both sides. They should, if reconciliation was in scope. Ask explicitly, because "integration" does not imply it.

In-house. Whoever owns the monitoring, if it was built. This is the option with the highest ceiling and the most variable floor.

The spread in those answers is larger than the spread in the quotes, and nobody compares it.

What actually differs

The code is similar. These four things are not.

Does anything compare the two systems? A standing reconciliation is the single feature that turns an invisible failure into a visible one, and it is the first thing cut from a fixed-price build because it delivers nothing on the demonstration day.

Is the handler safe to run twice? Delivery is at-least-once in almost every integration worth building. A handler that double-counts is incorrect rather than fragile, and whether it is correct depends entirely on whether whoever built it knew that.

What happens when one side is absent? Not failing, absent. Silent dependencies are handled worse than failing ones, because absence produces a default that gets consumed as a reading.

Who is contractually obliged to care in month six? For three of the five options, the answer is nobody.

Buying it better

Ask the failure question during procurement, in those words, and treat a vague answer as the answer. Anyone who has run one of these in production will have a specific response.

Put reconciliation in the scope explicitly. Not as a quality expectation. As a line item, with a defined output, because it is the thing that converts invisible failures into visible ones and it is the thing that gets dropped.

Buy the boundary, not the halves. If two parties each own one side, you have bought two correct components and the seam between them is yours. That may be fine if you know it. It is expensive if you assumed otherwise.

Ask who hears about it in month six. If nobody is obliged to, the honest plan is that you will hear about it from a customer, which is a position you can take deliberately for a low-consequence boundary and should not take by accident for a high-consequence one.

The honest limit

Detection is not prevention. A reconciliation report tells you a payment went missing and does not retrieve it, and some failures are not recoverable once found: a transaction the customer never completed, a notification no longer available to request.

Nor is the owner-of-both-sides option automatically right. For a well-trodden boundary with a mature platform that reconciles, the platform is usually the better buy, and the comparison is genuinely close for a low-consequence integration. The argument here is for making the comparison on the dimension that matters rather than on the one that is easy to put in a spreadsheet.

FAQ

What should I actually compare when buying an integration? Who finds out when the boundary between the two systems breaks quietly, by what mechanism, and how long it takes. The code is broadly comparable across the ways of buying it. The detection answer varies enormously and is the thing that decides whether this hurts in a year.

Why is a specialist in one side a risky choice for an integration? Because the failure lives between the two systems and a specialist is deep on one of them. They will correctly confirm their half is working, which is true and does not address the boundary, and nothing in their engagement makes the relationship their responsibility.

What is the single feature that makes integration failures visible? A standing reconciliation comparing the two sides and surfacing discrepancies as findings. It is also the first thing cut from a fixed-price build, because it demonstrates nothing on delivery day while being the mechanism that converts an invisible failure into a report somebody can act on.

How do I scope an integration properly? Put reconciliation in as a line item with a defined output rather than as a quality expectation. Specify what happens when one side is absent rather than failing. Confirm the handler is safe to run twice, since delivery is at-least-once in nearly every integration worth building.

Is buying from a platform a bad choice? Often it is the best one, particularly for a well-trodden boundary where the platform reconciles and exposes discrepancies. Ask whether it does rather than assuming. The limit is that it handles the boundary its way, and when your need differs there is no adjustment available.

Who should own the seam if two parties each build one side? You do, by default, whether or not you intended to. That is a reasonable position for a low-consequence boundary if it is taken knowingly, and an expensive one if it was assumed away during procurement.