Halil is the CTO of LoveCrafts.com. They operate in 100+ markets and are now in the process of migrating from Magento to commercetools. The cool part of the conversation is the discussion on how you actually compare and choose an eCommerce platform? Why commercetools disqualified all other contenders? How digital transformation at a scale looks like and how LoveCrafts folks dealt with the challenges with their user-oriented, startup-like business attitude. Read on to learn more!
Piotr Karwatka: My name is Piotr Karwatka and I am CTO of Divante, an e-commerce company. We've been focused on API first, headless implementation projects for some time already. One of our best known products is an open source project called Vue Storefront and PWA for e-commerce that you can run with any e-commerce back-end. I'm really excited because today my guest is Halil Köklü - CTO of Lovecrafts, a global community for crafters and makers. Halil, it's really good to have you here!
Halil Köklü: It's great to be here! Always a pleasure talking to you.
Piotr Karwatka: Awesome! I think that the context is pretty important, so the context is that we are working together with Lovecrafts on migrating the monolithic e-commerce to a next-gen platform. It's based on commercetools plus Vue Storefront Next on the front-end. By the same time, Halil and Lovecrafts organization, together with Divante, are building the open source connector between commercetools and Vue Storefront Next, so it's a really exciting project. Before Lovecrafts, Halil led technology at Rocket Internet in Amsterdam, the largest online fashion retailer in the Middle-East. What else should we know about your experience Halil?
Halil Köklü: Well, I'd say I've pretty much only done e-commerce in my career and still like it. In high school, I was busy writing online shops in PHP, later moved on to Magento in 2009 so it was quite early and Magento back then worked on some larger websites including a multi-level marketing company which had like more than 20 languages, countries, really old ERP integrations, it was like IBM I series. That also involved building something like a nutrition questionnaire, so that at the end of that questionnaire it would throw an individualized nutrition supplement. There was also our perfume configurator so you could configure your perfume from the bottle to the packaging. I've built the integration from the online shop to feeding the jobs into the machine. That was quite interesting because you were in that big hall standing next to a 63 meter long machine and I would throw thousands of jobs in there for stress tests and see what's going to happen.
Piotr Karwatka: So kind of a perfume printer?
Halil Köklü: Yeah, you could say that. There were laser machines involved and all sorts of things. I later moved on as a Magento expert to Rocket Internet. I've started with their Brazilian ventures, later moved on to their own stack and was Technical Lead in some of the Turkish ventures and then moved on to B2C for Namche and Mizado. Namshe mentioned is a fashion retailer whereas Mizado was something like an Amazon clone. It actually started as Lazada. It happened to be later bought by Alibaba in South-East Asia but these were the two teams I was dealing with and then surprisingly it was one of my first product development organization experience. Running an organization like that I somehow also had to deal for the first for that platform so we were the first to do multilingual, multi-currency first migrate to AWS. We got a lot of DDOs attacks, so DDOs protection and cloud infrastructure were things I learned there.
Piotr Karwatka: Awesome, sounds like something really complex. Lovecrafts is one of the biggest crafting community websites and marketplace around the globe started, I guess, in 2012. Can you maybe please share some background, how did you join the company?
Halil Köklü: Yes, as I mentioned, Rocket is a very fast and dynamic place, so we kept joking amongst ourselves that a year at Rocket is like three years elsewhere. But that pace also came with downsides. They would hire hundreds of people and then fire them half a year later. My team wasn't spared from this. One team got fired during my absence, so I have decided I can't support that ethically and decided to move on. I was looking for something more meaningful when I moved to London and Lovecrafts happened to be the first company I spoke to. I was blown away by Edward, Nigel and Cherry - old friends who decided to found the company together. They did that with their own savings with a mission to serve the crafts community and the visionary way of running a company. I was immediately drawn to this and then started literally the next day. That was almost seven years ago.
Piotr Karwatka: Wow, a long run. So what else makes Lovecrafts unique and what's it’s business model?
Halil Köklü: I have to start with my colleagues. First of all, they are crafters themselves, so you could say that Lovecraft is built and run by crafters for crafters. Like you might say with Vue Storefront, right? Made by developers for developers. Our users are not just reaching out for things like “where's my order” but they also get help with crafting, so it's not uncommon that a colleague would be crafting a user's project to find out where exactly they got stuck to help them resume their project and this can't be done in a few minutes. It's really time consuming and requires passion. I'm probably one of the least experienced in crafting but we do learn, even as engineers, how to knit and at the moment I'm trying myself on an embroidery project to learn more about that craft. But I must say that here at Lovecrafts, the community product we built is headless since 2014. So we built an API with some neat features like expandable queries similar to GraphQL, a symfony based front-end as well as native apps are consuming from this API. In 2018 we streamlined our editorial content from Wordpress for the blog and we were using Magento CMS for the static pages to Prismic which is a headless content management system. Back in 2011/2012 at Rocket Internet we launched various e-commerce businesses with their platform. The platform was called Alice and Bob where Alice is a front-end and Bob is a back-end. It was not as tidy as the ones we see today but I felt like it was still somewhat novel. Actually the original authors went on to other ventures and they have recently launched this as a product. It's called Spriker.
Piotr Karwatka: Yeah, Spriker is pretty interesting platform. Let me ask you about the key reasons to go towards this architecture. You were on Magento and decided to go headless… What were the key reasons for that?
Piotr Karwatka: So you have this direction and you need to have the rise of the puzzles that the back-end and front-end platform the project we are currently in is really interesting one because you picked commercetools as a back-end and Vue Storefront Next as a front-end application. I'm wondering about the decision factors to choose commercetools as we were talking about it before, I know it wasn't an easy decision.
Halil Köklü: Yes, it wasn't easy but actually when you look at commercetools it's very straightforward, you get drawn to it very quickly. The time consuming bit is looking at the details. To summarize why we chose commercetools let's start with chemistry. It's a bullshit free company, approachable, you have access to people and they give you honest, valuable feedback. It's API only, it has GraphQL support, it's modular so you can pick and choose. This is great if you don't want to be dependent on a major platform so for example there might be a new use case or it might not fulfill your expectations so that you might say we need to move our catalog to something else but you can still continue using the checkout. It has a great and complete documentation, like you understand the representations, the APIs immediately and it fulfills most of our requirements. It actually had the best overlap with our requirements compared to all the other platforms. The pro data model is very sensible and scalable, translations are for example represented in localizable attributes rather than requiring a whole new store in Magento for example. The pricing model is flexible and you have this staging capability so you can make changes to your products but publish at the end either by doing QA or have some other processes. This allows you to use the catalog SFM as well, whereas for example in Magento you save a product and then it's immediately public.
Piotr Karwatka: In Magento 2 which changed but still... It looks like a very well taught and very good decision but I must ask what other solution have you considered?
Halil Köklü: We wanted to give this a due process, right? So I can't just go and say I like commercetools and we go with it. We had to be sure because a platform change like this doesn't happen often. You want to make sure that it covers your current needs but also your future needs because you won't be migrating probably for another 5-10 years. We did some market research and looked at 30 platforms and 10 in detail, including meeting solution architects, going through each of our requirements and so on.
Piotr Karwatka: And can you maybe elaborate on this review process you had in place?
Halil Köklü: I think first of all you need to understand your business well, your product, your technology stack... We are very fortunate that most of the original developers and product managers are still with us so there's a lot of knowledge
sitting in our teams. I too have implemented many of the defining parts of the product, so everyone in the team can contribute very well to this project. If you have joined recently and are pushing for change or if you're like outsourcing this to an agency, the results are only going to be as good as your specifications. We ended up with a list of over 100 use cases and requirements including user features, technical capabilities, back office functionality as well as licensing and support questions. But then it also comes down to your complexity and pro vision how flexible it needs to be by your use cases unique. We then looked at the market and compiled a list of platforms to review. The first two platforms without looking at the market we're obviously staying with Magento 1 and it's natural success to Magento 2.
Piotr Karwatka: Did you take professional reports like Gartner into consideration?
Halil Köklü: Yes we looked at Gartner Magic Quadrant, Forrester... It gave us a first impression of the platforms because most of them don't really give a lot of information on their websites and it's mainly sales stuff and you have to sign up, talk to them first before you get something out, potentially even have to sign an NDA. So having 30 platforms on the list, it was clear from the start that we have to narrow down the list by answering some fundamental questions like are we going open source, is it going to be software as a service, is it going to be API only, headless…? And I felt like this is where the implementation starts really. It is fundamental that the plan works with your use case, the surrounding stack, the business process but also the skills and budget. If you make these decisions early on, then you end up with just carrying out that implement that the paths you have defined while you were looking at the platforms so the implementation really starts quite early
Piotr Karwatka: And that's an interesting observation!
Halil Köklü: Yeah, so sticking on to Magento 1 was not an option for us due to the imminent end of life and also it would have required us to make huge investments in building APIs, sensor coders and views models and controllers... APISs would be new controllers so you would need to make sure that everything is working as before and it's outdated so you need to make it work with newer technologies um disclaimer for example PHP 7.2 goes end of life in November, so you have to do work to support 7.3, the dependencies would go out of um out of support as well, payment providers like edien are cutting support for Magento 1 merchants so all that is scary and risky. Then we looked at Magento 2, it seems natural, it's more developer friendly than before - with Magento 1. But we have decided against it and the and that despite the data migration probably being simpler so there you you can be quite sure that the same functionality is available one way or the other however uh the database structure and the challenges out of that are still identical i'd say so you need to do all the customizations and improvements again with the risk that it performs worse at the start so you need to do a lot of work to make it performant and then how is it going to scale with your future growth also Magento 2 I hear that argument a lot is Magento 2 can be headless as well but what percentage of the functionality is supported is there a list of this feature is going to be only if you use the front-end as well versus the APIs and also for example the marketplace modules - how many of them are available for APIs. It's all just very unclear and it felt like missing an opportunity here by just going to Magento 2 because it's a whole new rewrite if you don't get the benefits out of it.
Piotr Karwatka: To paraphrase what you’re saying: in your case upgrading to Magento 2 would be pretty much the same amount of work like migrating to any other platform…
Halil Köklü: Yeah, Magento 2 doesn't meet our requirements so we need to spend time building that functionality like we did over the years and I'm not talking about just some user features but fundamental changes and then also the performance question I raised earlier. So yeah I think so at least in our case
Piotr Karwatka: So is the software as a service and software as a service as a car the best delivery model for software in 2020 like a software that just works you can start using it would you recommend our on-premise platform for anyone in 2020?
Halil Köklü: That's a very good question that it's not simple to answer. There was one more in the list which was open source and that was sillies and it also didn't make the cut so there weren't any open source solutions left and so until now we were like thinking we need to run it ourselves we need to control it we need to be able to make changes so the first thing was that we struggled giving up access to the code and then the second bit would then be is it going to be on premises closed source on premises or closed source sas and i think uh if you have a closed source platform it rarely makes sense to it on premises which is in most cases actually in your own cloud account. It only makes sense if you don't trust the slase of the vendor because otherwise you end up like was monitoring configuring upgrading yourself and you don't really have a clue about the platform itself because you don't own the code but if the vendor and the product are trustable I think sas can work well however it's not straightforward still why is that i think it's a general sas issue um because if i recall correctly for us none of the sas purchases we made were without surprises or disappointments and by that time you have already invested so much time into it or you're tied to a contract that you can't change so you're committing yourself to something which might not work and they might not be ready to make changes for you to make it work to protect the platform so the team was pretty worried about this are you suggesting to move or the core of our commercial business into the hands of others.