Recommerce connectivity: from integrations to an operating system
Commerce has always been about connectivity—payments, taxes, ERPs, CRMs, channels—but recommerce amplifies the challenge. When every item is unique and time matters, your data model becomes a 3D data cube (items × attributes × time). Availability and utilization are no longer simple stock counts; they’re time-bound queries across partner networks, refurbishment lines, reverse logistics, recycling routes, and local regulatory differences.
Why “app thinking” breaks down
- Item-level + temporality: moving from SKU counts to single-item tracking over time multiplies data and decision paths.
- Partner routing rules: different brands, geos, and contracts require dynamic flows (e.g., send Brand A to Refurbisher X, Brand B to Recycler Y).
- Local edge cases: taxes, customs, or shipping can make “standard” integrations uneconomic; configurable workflows unlock margin.
- Small teams feel it too: even one-person shops juggle returns, outlet/secondhand channels, bulk liquidation, and marketplace syncs.
Why you need an operating system for recommerce
An OS mindset (not just a vertical app) gives you: robust APIs, rule engines for routing, time-aware availability, and interfaces for both humans and agents (AI, automation). It lets you cover the common 80% while keeping the final 20% wide open for custom logic—the “extension cord” hacks that create real competitive advantage.
Karri: We kind of know that commerce is connectivity game, but re-commerce is like next level connectivity game.
Tuomo: Yeah, maybe to recap on when we say commerce is all about connectivity, even though you would be an OS or what, like I haven't yet found a commerce solution historically that would have handled pretty much everything. Even SAP has sub modules that they've built or acquired. If you want to really serve your merchant base, usually the merchants’ operating environments are so specific in, I don't know, taxation and all of the software that they use, for example in customer data platforms and all of that, that you really need good API connectivity if you want to serve a commerce need, because otherwise you're not that useful for the merchants.
Tuomo: So it's a world where sometimes I like to think about it, it's almost like you'd just be connecting cords to each other—like those… what's the word in English? “Jatkojohto.” Extension cords. And so you're just building the system through extension cords, and sometimes you find that actually this extension cord is connected to itself almost. So it's this kind of hot mess of extension cords, but that's just the nature of commerce, and some solutions just make the extension cord management a bit easier.
Tuomo: In re-commerce, why it's next level, I think, is this temporality aspect and the fact that operationally it's even harder for a single merchant or retailer to handle all of the life-cycle stages internally. Maybe they do inspection, but refurbishment goes to a partner network, or reverse logistics has to be figured out store by store or state by state. There are so many operational nuances—local or product-specific—that your connectivity network becomes more complex. Not hard to connect to an individual operator, but you need configuration layers and rules: “This brand goes to that refurbisher; that brand to a different recycler.” That’s why connectivity is even more important.
Karri: Sounds like it’s an issue for large operators, but even for small operators—maybe one-person shops—there might already be multiple connectivity points or integrations, starting from sales channels.
Tuomo: Definitely. Think about someone who wants to handle product returns—say 20 a month. Maybe you don’t want to sell outlet or secondhand items in your own store, but you also don’t want to bin them. You might bulk-list them from inventory to eBay or to an aggregator focused on that category. Connectivity matters even for those bulk decisions.
Tuomo: To be honest, mistakes we’ve made in the past include designing a “perfect” process from 100 merchant requests. You can ease most flows, but there will always be edge cases. You’re building OS systems: you help with the first 80%, but the last 20% must be configurable—whether that’s chaining ten “extension cords” to the warehouse or encoding a niche rule. That’s where merchants find alpha. If everyone ran the same playbook, they’d compete only on brand.
Tuomo: I heard a story at an exhibition: a European merchant could either integrate for cross-border shipping at ~€20 per parcel (with auto tax handling) or drive a van across the border once a week and bulk-declare—bringing the per-item cost down to ~€0.50. Regulation, pricing, and geography combined to make the “weird” flow vastly cheaper. Their software needed to support that custom add-on for one person driving three kilometers. Over a year, the gross-margin impact was ~€100,000. The founder said: “I need software that lets me do these small hacks; that’s where I make my cash.”
Karri: That’s a great example. The “perfect” solution didn’t include “a guy drives three kilometers,” but you still need it in orders and records—what went into the van and why.
Tuomo: Exactly. The beauty of commerce software is catering to odd but valuable patterns in a scalable, elegant way. Like operating systems: think of all the ways people use macOS—there are odd patterns, but the OS still supports them. Yes, you lock down the 80% to help new merchants get going, but growth often comes from those explorations. If the last mile isn’t flexible, software becomes a growth hindrance. That’s what we’re addressing in the new version—keeping the OS flexible for those edge cases.