Somewhere in the last fifteen years, the default way to build a serious software product stopped being “write it” and became “assemble it”. Authentication, payments, messaging, search, analytics, observability, billing and increasingly whole vertical subsystems arrive as services you subscribe to rather than code you own.
The pitch is compelling and largely true: a team of six can now ship something that would have required sixty, and in regulated verticals — trading infrastructure, health records, insurance — the specialist components come either as licensed products or as custom fintech development engagements with firms that have already solved the domain problems once. What the pitch leaves out is that assembly is not free. It has a cost structure of its own, it is paid continuously rather than up front, and most teams only discover its size in year two.
This is an attempt to name that cost properly, and to set out how to evaluate a vendor before you have committed to one.
Assembly replaced building, quietly
It is worth being precise about what changed, because the shift was gradual enough that many teams never made an explicit decision about it.
In the older model, a product team wrote most of its own code and bought infrastructure: an operating system, a database, maybe an application server. The boundaries were wide and stable, the interfaces were standards, and switching cost was high but calculable.
In the current model, the boundaries are narrow and numerous. A modest SaaS product might depend on twenty external services, each with its own API, its own failure modes, its own release cadence, its own pricing model and its own view of what your data looks like. Your product is, to a significant degree, the code that sits between those services — the translation, the retries, the reconciliation, the compensating logic when one of them is wrong.
That in-between code is the integration tax. It never appears on a roadmap, it is rarely attributed to the vendor that caused it, and it compounds.
Where the cost actually accumulates
Teams estimate integration cost as the time to get the first successful API call working. That is typically five percent of the total. The rest arrives in categories that are predictable enough to plan for.
Error handling and the unhappy path. The documented API is the happy path. Production is timeouts, rate limits, partial failures, duplicate deliveries, malformed responses and the occasional maintenance window announced somewhere you were not reading. Building the retry logic, the idempotency keys, the dead-letter handling and the alerting around one integration reliably takes longer than building the integration.
Model impedance. The vendor’s data model is not yours. Their “customer” has one email address; yours has several. Their “order” has a single line item; yours has a hierarchy. Every mismatch becomes a mapping layer, and every mapping layer becomes a place where information is lost in one direction and invented in the other.
State reconciliation. As soon as two systems hold overlapping state, they will disagree. Someone cancels in one and not the other; a webhook is lost; a retry creates a duplicate. Reconciliation jobs are the quiet backbone of assembled systems and are almost never scoped in the original estimate.
Version churn. Vendors deprecate. A dependency you integrated two years ago announces a breaking change with six months’ notice, and that work lands in a quarter you had already planned. With twenty vendors, this is not an occasional event; it is a standing allocation.
Debugging across boundaries. When something is wrong and the evidence lives in someone else’s logs, your mean time to resolution is bounded by their support response time. This is the cost that most damages the engineering experience, because it converts problems your team could have solved into problems your team can only escalate.
Compliance surface. Every vendor with access to user data is a subprocessor. Each one needs review, contractual terms, a place in your data map, and a mention in your privacy documentation. In regulated sectors, each is also something an auditor will ask about.
A reasonable planning heuristic: budget three to five times the naive integration estimate for the first year, and a standing maintenance allocation of roughly ten to twenty percent of one engineer per significant vendor thereafter. Teams that plan on this basis are rarely disappointed. Teams that plan on the first-successful-call basis spend their second year confused about where velocity went.
Reading an API like an engineer, not a buyer
Vendor evaluation usually runs on feature matrices. Feature matrices are close to useless, because every vendor in a category ticks every box, and the differences that matter do not fit in cells. What you want instead is a two-day technical evaluation against the following.
Documentation that describes errors. Anyone can document success responses. Look for a complete enumeration of error codes, with the conditions that produce each and the correct client behaviour for each. A vendor that documents its failure modes has thought about them. One that does not, has not, and you will discover the taxonomy yourself in production.
A sandbox you can break. Not a demo environment that always succeeds — a sandbox where you can trigger failures, simulate timeouts, force rate limits and replay webhooks. The presence of a proper sandbox is one of the strongest available signals of engineering maturity.
Idempotency as a first-class concept. Can you safely retry a write? Is there an idempotency key mechanism, and is it documented? Without it, every network blip becomes a potential duplicate charge, duplicate order or duplicate record, and you will build a deduplication layer that should have been theirs.
A versioning policy in writing. How are breaking changes defined, how much notice is given, how long are old versions supported, and what is the historical record? Ask for examples of the last two deprecations and how they were handled.
Webhook discipline. Are deliveries signed? Retried? Ordered, or explicitly unordered? Can you replay them? Unsigned, unretried webhooks are an invitation to build your own polling layer on top.
Rate limits that are published and sane. Undisclosed limits discovered under load, during your busiest hour, are a special kind of unpleasant.
Latency characteristics, including the tail. Ask for percentile distributions, not averages. In any system where your request blocks on theirs, their ninety-ninth percentile is part of your user experience.
The SLA arithmetic nobody does
Availability numbers are quoted as though they compose. They do not — they multiply.
A service at 99.9 percent allows roughly forty-three minutes of downtime per month. Chain five such services in a critical path where any one failing takes down the flow, and your theoretical ceiling is about 99.5 percent: over three and a half hours a month, before counting your own code. Add two more dependencies and the ceiling drops again.
Three implications follow.
First, the composed number is what your users experience, so it is the number to design against. Second, the way to beat it is not to demand better SLAs from vendors — you will not get them at your size — but to reduce the number of dependencies in the critical path. Caching, graceful degradation, asynchronous processing and queueing move a dependency off the critical path, and a dependency off the critical path does not contribute to the multiplication.
Third, read what the SLA actually promises. Most offer service credits, which refund a fraction of what you paid for the period in which they failed you. That is not compensation for your outage; it is a discount on their invoice. Treat SLAs as a statement of intent and an indicator of how seriously a vendor takes reliability, not as a risk transfer mechanism, because no meaningful risk is being transferred.
Pricing models and the bundle question
Vendor pricing shapes architecture more than teams expect, because engineers will optimise for whatever the meter measures.
Per-seat pricing is predictable and penalises internal adoption — you will find yourself rationing accounts, building shared logins, and degrading your own audit trail to save money.
Per-usage pricing scales with success, which sounds fair and means your cost curve is coupled to your traffic curve rather than your revenue curve. These diverge more often than anyone expects.
Per-unit-of-value pricing — per transaction, per account, per instrument — aligns best but requires care that the unit the vendor counts is the unit your economics are built on.
Bundles are the model most common in mature vertical markets, where a vendor packages several related components at a combined price below the sum of the parts. In brokerage technology, for example, vendors publish pre-packaged software bundles assembled around a firm’s operating model — a starting package, a growth package, a package aimed at proprietary trading firms — rather than selling every module separately.
Bundles are usually good value and carry a specific trap: they make the marginal component free, so teams adopt modules they do not need because they are already paying for them. Six months later, three of those modules are load-bearing, and the bundle is no longer a purchasing decision but an architectural dependency. Adopt from a bundle deliberately, component by component, exactly as though each had its own invoice.
Lock-in, honestly assessed
“Avoid lock-in” is advice that sounds prudent and is frequently expensive. The costs of avoidance — abstraction layers over every vendor, lowest-common-denominator feature use, a permanent translation tier — are paid immediately and continuously, while the benefit is contingent on a migration that may never happen.
A more useful framing is to estimate exit cost per vendor and decide whether it is acceptable, rather than trying to drive it to zero.
Exit cost is low when the vendor does something standardised and your usage is shallow: transactional email, object storage, error tracking. Abstracting these is usually wasted effort; if you need to move, you move in a week.
Exit cost is high when the vendor holds state you cannot easily reproduce, when their model has shaped yours, or when the integration touches many parts of your codebase. Payments, identity and any domain-specific core system fall here. For these, the protections that actually work are contractual and operational rather than architectural: a guaranteed data export in a documented format, an agreed notice period, and — critically — an export you have actually tested rather than one you have been promised.
The thin-abstraction compromise is often right for the middle cases: a narrow internal interface that captures the handful of operations you genuinely use, with no attempt to model the vendor’s full surface. It costs little and it localises the change if you ever need to swap.
Support is a product feature
In an assembled architecture, the vendor’s support function is part of your incident response capability, and it should be evaluated with the same seriousness as the API.
Test it before you buy. File a genuine technical question during the trial — something specific, from an engineer, that requires the responder to look at the system. Response time matters, but the diagnostic quality of the answer matters more. A reply that misreads the question and links a documentation page tells you what a production incident will feel like at three in the morning.
Ask about escalation: is there a path to an engineer, or does support terminate at a tier-one queue? What are the guaranteed response times by severity, and are they contractual or aspirational? Is there a status page with an honest incident history — and does that history match what you can find in community discussions from the same dates? A status page showing perfect uptime for two years is not evidence of perfect uptime.
For vendors in the critical path, onboarding time is also worth measuring explicitly. A vendor who can take you from contract to production in a week is selling something materially different from one whose typical implementation runs a quarter, regardless of what the feature matrices say.
Observability stops at your boundary, and that is the problem
In a system you wrote, an incident is a matter of reading your own telemetry. In an assembled system, roughly half the evidence is on the other side of an API, and getting to it is a commercial negotiation rather than a technical one.
The practical mitigation is to instrument the boundary as though it were a hostile interface, because operationally it is one. Every outbound call should carry a correlation identifier you generate, and every response — success or failure, with timing and status — should be recorded on your side. When a vendor tells you their system responded normally, you want your own record of what you sent, when, and what came back, at percentile granularity.
This matters for a reason beyond debugging. Vendors measure their own availability at their edge, using their own definitions, and those definitions frequently exclude the categories of failure that hurt you most: elevated latency that is technically a success, partial responses, rate limiting applied under load, regional degradation. Your measurements are the only ones that reflect what your users experienced, and in any dispute about whether an SLA was breached, they are the only evidence you control.
It is also worth keeping a synthetic check running against each critical vendor independently of your production traffic — a small, regular transaction through the real path that alerts on degradation. Discovering an outage from your own monitoring rather than from a customer email is largely a function of having built that check before you needed it.
Vendor security is your security
Every integration widens your attack surface and your compliance obligations, and the diligence here is unglamorous but not optional.
Start with the basics: which certifications or audit reports exist, when were they last renewed, and will the vendor share the actual report under an agreement rather than a badge on a marketing page? Ask when the last independent penetration test was conducted and whether a summary is available. Ask how vulnerabilities are disclosed and how quickly critical patches ship, and ask for a recent example.
Then follow the data. What exactly do they store, in which jurisdictions, for how long, and who are their own subprocessors? A vendor’s subprocessor list is effectively an extension of your own, and one that can change with thirty days’ notice. In regulated sectors your auditor will ask for this map; building it as you integrate is far cheaper than reconstructing it a week before an audit.
Finally, scope the credentials. Most integrations are configured once, with the broadest available permissions, and never revisited. Scoped keys, per-environment separation, documented rotation and alerting on unusual usage are the difference between a vendor breach that costs you a key rotation and one that costs you a disclosure notice. The vendor’s own security posture is partly out of your hands; the blast radius of their failure is entirely within yours.
When to build after all
Assembly is the default for good reasons, but three conditions justify building.
It is your differentiator. Whatever your customers actually choose you for should be code you own. Buying your core is a strategic error dressed as a practical one.
The domain fit is poor. When a category product requires enough configuration and workaround that you are effectively writing a system anyway, with the added constraint of someone else’s data model, the calculation has already tipped. The warning sign is a growing folder of adapters.
Unit economics invert at scale. Usage-priced services that are cheap at a thousand transactions can be indefensible at ten million. Model the vendor’s cost at your three-year volume, not your current one, and know in advance the volume at which building becomes rational — so that you can make that decision on schedule rather than in a panic.
A fourth case sits between the two: commissioning custom work from a vendor who already knows the domain. You get their accumulated understanding of the problem, and you retain a degree of control over the result. The terms are what decide whether this is buying or building, so settle them explicitly — who owns the resulting code, whether it can be resold, who maintains it, and what happens if the vendor is acquired.
There is also a timing dimension to this decision that is easy to miss. Building early, before you understand the problem, produces an expensive system encoding assumptions that turn out to be wrong. Buying early, before you understand the problem, is cheap and teaches you what the requirements actually are — the vendor’s model becomes a working specification you can later improve on.
So the sequence that tends to work is to buy first, instrument heavily, and revisit once you have a year of real usage data showing exactly which parts of the vendor’s product you rely on and which you never touch. By then, the build decision is a scoped project against known requirements rather than a speculative one, and in most cases the honest answer turns out to be that only a narrow slice was ever worth owning.
A scorecard worth using
For each candidate vendor, score one to five and weight by how close the component sits to your critical path.
- Error documentation completeness
- Sandbox fidelity and failure simulation
- Idempotency and retry semantics
- Versioning and deprecation track record
- Webhook reliability and replay
- Published rate limits and tail latency
- Composed availability impact
- Data export: documented, complete, and tested by you
- Support responsiveness and diagnostic quality
- Pricing alignment with your unit economics at three-year scale
- Compliance posture and subprocessor transparency
- Estimated exit cost in engineer-weeks
Anything scoring poorly on items three, four, eight or twelve deserves a second look regardless of how good the product demo was, because those four determine what the relationship feels like in years two and three — which is where the integration tax is actually paid, and where the decision you are making now will either look obvious or expensive.
