Every architecture engagement involving system integration eventually arrives at the same question: do we build a custom middleware layer, or do we accept the vendor’s integration surface as it is?
The wrong answer is expensive in both directions. Let’s break down when each is right.
What “middleware” means here
By middleware I mean a service or layer your team owns that sits between two systems and translates between them. It might handle authentication, retries, format conversion, queueing, throttling, or business logic that doesn’t belong in either system.
The alternative is to let the systems talk to each other directly using whatever the vendor provides — SDKs, webhooks, REST endpoints — and absorbing the limitations of that interface into your application code.
When to build it
There are four signals that justify custom middleware:
You need to change behavior the vendor doesn’t expose. If the vendor’s webhook fires once and your business requires three retries with exponential backoff plus an alert at retry two — and the vendor doesn’t support that — you need a layer that does.
The protocol mismatch is structural. If your platform speaks events and the vendor speaks request/response, every consumer of that integration is going to pay the cost of bridging that gap. Centralizing it in one place is cheaper than 12 partial implementations.
You expect to switch vendors. A custom middleware abstracts the vendor away. If your CRM, billing, or telephony provider is likely to change in the next 24 months, the middleware is what saves the migration.
You need audit, compliance, or observability beyond what the vendor offers. Regulated industries often need every call to be logged, signed, or routed through a specific region. Middleware is where that lives.
When to skip it
Custom middleware is one of the most expensive pieces of code you’ll ever own. It needs to be deployed, monitored, scaled, secured, and updated whenever either side changes. If none of the four signals above apply, skip it.
Specifically, skip it when:
- The vendor’s interface already meets your needs end-to-end.
- The integration is one of many low-volume ones where the cost of owning a middleware exceeds the cost of duplicating client logic.
- The vendor is genuinely strategic to your business and switching is implausible (you’re integrated with Stripe and you’re not leaving Stripe).
- Your team doesn’t have the bandwidth to operate the middleware as production infrastructure.
A real example
On a recent engagement, the client integrated their customer service platform (Freshworks) with their core operational system (a custom BOS). Freshworks had no native concept of the BOS’s primary entities, and the BOS had no concept of tickets.
A direct integration would have meant every Freshworks plugin or workflow needing BOS data would have to know the BOS’s API, auth model, and rate limits. We modeled it and counted twelve points of integration coming in the next year.
The decision was easy: a custom middleware layer that exposed a stable, opinionated API to Freshworks and translated calls to the BOS underneath. The middleware also handled retries, audit logging, and a queue for async operations the BOS couldn’t process synchronously.
Cost: one engineer for 12 weeks. Benefit: every future integration point ships in days, not weeks, and a future vendor change is a contained problem.
The decision framework
Before you commit, write down:
- What capability does the middleware add that you can’t get from the vendor?
- How many consumers will use the middleware?
- What happens if you don’t build it — what’s the duplicated cost?
- Who operates it after you ship?
If you can’t answer #4, you shouldn’t build it. A middleware without a team to operate it is technical debt with a uniform.