Journey from a monolith to composable commerce – Case Veken Kaluste

Lately, composable commerce has been among the most interesting conversations in the ecommerce landscape. More and more companies are rethinking their commerce architecture and adapting the modular approach to ecommerce.

I recently had a chance to chat with an old colleague, Indre Solodov, CDO of the furniture store Veken Kaluste. We discussed their recent move from a monolithic architecture to composable commerce.

Veken Kaluste is a Finnish furniture store that has grown rapidly to one of the biggest furniture e-commerce players in Finland. Over 75 % of the company’s revenue is generated through ecommerce, and it has strong visions to keep developing the successful ecommerce further.

Indre Solodov, CDO, Veken kaluste

CR: You have transitioned from a monolithic solution to a composable one with components both built and bought. Can you share the reasoning behind why you started this journey?

Solodov: When I started at Veke, my first assignment was to create a future-proof digital strategy which is aligned with Veke's vision and core strategy. It became clear relatively quickly that the right path for us would be towards an architecture which is not restricted in any way and allowed us to begin the journey where we could build truly customer-centric solutions with speed and test new features without worrying about the costs and time.

Now that we also have an experienced in-house development team that knows the pros and cons of working with a monolithic approach, and having also seen what kind of benefits the modern technologies can bring and how much better the developer experience with them can be, the final decision was quite easy.

With the previous platform, we had constant basic issues with, for example, page loading times, product filtering functionality and checkout user experience. We used a lot of money to try to improve them but only got marginal gains even though we worked with a world-class platform partner.

When a monolithic e-commerce platform grows with modules and customisations, it becomes slower to develop new stuff with every release. Getting new minor features released could take weeks, and there were often complications after the release.

CR: The benefits from this kind of change are often indirect. How did you evaluate the business case?

Solodov: What we were after was competitive edge. We wanted to remove the productivity bottlenecks. We also did not want to be limited by the platform but wanted to decide what we need and want to do. Not only do modern technologies increase productivity, but they also increase developer experience and allow rapid testing and innovation. This was a big thing for us as well.

We also had some measurable targets like performance, mobile-friendliness in Google’s eyes and minimising negative feedback from the customers.

CR: How did you get started with your journey to composable architecture?

Solodov: I mentioned earlier that we had issues with filtering and search. Eventually, we took Algolia in use because we had previously had good experiences with it. At the same time, we needed to renew the customer portal - OmaVeke - and one of our developers started implementing a proof of concept with a modern javascript framework. The good experiences we had from the PoC eventually resulted in the bespoke storefront.

CR: You mentioned Algolia and a bespoke storefront there. What other solutions do you have in place?

Solodov: The base is the ERP, where all the orders are handled. We do not have any separate backend for ecommerce. Then we have a PIM for product data and a bespoke price engine/campaign tool. The product and price data is stored in Algolia, where it is fetched to be displayed on the bespoke storefront with personalisation from Bloomreach.

We also have a headless CMS for content that is shown on the web storefront and on the screens in our physical stores. Integrations are done with a separate integration platform.

CR: It is a common understanding that composable commerce architecture requires more technical skills than a monolithic solution. What kind of people are involved in the process?

Solodov: We have an architect, two full-stack developers and one frontend developer/designer. All are seasoned experts who have been working in the ecommerce field for several years. This expertise also helped us to justify the need for change to others.

It is true that composable architecture requires more technical maturity. This approach does not dictate how you implement the pieces, whereas the monolith gives you the frames or guidelines. Therefore with a composable approach, you have more freedom but also more responsibility to keep the architecture clean and avoid technical debt. As the saying goes, with great power comes great responsibility.

CR: Go-lives are often exciting, if not downright stressful. How did it go for you?

Solodov: We had checklists to make sure everything had been taken into account. We’ve been through many kinds of launches in the past, so we had a pretty good idea of what should be taken care of, for example, SEO-wise.

The launch itself was a soft launch, only part of the visitors were directed to the new site, and we monitored the site closely and asked for feedback from the visitors. There were some fixes needed during the soft launch, but we were also able to bring in new features that our visitors suggested.

CR: What kind of benefits have you seen so far?

Solodov: We had some clear targets for mobile-friendliness in Google’s eyes, speeding up the site, getting rid of negative feedback from end customers and increasing the conversion rate. All these have been achieved.

From a developer’s perspective, the fear of release has disappeared. With a monolith, even when the changes were tested thoroughly before release, it was very common to have complications after production release.

Nowadays, there are none, but we can trust that the code tested to work will work in production. And also, the threshold for making the releases is much lower now. We’ve probably had more releases this year than in 2022 in total.

One example of the speed of development and deployment was the omnibus directive that required changes to the price handling. Implementing the changes to the composable stack was relatively straightforward compared to experiences from monolithic platforms and their modules.

Marketers are a lot happier now with the possibility of scheduling content updates. This means that, for instance, campaigns will be published without the need for manual work like it was previously.

When discussing the benefits, one thing worth mentioning is hosting costs. With a monolith, the hosting costs were high, and you could even see the number of visitors in the cloud cost explorer. Nowadays, there are no spikes there, the hosting costs are ~10% of what they used to be, and the performance is a lot better.

Naturally, there are some SaaS costs that have been added to the totals, but with an efficient caching strategy, the TCO in general has gone down. Especially when reflecting back to the days when each update cycle for the monolith would cost tens of thousands without getting any business value.

CR: Did you have any learning experiences during the project?

Solodov: The technology and tool selections we selected were spot on. There were naturally some surprises and delays during the project, like there always are, but nothing major.

What we would do differently is to communicate even more during the project. What is being done, what will be delivered and when what will not be delivered now and why. The monolithic solutions contain huge amounts of features that are not business-critical, but someone can still use them for some purposes.

CR: What would you say to others that are thinking about the move towards composable commerce?

Solodov: Validate the business case, get the required skills either in-house or with the help of a partner or consultant and have the courage to take the leap. And remember to communicate internally.

CR: Anything else you would like to bring up?

I’d like to thank the team for pulling this out; Joose Kaasalainen as UI/UX Lead, Teemu Räsänen as solutions architect, Jani Kontturi as frontend architect, Tomi Henttinen as a senior developer and Miska Laivamaa as a junior developer. They did an amazing job here!