In 2021 I toured a 3PL warehouse outside Chicago, and the owner was proud of exactly the wrong thing. "We built all our integrations ourselves," he told me. "Saved a fortune on middleware licensing." Two engineers, one of them part-time on ops. Six months later he called me in a panic: the ecommerce platform had changed an API field, the part-timer had quit, the new hire couldn't read the old code, and orders were stuck for two days. They lost a major client over it. Those two days cost more than several years of middleware subscription would have.
Every warehouse eventually faces this decision. Orders have to flow in from marketplaces, labels have to come back from carriers, 3PL clients want inventory visibility, and the big retail customers demand EDI — 850 purchase orders, 856 ship notices, the whole alphabet soup. The question is never whether to integrate. It's who does the work, and what it really costs.
Development Is the Cheapest Part of Building It Yourself
Most warehouses cost this decision wrong because they only price the build. Two engineers, two months, the API connects, and everyone celebrates the licensing fees they "saved." That math is fiction.
The real cost structure of a homegrown integration is roughly thirty percent build, seventy percent maintenance — and the maintenance never ends. Platforms revise their APIs. Carriers rotate certificates. EDI specs get tweaked. Alerts go off at 3 AM with nobody qualified to answer. Every external change becomes an unplanned development sprint. You think you bought a one-time engineering project; what you actually bought is a long-term liability with your name on it.
The sharper risk is personnel. The single point of failure in most homegrown integration stacks isn't a server — it's the person who wrote the code. When they leave, and they always eventually leave, you inherit a black box with no documentation and a business that stops the day something changes upstream.
What Middleware Actually Sells You
Middleware isn't charity either. The iPaaS products everyone has heard of — MuleSoft, Boomi, Celigo, Workato — charge you three times, and you should get all three numbers in writing before signing. First is the subscription, tiered by connections or data volume; pricing changes regularly, so verify against the vendor's current published rates and don't trust a verbal quote. Second is implementation — vendor consultants bill by the day, and a medium-complexity integration routinely takes twice as long as the estimate. Third, and most overlooked, is lock-in: once your business logic lives in their visual flow builder, migrating away costs a fortune.
So be clear-eyed about what you're buying. Middleware is not cheaper — it's outsourced risk. When a platform changes its API, the vendor adapts the connector. When something breaks at 2 AM, there's a support team to escalate to. You're paying so that the 3 AM phone call isn't yours.
One more trap to flag before you sign: don't outsource your process mapping to the vendor's consultants. Your own workflows — where orders originate, who handles exceptions, which system is the source of truth for inventory — have to be settled internally before any configuration starts. I've seen warehouses hand the whole process design to consultants, go live with a configuration that didn't match how the floor actually worked, and pay for the rework twice. Consultants know the tool. Only you know the business.
My Three Lines in the Sand
Here are the three rules of thumb I've settled on over the years. Hit any one of them and you shouldn't be building integrations yourself.
Line one: more than five integration points. Marketplace, ERP, carriers, EDI, client portals — every additional endpoint grows maintenance complexity exponentially, not linearly. Five is about the most a human team can hold in its head. Beyond that, you need platform tooling.
Line two: you don't have two full-time integration engineers. Note the word full-time, and the words integration engineers — not "a developer who can pitch in." A homegrown integration maintained part-time will fail eventually; the only variable is when.
Line three: the business is still changing fast. Shopify this year, TikTok Shop next year, EDI from an enterprise client the year after. When the integration surface itself is unstable, rework costs on custom code will drown you. A middleware connector library exists precisely for this — enabling a prebuilt connector is an order of magnitude cheaper than writing one from scratch.
The inverse also holds. Build it yourself only when all three are true: the endpoint count stays at two or three indefinitely, the business logic is genuinely custom in ways middleware can't express — unusual billing rules are the classic case — and you have stable integration engineers who aren't going anywhere.
If You Insist on Building, Two Non-Negotiables
Some warehouses have legitimate reasons to build. Fine. But I have two requirements, and I wouldn't start without both.
First, documentation and a handoff runbook ship with the code. Before the author leaves, someone else must be able to read, modify, and deploy the integration independently. A system only one person understands isn't an asset — it's a timed explosive.
Second, every external call gets circuit breakers and retries, and every order payload must be replayable. Platform APIs hiccup constantly; without retries, one timeout is a lost order, and lost orders during peak season can cascade into penalties from marketplaces and angry end customers. Without replayability, you have no recovery path when — not if — something fails. These are the floor, not the ceiling.
Here's the one thing you can do tomorrow: list every system integration point you have on a single sheet of paper and count them. More than five? Book demos with three middleware vendors this week. Under five but maintained by one part-timer? Book the demos anyway. Don't wait for the day orders stop moving to discover you never did this math.
