Why we built OpenLinker: an open-source channel manager you own

We didn’t set out to build OpenLinker. We set out, over and over, to build the same thing — a custom orchestration layer that synced orders, inventory, and listings for someone else’s shop. Then we’d hand it over, and watch the next agency do the exact same thing for the next client. Eventually we got tired of rebuilding the plumbing and built the foundation instead.

This is the story of why.

The recurring frustration that made it necessary

For years we worked as a software house with mid-to-large e-commerce companies. And a pattern kept repeating: a client would come to us wanting a custom system to replace the SaaS platform they were renting — usually BaseLinker, sometimes ChannelEngine or ChannelAdvisor depending on the market.

When we asked why they wanted out, the answers were always the same three things:

• The bill is ridiculous. Per-order pricing that scales with your success — so the better your business does, the more you pay for the privilege of running it.
• It isn’t flexible enough. You can’t change how it prices, how it handles a specific marketplace’s rules, or how it talks to your ERP.
• You build around it, not into it. It’s a black box bolted to the side of your stack instead of a part of it.

Those clients had the budgets to commission a bespoke system. But that’s a luxury reserved for a few — not because of money alone, but because of timeline, risk, and the bus factor of a private codebase that nobody outside the agency can read.

We first talked about building this — closed-source, back then — four years ago. The scale and cost scared us off. It felt like too big an endeavor to do properly. Then AI-assisted development changed the math on what a small team can ship, and we decided to take a different approach: an open-source, self-hosted platform that’s 80% of the way there out of the box. The remaining 20% — the client-specific integrations and tweaks — is exactly the work agencies are good at and can bill for.

Own the foundation, don’t rent it

Here’s the conviction underneath all of it: e-commerce shops shouldn’t pay a per-order tax, and you should own your core systems and your data.

When the system that runs your sales channels is an off-the-shelf SaaS you don’t control, you’re in a strange position. Every shop has its own know-how — pricing logic, fulfillment quirks, the small operational edges that make it competitive. The moment that lives inside a platform you rent, your competitive edge lives on someone else’s servers, under someone else’s roadmap, behind someone else’s pricing decisions.

OpenLinker is the opposite of that. It’s self-hosted, open-source, Apache 2.0. You run it on your own infrastructure. Your customer data, your order history, your listing logic — all of it stays with you. There’s no per-order pricing, because there’s no meter. The integrations scorecard is public and honest about what’s live and what isn’t. You can read every line.

That’s also why we picked Apache 2.0 specifically. We didn’t want OpenLinker to be “yet another channel manager” with a different logo. We want it to be the engine — the thing agencies build commercial solutions on top of. A permissive license protects everyone on that road: the shops running it, the agencies deploying it for their clients, and the contributors extending it. No vendor lock-in, for anyone.

Who we actually built it for

OpenLinker is for e-commerce development agencies whose clients are locked into expensive, inflexible SaaS — or who are actively shopping for a way out.

The math is straightforward. A client paying upwards of $2,000 a month for an orchestration SaaS is paying a lot for something they don’t own. An agency that knows OpenLinker can hand that same client a self-hosted system with the integrations they actually need — and the client stops paying the monthly toll. The agency, in turn, gets a genuinely differentiated offering: not “we resell a SaaS,” but “we build and maintain your system.” The client saves; the agency earns the integration and maintenance work.

How many shops are locked inside an expensive platform right now, paying forever for software they’ll never own? That’s the audience. If that’s you — or your client — we wrote a page for agencies about exactly this.

The hard decision: architecture first, integrations later

Here’s the behind-the-scenes part, and the call we argued about most internally.

From a pure business angle, we should have skipped straight to integrations. Integrations are the visible value — that’s what a demo shows, that’s what a client asks for. So why did we spend so long on the boring scaffolding?

Because we’re building OpenLinker for the long term — for years, thousands of integrations, and maintainability. We chose a hexagonal architecture: a framework-free domain core, capability ports, separation of concerns, a stable plugin SDK that adapters compile against. The honest cost of that decision is that OpenLinker is big. There’s a real learning curve, abstraction layers, and guidelines to absorb before you start building on top of it.

We had the internal argument more than once: why are we spending so much time on architecture instead of just shipping integrations? The answer we kept landing on is that a substantial, long-lived piece of infrastructure earns its longevity in the foundation, not the features. And if we want third-party contributors — which we very much do — they need to see that the thing they’re contributing to is built to last. You don’t pour your weekends into a codebase that’s going to collapse under its own weight in a year. If you want the long version of how the core is structured, we wrote up the architecture.

That’s the trade we knowingly made: a steeper starting point, in exchange for something that can stay with the e-commerce industry as a core part of how shops run.

Where it honestly is today

OpenLinker is alpha. Pre-1.0. We’re not going to pretend otherwise.

Here’s what’s actually live right now:

• PrestaShop — full catalog, inventory, and order lifecycle, including a companion module for marketplace shipping.
• Allegro — the full offer suite: OAuth, a cursor-based event journal, GPSR product-safety data, category lookup by EAN, seller policies.
• An AI content assistant for offer descriptions, with both Anthropic and OpenAI models, admin-switchable, with per-provider encrypted key storage.

And shipping right now: InPost shipping and Subiekt nexo pro invoicing integrations. Everything beyond that — Shopify, WooCommerce, eBay, Amazon, the rest of the shipping and invoicing providers — is planned, not done. We keep the scorecard honest precisely so nobody gets surprised.

Just as importantly: we’re working with several e-commerce development agencies and starting the first client deployments on OpenLinker, with a lot of hands-on support. We want to understand what works, what doesn’t, and what to fix — before we tell the world it’s done.

What we’d like you to do

If you’re an e-commerce developer or an agency, take a look. We genuinely believe you can deliver a lot of value to your clients with OpenLinker — a system that’s dramatically cheaper to run month over month, that you can extend as the client grows, with no vendor lock-in.

And if your client is currently paying four figures a month for an orchestration SaaS, switching to a self-hosted OpenLinker deployment is worth a serious look: lower running cost, far more flexibility, the integrations they actually need, and ownership of their own data.

• Star the repo on GitHub — it’s the single biggest signal that this matters to people.
• Reach out as a design partner — we’re working closely with the early agencies and there’s room for more.

We’re building this in the open, on purpose. Come build it with us.