Since RELEX was established in 2006, we’ve grown into a global company with over 1,700 people, multiple product lines, and a recent valuation of 5bn euros. In hindsight, the journey looks linear and stable, like we were always going to continue that path. But the reality is of course different, and over the years we’ve had to make a lot of choices and decisions, good and bad, that have kept us on track. These include decisions on people, priorities, money, and so on.
We’ve also made a lot of product choices throughout the journey. Some of the early decisions have turned out to be critical for the later phases, while many of them didn’t necessarily feel foundational or ground-breaking at the time. So, while hindsight isn’t often useful, I’ve taken the liberty to do just that, and will now discuss a couple of early choices that for us were extremely valuable.
Configurability to the extreme
The challenge of Enterprise B2B is that there’s always something special to each customer, and those customers expect you to be able to deal with these differences. As a start-up, trying to earn money to pay salaries and fund growth, you will want to adjust to those needs. But how you do that can have an enormous impact on the next phases.
The easiest and quickest way is to hard-code those requirements into the solution, and that’s normally the way to go initially. But what happens next is critical.
One typical outcome is to branch out different versions for each customer as again, that’s the quickest way to satisfy those needs. This can work fine short-term, but it easily becomes a problem as you’re essentially having to maintain several customer-specific solutions.
Another common option is to introduce some rudimentary parametrization, on code-level, meaning that all changes require developers to execute them. This is better than running several versions of the solution, but it isn’t scalable either after a while.
Obviously, the real solution is to build proper configurability into the solution. However, the challenge is that building configurability is multiple times slower than just building the thing, and there’s rarely much time available. For some companies, this can lead to growth slowing down as there just isn’t the capacity to do more.
We were lucky to introduce proper configurability early on, roughly at the right time. However, what was the real deal-breaker for us was to take that configurability to the extreme. We’re in the business of automating and optimizing, and our Chief Architect quite quickly concluded that he’s not going to code all those customer-specific variations for us but rather he will build a visual UI for our business people to be able to adjust the workflow and calculation logic for each customer.
So essentially, we built a visual workflow configurator for the tool already during the early years. As we kept scaling exponentially, it turned out to be a huge enabler for us. We often faced requirements during implementation projects that would have normally halted the project for six months because of a show-stopper product gap, but instead, we normally could configure the solution around the issue – and we didn’t need to use our precious developers’ time on that, but the consultants could do it. (If it made sense, we’d later productize it into the product properly.) Having this capability also enhanced and inspired lots of innovation across the organization.
Standardize, except where you can’t
Our decision to build extreme configurability into the product meant that the software itself was standardized, and all customers ran the same version from the get-go. However, there were areas where standardization didn’t work for us, and that was with integrations to customers’ source systems, like ERPs. We could have of course demanded standardized data in a standard format, but we soon realized customers couldn’t provide this, or at least it delayed everything by months.
Essentially, it made no business sense to be strict on this topic. So instead, we decided to make it our strength: we said we can take in data in whatever format as long as it’s a digital one, and we took care of the rest. (At least once the input data was scanned paper documents in pdf, and we still made it work.) We then built separate, fully custom, data adapters that would push the data in a standard format to the solution. The key was to do this outside of the solution which remained standardized, whereas these adapters were anything but. We also had separate teams building these adapters, which worked fine also hiring-wise: we employed university students and graduates to do that work, which was a nice entry into our R&D teams.
This approach served us very well for many years, but it also has its obvious downsides, and as we have grown and matured and reached a stronger position in the market, we have moved away from that model over the years.
Build your own database?
(I’m not quite serious with the header, but if I was to generalize it, it would be something like “make bold choices to build competitive advantage”.)
Early on in our journey, we learned that customers need real-time analytical capabilities to work with RELEX – essentially, they wanted to filter and slice-and-dice the data and KPIs. We initially built something on top of a traditional relational database, but after a while, realized that its performance wasn’t good enough for larger customers with billions of rows of data.
This called for an in-memory database, but the challenge was that there weren’t any at the time, at least any suitable ones. Eventually, our Chief Architect concluded that we need to build our own database to fully solve the issue (it took him a while to find the courage to suggest it, as he was afraid people would think he’s fully lost his mind).
That’s what we ended up doing; we built our own in-memory database, tailored for our domain & data models, and it took the performance to a completely new level. Still today it remains a significant competitive advantage to us.
Key takeaways
Any fast-growing software company will continuously face the challenge of optimizing for the short term versus the long term. The former is needed to keep the business growing, and hence often trumps the latter. However, if the growth happens to continue and even accelerate, then it can lead to issues if that long-term was neglected earlier. There’s no silver bullet here, but that balance and timing need constant focus and sometimes tough choices.
But as I’ve also highlighted, sometimes there might be valid business reasons to not try to standardize and productize, and here I believe the key is to make those decisions consciously and fully embrace the chosen path.
Finally, to really build something different, outside-the-box thinking is often needed. Again, you should not go, rogue, all the time, but I believe for every company there are those moments when building your own database (or equivalent) makes sense.
