When you sign your first integration with a print service provider, the cost is obvious: a few weeks of engineering time, some API calls mapped to your internal schema, and you're live. But as you add a second provider, then a third, then ten, something else happens. The cost doesn't scale linearly. It compounds.
The visible cost
Let's start with what you can count.
One integration takes about 4-6 weeks: understand their API, design an adapter, write tests, deploy. You've paid that. When you add a second provider, you pay it again. Different schema, different status vocabulary, different SLA structure. You can't reuse much from the first one.
By the third integration, you've sunk maybe 15 weeks of engineering time. That's 2-3 person-months.
But you knew that going in. That's not the hidden cost.
The costs you won't see until they arrive
The real expense shows up later, in the form of maintenance.
Each PSP can change their API on their schedule, not yours. Maybe one provider updates their status codes, another deprecates an endpoint. You have a Slack channel tracking their API changes. You have a junior engineer who's now the "expert" on three different integrations. You burn cycles every quarter handling upstream breaking changes.
Point-to-point integrations don't fail once. They fail continuously, in small ways, until you consolidate them. — Toby Dawson, Founder
And then there's the data problem. Each provider tracks inventory differently. One reports capacity in units, another in time slots. One updates in real-time, another batches. You build normalization logic for each one, and when someone asks "why can't we just use the cheapest provider all the time?" you have to explain why you don't have a single cost model across all fourteen APIs.
Now add a new customer. They want to integrate with a provider you don't currently support. Four more weeks. They want to negotiate a special SLA? You need custom routing logic just for them. They want to understand why an order went to Provider A instead of Provider B? You can't answer that without wading through fourteen different decision trees.
Why scaling is the real problem
In theory, n integrations should cost n × (cost of one integration). In practice, the cost grows as n².
Why? Because each provider doesn't exist in isolation. Your routing decisions affect all of them. Your customer wants to balance cost, speed, and quality across all providers simultaneously. Your operations team wants visibility into capacity across all of them. Your finance team wants a consolidated cost model. And none of that is easy when your integrations are siloed.
You start asking questions like:
- Why can't we automatically fail over when one provider is down?
- Why can't we optimize cost in real-time based on current capacity?
- Why does adding a new provider take 6 weeks instead of 6 days?
- Why don't we have SLA visibility across all providers?
And each answer involves cross-cutting logic that touches all fourteen integrations.
The compound cost of change
Here's where it gets expensive.
You decide you need better capacity planning. So you design a new data model that can represent capacity uniformly across all providers. That's a 2-week project touching fourteen adapters. Then you discover that three of your providers don't actually expose capacity data in real-time, so you need to build inference logic. Another 3 weeks.
Now you want to add routing rules based on geography. That cascades: you need to normalize geography representation across providers, handle regional fallbacks, and add a new dimension to your scoring function. Each adapter needs updates.
You want to support webhooks from all providers so you can react to changes immediately instead of polling. That's fourteen different webhook schemas to normalize.
Each feature request, each optimization, each operational improvement hits the same wall: you have to change all fourteen integrations to get benefit across the system.
Breaking the cycle
The way out is to stop thinking about "integrations" and start thinking about "adapters to a unified platform."
The difference is structural. An integration is a point-to-point connection from your system to Provider A. An adapter is a translation layer that speaks your internal language on one side and Provider A's language on the other.
Once you have that separation, scaling becomes linear again. Adding a new provider means writing a new adapter. Optimizing your platform means updating shared logic once, not fourteen times. New features are built into the platform; adapters automatically get them.
That's the architecture we built Oruve around. Not fourteen integrations. One platform with fourteen adapters.
The cost savings aren't subtle. We went from "adding a new PSP takes 4-6 weeks" to "adding a new PSP takes 4-6 days." We went from "rolling out a new routing strategy takes months" to "rolling out a new routing strategy takes a sprint." We went from "visibility into cross-provider capacity requires custom queries" to "it's built in."
That's not magic. It's just what happens when you stop bolting things together and start thinking like a platform.