Print is broken for the same reason most legacy infrastructure is broken: it was built one integration at a time, when nobody thought beyond the next provider. We started Oruve because watching teams struggle with that architecture felt like watching 2015 repeat itself in print, and we kept thinking: what if that didn't have to be the default?

The architecture nobody wanted

Here's how most print workflows actually work:

  • Your ecommerce system receives an order.
  • You check five different print providers to see who's available.
  • You manually route based on rules you maintain in a spreadsheet and a Slack channel.
  • You hope the provider accepts the order.
  • When something breaks, you have no visibility into why. You check five different dashboards.

Nobody designed it this way intentionally. It's just what happens when you bolt integrations together.

The first provider integration takes a few weeks. It works. The second takes another few weeks. The third provider changes their API and suddenly you're maintaining custom logic for three different status schemas. By the time you're managing five providers, your routing logic is scattered across three systems and you're maintaining it in Slack.

That's not a scaling problem. That's a design problem.

What the problem actually is

The problem isn't that print providers exist. The problem is that there's no abstraction between you and them. You have to speak all their languages and maintain all their quirks. — Toby Dawson, Founder

I spent a decade building systems that had to coordinate across multiple services — not print, but the underlying patterns are identical. The core insight is always the same: the system works until you add the third provider. Then integration tax becomes your primary engineering cost.

For print specifically, that tax is enormous. Each provider has:

  • A different product model (one thinks in units, another in time slots)
  • Different status codes and SLA definitions
  • Different integration patterns (REST, SOAP, FTP, custom protocols)
  • Different update cadences (real-time, batched, poll-based)
  • Different pricing models (flat, usage-based, contract rates)

You end up with custom normalization for each one. You end up with routing logic that doesn't know how to compare apples (Provider A's capacity units) to oranges (Provider B's time slots). You end up with operational dashboards that don't talk to each other.

And every time you add a new provider, you do it all again.

The coordination problem

But the deeper problem is coordination. Once you have multiple providers, you have multiple dimensions to optimize simultaneously:

  • Cost: Who can do this cheapest right now?
  • Speed: Who can deliver it fastest?
  • Quality: Who produces the best output for this product?
  • Capacity: Who actually has availability?
  • Geography: Who's closest to the destination?
  • SLA: Who's currently meeting their commitments?

Most teams solve this by making it your problem. You maintain a routing algorithm. You answer "why did this order go to Provider A?" by reading code.

What if it didn't have to be your problem?

The gap between theory and practice

In the abstract, print routing looks simple. You score each provider and pick the best one.

In practice, "best" is context-dependent. It changes with customer preferences, current capacity, SLA standing, and real-time pricing. You can't hardcode it. You have to abstract it.

You also can't afford latency. Your checkout flow is blocked while you're making routing decisions. You have milliseconds. That means fan-out to all providers in parallel, handle timeouts gracefully, and make a decision fast. That's not trivial when you have 14 providers with different response times.

And when something goes wrong — a provider is down, an order fails to route, capacity disappears mid-fulfillment — you need visibility. You need to understand what happened and why. Most teams don't have that. They have logs scattered across providers and internal systems.

What we're building

Oruve is our answer to all of this. It's not "yet another integration platform." It's a control plane for print.

The idea is simple: you should be able to add a new provider in days, not months. You should be able to change your routing strategy without touching adapter code. You should be able to see capacity, cost, and SLA status across all providers from a single dashboard. You should be able to optimize for whatever metric matters most to your business — cost, speed, quality, or some combination.

Most importantly: the system should work the same way whether you're connected to two providers or fourteen.

That's the architecture we didn't find, so we built it. It's the thing we keep thinking about and keep writing about. And it's why we started Oruve.