Karri: Hello, and welcome to the Recommerce Podcast, the podcast where we talk all things Recommerce and circular businesses. Like always, I'm joined by Tuomo Laine, CEO and co-founder of TWICE Commerce. Welcome.
Tuomo: Thank you, Karri.
Karri: Today, we are comparing Recommerce operating systems, so Recommerce OS, with vertical solutions such as rental software. We're going to dive deep into how they differ in ways of functionality and the approach they were built and how they are thinking about API connectivity, expansion to multiple business models, and how they might work in the world of AI. Let's start by just defining. So what is an operating system?
Tuomo: I think when it comes to an operating system, it's about having a set of primitives that work for multiple use cases. In an operating system, you have a way of thinking where these primitives, which in our case in commerce might be things like stock items and listings and collections and customers and maybe orders, are defined in a way that they enable many different commerce models to be built on top of that or that they can support many different models. So they try to be less opinionated in the way how they have been set. So, for example, if we're talking about a stock item, let's say it's been set in a way that it doesn't assume that I'm going to only be rented, thus I have all of these fields that are only rental-specific. Rather, it's been built in a way that it assumes that, all right, I might be going around places. So I have a timeline, but it might be maintenance. It might be an order. It might be, I don't know, stock transfers. Stock transfers might happen in a linear commerce also. And it might assume that some information about my usage or what I am is stored into this primitive. But again, it's not saying that it needs to be a thing called condition or it needs to be a thing called rental hours. So to simplify, I think in a commerce OS, whoever is building that is trying to define primitives that work horizontally in many use cases, support those, enable all of the needed information to be stored, but tries to avoid being very opinionated on what kind of information needs to be stored.
Karri: And how does that then compare to a vertical software? So maybe for simplicity, we can focus on, for example, rental software.
Tuomo: So for vertical software, then you might—you still have a thing like stock item. But since you're building this more narrow assumption that this is now a stock item that is only to be rented, for example. And the vertical might not only be a business model; it might be, for example, AV and video equipment. So if the software knows that there’s only rentable AV/video equipment stock items in this system, they might hard-code in data values that are only relevant there to that category, like connection types to cords and all of these things that might not be relevant to a bike, for example. And there might be features that are only relevant for that industry and that rental use case that have become almost like a button or some kind of feature inside the software that might help that narrow use case. But for anyone else, it might become confusing. If we go back into what rental—so what TWICE used to be called in the early days—we might have said things like the ability to ask information from the customers, and we had predefined things like shoe size for the ski industry—age and experience level—as a set of things that might be asked from the customer. That was a very vertical-software way of building something. Because for those specific merchants it was very useful, but for someone outside of that industry, still wanting to rent, it was very confusing: why would I ask my customer for their shoe size? Makes no sense if I'm renting power tools. So I think that's the difference. It's the effort, when it comes to a commerce OS vs. a vertical software, of how you define your primitives and whether you enable your software to work for multiple industries and multiple use cases.
Karri: Maybe on a high level before we go into the specific features—how does this then show up for the user, or why would somebody, for example, build a rental-specific solution or choose it over a commerce OS? Because it sounds like it's a lot more flexible, but maybe it brings a little bit more complexity.
Tuomo: Yeah, I think we have to look at what it was 10 years ago or five years ago and what the world looks like now. First, there aren’t that many commerce OSs in the market that are approachable and well-designed for a smaller merchant. Building a commerce OS is very complex. It takes a lot of thought to build flexibility and infrastructure and define primitives so they aren’t too opinionated but don’t become too generic either. For every commerce OS, there are probably 50 vertical softwares, because it’s so much harder to build an OS than a vertical tool. Now, why build or use vertical software? A decade ago it was hard to build a commerce OS; it was easier to build vertical SaaS for a niche and serve that category. The challenge: if your niche is small (say, bike rentals), the market might not sustain truly best-in-class software—just “good enough.” For an OS, even after you do the hard work of flexibility, it still has to make sense for the user. That’s where onboarding and auto-setup matters. Like installing Windows or macOS, there’s a guided setup. A commerce OS must ask who you are and what you’re trying to achieve, then set sensible defaults so the relationships between primitives make sense from day one. With vertical software, you land in an opinionated UX that tells you “this is how you run your rental shop.” That’s great if it matches your process—but when you want to do something different, you start fighting the software and end up reading support articles that tell you how to run your business rather than how to accomplish your goal.
Karri: Makes sense. If you compare operating systems, your Mac and my Mac are set up differently with different applications. It sounds like an OS adapts to how you want to run it. I assume more mature or larger customers appreciate that, since they already have operations or know what they want to optimize. What about new entrepreneurs starting, say, a rental business? Is a vertical solution helpful as “here’s how you run a rental business” if they lack experience?
Tuomo: I’d say yes—it can be one way to get going: follow the system’s opinions and you’ll end up in a decent place. But to promote TWICE a bit: a recommerce OS like TWICE should still help you onboard as a new entrepreneur. If you tell us you’re launching a bike rental business, we can set sensible defaults—like inventory fields relevant to bikes—so you start with a familiar setup. Think how Wix evolved: it used to be “pick a theme.” Now AI asks what you’re building and configures the site. We’re doing similar with TWICE onboarding: you can describe what you want and AI agents help set everything up. That’s why the OS layer is the way forward—the tech now allows easy customization. In vertical software, customization is narrow (e.g., which KPIs show on a dashboard).
Karri: Okay, so by default an OS might feel more complex because it doesn’t predefine everything, but AI helps you customize it to the same starting place as opinionated vertical software. If AI gets me to parity on day one, what’s the long-term benefit of an OS over a vertical tool?
Tuomo: As your business matures, your needs evolve. You may want to sell your rental fleet at end-of-life, accept trade-ins, refurbish, launch repair services. On a commerce OS, you keep the same system and tweak. On rental-only software, you go shopping for maintenance software, then something else for trade-ins, and so on—accumulating parallel tools. Early expansion steps aren’t complex enough to require separate vertical systems; the OS can handle them. And because OS teams invest in primitives and clean APIs, extending with custom code is achievable. Vertical tools might have APIs, but the underlying data is so opinionated that it’s hard to extract what you need. We’ve evolved here ourselves: early TWICE APIs were opinionated; as we matured into an OS, our data became less opinionated so customers can build custom use cases.
Karri: So with vertical solutions you end up doing workarounds—using, say, a comment field to track status changes—while in an OS you define the property you need and it’s first-class and available to integrations.
Tuomo: Definitely. That’s why even a new entrepreneur is safer with a recommerce-native OS. If you need something small, in the age of AI you can often build a tiny app or agent in an afternoon using the OS endpoints or an MCP layer. Not every small need should become its own vertical SaaS.
Karri: Before we jump into AI, let’s talk API and connectivity. How is that built into a commerce OS?
Tuomo: Simplifying: start with primitives—inventory (stock items), listings, customers, orders, payments. Step one is CRUD access via APIs: create, fetch, edit primitives. That puts the GUI and the API on equal footing. Next, add services that encode jobs/relationships between primitives—e.g., an order ties customers, listings, stock items, and payments. Then the OS exposes job-level APIs (“refund this listing”) and emits/consumes events via webhooks. The key is keeping the data unopinionated enough under a commerce umbrella so partners can integrate without fighting industry-specific assumptions. Vertical software may offer similar routes, but the payloads are opinionated, which makes basic integrations brittle and job APIs hard to reuse.
Karri: A concrete example for recommerce: inspections or maintenance. How does integrating a custom form compare in an OS vs. vertical software?
Tuomo: In an OS, an inspection is just an event on a stock item’s timeline. The OS might not even have a built-in “inspection” type—you can name it what you want (inspection, automated maintenance, etc.). You listen to primitive events (e.g., order ended) and attach your custom payload at the right timestamp. The upside: total flexibility. The trade-off: the OS won’t enforce a single schema across all your forms; you own standardization if you have multiple versions.
Karri: So in a recommerce OS like TWICE, there’s a primitive “inventory item event” you can use for a lot of things. In vertical software you’d need a predefined “maintenance/inspection” endpoint. In TWICE (and other OSs), you choose the name and payload.
Tuomo: Exactly. Vertical tools could enable similar behavior, but rarely do. Another example: car rental. You might log GPS pings to ensure a vehicle doesn’t leave state or national borders. In a commerce OS, it’s easy to attach those pings to the stock item. The OS won’t auto-alarm “left the state” because it’s less opinionated, but you can build a small service that reads the data and triggers alerts. The OS remains the source of truth for items, events, states, listings, and customer interactions—while specialized jobs connect to it.
Karri: So the OS lets you do almost anything, but won’t do everything for you by default.
Tuomo: Right. You shouldn’t expect checkboxes like “prevent vehicles leaving the state” unless the OS has an app store. With an app ecosystem or partners, specialized solutions surface as plug-ins. For example, partners like Click & Share handle self-service rentals (smart locks, cold pickups/returns) and integrate with TWICE so they can focus on their specialty while the OS handles commerce primitives, accounting, storefronts, etc. Most businesses share 60–80% of needs; the remaining 20% vary wildly. An OS plus partners covers both.
Karri: Sounds future-proof—and a good segue to AI. Do you see a world where we don’t even have a thick standard UI? Where the goal is clean, accessible data that AI can use to spin up job-specific interfaces?
Tuomo: For rentals alone, there are many interfaces today: email, phone, online store. With AI, an agent can facilitate discovery, recommendation, and booking via chat or voice—on your site or in a broader assistant. Vertical tools struggle when they can’t control every step of the user path. An OS helps agents tap relevant data points to serve the user in fuzzier, real-world flows. The priority is well-designed data tables and schemas so AI agents (internal or customer-facing) can act safely and generate UIs for specific jobs. The future-proof move is to store and expose primitives in an open, accessible way for partners and agents.
Karri: Final question: you built a rental-vertical product first and now a recommerce OS. Is there still a case to choose vertical software over a recommerce OS?
Tuomo: On a business-model level, no—I don’t see a reason to pick “rental-only software.” There may be niche industries with requirements I’m not aware of, but for rentals vs. an OS, it doesn’t make sense anymore. Like it wouldn’t make sense to have “buyback-only” software. You want it connected to other primitives.
Karri: Thanks a lot for your insights. This was a deep dive into recommerce operating systems and vertical software.
Tuomo: Thank you so much.