<aside> 💡
Headline lessons
RELEX began as a research-to-reality company: the founders had spent years close to supply-chain and retail planning problems, and wanted to turn that knowledge into something that would work in day-to-day operations, not just on paper. Johanna frames the early anchor as choosing a relevant problem and then building credibility by proving, in outcomes, that you actually solve it—not just that you have a theory.
The founding team was also not “perfect on paper” in the stereotypical startup way. They all came from a similar industrial engineering background, which meant they were not starting from “startup mythology,” but from an operator’s view of how supply chains and replenishment actually work. Early progress came from knowing the area, having expertise in supply chain, and being able to react quickly as they learned.
The founders of RELEX in 2012. Mikko (left), Johanna & Michael.
That domain depth also shaped how they behaved with customers from the beginning. They understood the subject area deeply and used that knowledge to guide customers toward better ways of working, rather than treating customer-requested solutions as the blueprint. In other words, their fit was not only that they could build the product, but that they could lead customers through a messy operational problem with a point of view.
The initial insight behind RELEX was that automated store replenishment was turning into a category, and that category mattered because the work was becoming too complex to run well through manual planning and simplistic tools. From their perspective at the time, the available approaches worked mainly in the easy cases. The opportunity was in the opposite direction: the more variables, exceptions, and constraints you have, the more value a computer can create because it can handle calculation-heavy complexity in a way humans cannot.
That view also shaped how they saw their arena. They were not stepping into a mature, packaged software market with clear “best practices” to copy. They were stepping into a messy operational space where retailers were still figuring out what good replenishment even looks like, and where new processes often had to be built alongside the software. Johanna sees that this created room to lead customers toward better ways of working rather than simply automating old habits.
Finland shaped RELEX’s early R&D in a very practical way. There were not enough meaningful customers in any one retail segment to stay narrow, so their early customers spanned very different categories, from consumer electronics to agricultural retail to bookstores to car tyres. Some patterns repeated, but the edge cases were wildly different, which forced them to learn quickly.
That breadth created a constraint they could not ignore. They needed one solution that works for everyone, because customer-specific forks would not survive contact with even a modest customer base. Johanna says it was obvious early that if you build ten custom branches you end up with something you cannot maintain. Michael saw that same pressure from the field. Different Finnish retailers kept arriving with different requirements, and their architect refused to solve it by hand-coding endless variants, which pushed them toward a strong common core with configuration on top.
As customers grew larger, validation became less about “does it work at all” and more about whether the system could keep its promise at scale. Their optimisation depended on detailed calculations, and eventually performance stopped scaling. They were met by a hard choice: either lower the level of detail they delivered or change the technology underneath. They chose to protect the promise. They moved toward in-memory approaches, could not justify buying one of the few, very expensive, off-the-shelve products at their pricing level, and ended up building their own database and rewriting the application around it. At the time a rewrite of that size was only feasible because they did not yet have a massive legacy base of hundreds of customers.
The earliest version of their product was not glamorous. Johanna says the first thing they delivered was “embarrassingly simple,” but it still created real value for the customer. That first version was only a starting point. Each new customer forced the product to become more sophisticated, and much of what they built became shared progress rather than isolated customer work. Over time, customers did not just get “their own solution,” they raised the level of the common product for everyone.
The early adopters in their story were the customers who were willing to build with them. Those customers mattered because they did not only buy something finished as they helped shape what “good” looked like in practice, and they gave RELEX the room to keep iterating while staying anchored in real operational pain.
RELEX also did not treat early adopter feedback as a feature request queue. They believed in shipping and learning continuously, but they drew a hard line between understanding the problem and copying the customer’s proposed solution. Johanna sees that if you stay inside the customer’s existing frame, you will only produce inside-the-box outcomes. Their job was to understand the pain deeply and then use their domain expertise to propose a better approach than the customer could have specified upfront.