how Evolve was built

Transcript

How Evolve was built: From bespoke software to a product-driven company in composable commerce

This transcript captures the full conversation between Anton Koval (Senior partner manager Commercetools) and Pim Vernooij (Co-founder of Lab Digital & Evolve) about their journey from a bespoke software agency to building Evolve, their composable commerce implementation platform.

Anton Koval: Welcome to today's session exploring the journey of building successful accelerators in the composable commerce space. I am Anton Koval, and I'm joined by Pim from Lab Digital—a team behind Evolve, a great accelerator which they call an implementation platform for composable commerce. In this conversation, we'll uncover how Lab Digital transformed from a bespoke software agency to a product-driven company, their partnership with Commercetools, and practical insights for agencies considering their own accelerator strategy. Whether you are a technology partner looking to scale your impact or an enterprise looking for a composable commerce solution, this discussion will provide valuable perspective on standardization, reusability, and creating competitive advantages.

So to start off, I would like to ask the first question to Pim: What are the origins of Lab Digital? How—what inspired you to start the company?

Pim: Yeah, so let me tell a little bit of background about our company. First of all, of course, thank you for the invitation to speak about this topic. It's very close to our heart, and we're really passionate about it. We started Lab Digital around 10 years ago—actually, it was our 10th birthday last week, so we celebrated it a little bit. We started out as a bespoke software engineering company. Me and my business partner Niels had worked together for around eight years at a different digital agency. Due to some organizational changes at that company at the time, we saw the opportunity to start our own company and build a company in which technology people can thrive, and in which we can build really great software. So in short, to build something of our own with our values embedded in it.

Anton: Okay, great. And so during the early years, did you start seeing some patterns or current challenges that you had with client projects?

Pim: Yeah, absolutely. So as I said, we started out as a bespoke software engineering company but also did a lot of e-commerce already. And we saw a lot of similarities between projects and clients. In the beginning, this was largely in the area of infrastructure—so cloud-native infrastructure and creating templates for that. So we built a large library of starting points for new projects, so things we could reuse for new projects. But also in terms of other developer tooling—so not only infrastructure but also libraries that make our own lives easier or make it easier to create tests, for example, for software. That's why we open-sourced a lot of those modules as well, so that we could reuse those across projects. So this has been in our DNA, you could say, early on.

Anton: And how did you decide what should be a standard or what is custom? Meaning, like, how do you decide on how this solution or this area or this feature is the one we should make more scalable?

Pim: So that happens usually when we see patterns occurring across different projects. I would like to say that your first attempts of implementations are usually not your best. So what we try to do is get experience in a certain area, and once we know a certain area, we then decide to settle on a certain standard and incorporate it in our standards library. But gaining experience in a real-world scenario and then porting it back to our internal standard is, in our experience, the way to achieve the highest quality. Otherwise, you will—the other way around would be to build something before you have implementation experience, and our experience is that that doesn't work that good.

Anton: And you mentioned you contributed to some open-source projects. So how did that start? Why did you decide to go that way?

Pim: So we saw this started actually, I think, in one of our first projects already. We encountered—this was with a bespoke software e-commerce project—and we deployed it to AWS. We're speaking 2015 now. AWS was—well, it was around already quite a bit. Terraform was fairly new, Docker was fairly new, and also the Docker support within AWS was fairly new. And we noticed that some tooling to properly deploy was lacking—it simply wasn't available. We wanted to have a consistent way of deploying across all of our projects, and that's why we decided to build a deployment library and open-source it, because it was lacking in the community.

Open-sourcing it makes it easy for us to reuse. It's very accessible. Other people can contribute to it if they find bugs, for example. So that's—it was really to solve a problem that we had, and the library was really suitable to open-source. Another aspect of open-sourcing is that if you don't do it, it will probably be replaced by something else because someone else will open-source it. So we were simply the first in this domain, and that's why we were basically able to expand the ecosystem with a tool that's useful for more than just us.

Anton: Usually when you contribute to open source, then that means that the developer could be working on a project—client project—but he's contributing to open source. How did you, especially initially when there are not too many projects, teams are not too big, how did you sort of justify for yourself the investment in open source?

Pim: Yeah, so this is typically—in the beginning, we typically did this for components that we saw really—for components that would be really reusable across many instances. So not just an individual client, but pretty much for all of our clients. And then we found justification for that. And in some instances, clients even contributed to building these modules because it's also in their interest if these problems are solved, but also if they are supported widely and other people use them as well, because it makes the software more robust. So this is also something that you be transparent about with clients on how you approach these things.

Anton: And you mentioned as well Terraform. So how would this approach sort of shape your thinking about this reusability of the components?

Pim: So then we have to take a step forward, I think, because you're talking about the Terraform provider for Commercetools, I think. So this is actually a great story. So we—I think we started with Commercetools around 2018, so three years after we started with Lab Digital. And we had a lot of Terraform experience already. And we had a use case—in this case, I think I believe it was Danone—where many different environments needed to be managed for them because they have a lot of brands across the world. They're available in, I think, more than 50 countries with all their individual brands. And the question was basically: Can you build a platform that can be rolled out to all of those with a mixed set of components?

And that's when we started thinking about: Hey, how can we deploy Commercetools this many times with slightly different configurations for each country? And our first thinking was: Hey, let's build some kind of a dashboard in which we automatically create stuff in Commercetools and then roll it out. But then we saw—when we looked closer at Commercetools, we saw a lot of similarities with cloud services such as the ones in AWS. Basically, they all have a configuration API which is managed by Terraform. So that's really what led us to thinking: Can't we apply the same principles using infrastructure as code and Terraform to services like Commercetools? So that's really where the idea was born—was due to a project we had for a client which had quite significant scaling requirements, and we needed to have a way to manage that as a small team, right? We don't have hundreds of engineers. Usually these types of projects are—and especially the configuration part—are managed by only a couple of people. Applying the right tool for the job here played a big role, and Terraform in this case was the right tool for the job.

We're really proud of the Terraform provider because as soon as we released it, it was also noticed by Commercetools itself. And it appeared that it had been a longtime desire of Commercetools engineers to have something like this. So I think a month after we started working on it, we were already in Berlin working with the Commercetools engineers on the provider, after which we released it and open-sourced it as well. And ever since, I think that many of the Commercetools partners and users are actually using the provider to manage their Commercetools configurations.

Anton: But then you came to a solution called MACH Composer. So how—what is that?

Pim: Yeah, so MACH Composer also tied to the Danone project. It's basically a configuration layer on top of Terraform that allows you to manage configurations of multiple sites. So a usual Commercetools project is a single site or maybe two, but in this case, we needed to manage 50. So what MACH Composer does is it takes configuration of a site and then generates the appropriate Terraform configuration for it to be rolled out. And this includes all things necessary in AWS—the cloud that we used at the time—but also the configurations needed for Commercetools. And we started expanding it into other areas so that we could also do configuration of a CMS, of Algolia, of several other cloud services—basically all formed together the composable architecture to manage all configuration of those platforms.

And what MACH Composer really brings is that you can roll out multiple instances of the same configuration where each instance is slightly different. So one instance could use, I don't know, Algolia as a search engine, while the other instance could leverage commercetools' built-in search as a search engine. And it allows us to differentiate, and it's open source as well.

Anton: Under MIT license?

Pim: Yes, yes, it's all MIT license, so basically anyone can use it and fork it and apply it. But it's really Terraform that does the heavy lifting underneath it. It's a simple layer on top of Terraform. And this is also why we are confident in bringing this into projects because some clients worry about being locked in to MACH Composer. But since it's only Terraform underneath, there's a simple eject scenario where you could simply swap back to Terraform and move away from it. So it's really a convenience tool of managing large-scale configurations.

Anton: Okay, and then from the open source—so you sort of trained yourself on open source, tried a couple of different approaches and features, and then we are now going to Evolve, sort of a more closed-source solution. So how did that transition happen?

Pim: So basically, the Terraform tools are all around infrastructure and configuration management—so getting the right APIs in place, making sure that services can discover each other, that for example a front end knows to which Commercetools environment to speak to, etc. And it has nothing to do with actual implementation. So it's really about plumbing and setting up all the necessary cloud and SaaS services and getting them in the right place.

But you still—we still in each project were building a complete front end, a GraphQL middleware layer, all kinds of backend integrations towards either SaaS services or on-premise APIs that already existed. And this was still a lot of work for us to do. And of course, we did some reusability here and there, but since a year or two, we decided to really double down on a product approach for all of that so that we have a foundation to start from for each project that consists of basically an entire front end for B2C and for B2B. It provides a middleware layer that does the API orchestration based on GraphQL and GraphQL federation, and it integrates with several SaaS services in the back end—Commercetools, of course, but also several other CMSs, search engines, payment providers. So those are really like the functional things that are included in it.

But we also provide hosting for AWS, for Azure, for GCP, so that there's a starting point for new projects. You basically have a complete running environment ready from day one in a way that it is pretty production-ready because it's highly optimized, it's super performant, it's highly secure. Especially—we took a lot of care for the developer experience so that teams can work productively on composable architectures, which is, I think, a really big thing because we're working on these distributed architectures with a lot of moving parts. To keep that—be able to grasp that and to work on it productively is a challenge, and we really try to solve that with Evolve.

So developers are still able to, with a single command, install Evolve locally, and with another command, run it locally so that you can start the work. So if a developer at Lab—a new developer starts—and someone has not done a pull request on their first day, then we think something is wrong. And this is not—we've seen cases where it took a lot longer to get to this point. So we try to optimize for that as well.

Anton: Was the idea of building this or getting to Evolve from the beginning, or were you sort of discovering as you were going that this is the way?

Pim: I think it hasn't been the plan from the start, but if we go back to our—when we started creating reusable software and components has always been in our DNA. So we always apply some level of reusability, and I'd say any SI would. But taking the next step and creating an actual product of it is another thing because that requires investment, strategy, and organization. It also brings expectations from clients and so that was not the plan from the beginning.

After we did, I think, three or four full-stack composable commerce implementations, we thought: Hey, this is an area that we can really build something in and build something that differentiates us as an SI. So that's why we decided to actually go for that.

Anton: And for agencies, it's often when they want to build accelerators, it's very crucial to make the right first steps. So as the one who already did it, what would be your good practices on avoiding mistakes in the beginning?

Pim: So I think one of the key things that makes Evolve successful is that we didn't build it in isolation without a concrete case. It was actually—we did a couple of client implementations before we settled on our standards in Evolve. So having that experience and adding it into your accelerator, I think, is really key because otherwise you're developing something outside of a real-world scenario. I think that's an important aspect.

And I think once when we decided to actually start pursuing this route, we tried to launch as quickly as possible. So the first use cases that we built with Evolve used a relatively small version of Evolve compared to what it is today. But getting to a stage where you're actually working with a client on it and learning from that and getting those feedback loops up to speed, I think, has given us a lot of tailwind because then people start to notice that it brings speed, clients become enthusiastic about it. Basically, it builds the confidence that you're on to something, and then you can start iterating on it further, maybe start investing in it more if you see success. But I wouldn't recommend like building an accelerator for a couple of months and then launch it. I think you should launch as early as possible. And we were able to do that because we already had a lot of experience and also other reusable components that we could leverage in Evolve with some refactoring.

Anton: And how did this change how the company operates today? So is there a specific person working on Evolve or a team? How is the sort of structure of the agency? Did it change?

Pim: Yeah, so in the beginning, there were two people, I think, who were focused on it almost completely—and primarily engineering, of course. But I think now, since almost a year, maybe a bit more, we're really building an organization around it that kind of acts as a company within a company. We also manage and track the metrics around Evolve separately from Lab Digital so that we know what goes in and what comes out, so to say. So we really—it's kind of a startup within Lab that operates slightly differently.

There are also different questions asked to us, right? Because you suddenly have a software product that clients want to know what the roadmap is, how they can influence that, but also being able to support clients outside of the regular project because we have some clients that implement Evolve by themselves. So you need to certainly build like a professional services organization. It's still very early, but we're starting to notice that that's required.

And of course, you're investing in a wholly different way than you used to be because before Evolve, we didn't have a structured way of managing, let's say, the R&D budget. The building reusable components simply occurred in the sidelines of projects or in preparation. And now we kind of have a vehicle for that with a budget that we can manage. So that's—it changes the company quite a lot. I think it's doing really well for us also in terms of being attractive as an employer and not simply building projects for clients but also having a product that's used for that. It's working really well for us.

Anton: Any like when the developers have nothing to do on—let's say they're on a bench—they're working on Evolve, or...?

Pim: We try to avoid that because I think the best people at Lab work on Evolve and transition from project work, basically, because we take the product super seriously. So we try to avoid working on Evolve as bench time. Of course, it does happen, but we see that that is a utilization problem of the Lab Digital agency and not necessarily of Evolve.

But if there's an opportunity where we think: Hey, this can really be really valuable if someone joins the Evolve team for a while, we of course do that. What we do see is, for example, with new people starting—usually projects don't start at the day that they join the company, so they have some time in the beginning of their time here at Lab that they're underutilized. And we noticed that joining the Evolve team for a while is a really great way to onboard them because all of our projects are basically built using the Evolve technology, so they share an identical architecture. And if you've worked on one project, you can probably work on most of our projects. So it's a great way into the company to learn about our technology stack before people actually join a project or client team.

Anton: Okay, and does it make you—do you see it makes you more competitive in terms of deals and getting more deals?

Pim: Yes, my impression is that because we have Evolve, we have a much better proposition towards clients than our competition. Some competition does have an accelerator but don't take a holistic approach like we do. And they have, for example, a front end or some reusable components, but we really bring a complete architecture, a developer experience that's production-ready. And this is really why we call it an implementation platform rather than an accelerator because it's a way of working, a way of thinking, way of organizing basically your entire platform. And I think that fact is really appealing to clients because it speeds up projects by quite a bit but also makes teams more productive on the long run.

And by having all these architecture decisions already in the platform, it eliminates a lot of risk in projects because if those architecture decisions are made in projects, that means that investigation is done, experimentation—you can't take it from the shelf, basically. And then in our case, you can. So it de-risks projects as well.

Anton: So why did you choose Commercetools?

Pim: So a little bit of background: When we started Lab, we were primarily a Python and Django software company, and we used a commerce engine called Oscar Commerce, which is open source and to which we contributed as well as core developers. And being open source, we had full flexibility, of course, over the engine, and we could build anything we want with it. And that's why we loved an open-source ecommerce engine so much rather than using one of the legacy monolithic engines.

But at some point, we came across Commercetools, and we noticed that the same level of flexibility and control over what you can build with it we found with Commercetools. So it was really comparable to the characteristics of the open-source engine, and that's why it was really appealing to us. At the time, we had two bigger clients that we were speaking to about replatforming initiatives, and we basically gave them the option: either go with us with the open-source route or with Commercetools. And both of them chose for Commercetools, and that's really why we initially chose for Commercetools.

I think, of course, we re-evaluate continuously whether it's still the right fit, and it is, of course. And that's because it's simply the most mature API-based commerce engine out there with a full feature set for building user experiences, but also the fact that you can manage any aspect of the platform with an API because this really allows us to automate everything with Terraform and basically build anything we want against it. So that's why we really like Commercetools as a commerce engine.

Anton: And how does the partnership evolve? So you started with a couple of projects, and how is it evolving?

Pim: So I think in the beginning, composable wasn't even a thing. So it was—we built like platforms using cloud platform and Commercetools, but nothing more. And then, of course, a lot of different SaaS vendors started appearing, and for every different part of the system, you would use a different SaaS system. So I think we transitioned from being a bespoke software-focused party to being really specialist in this composable commerce area. And Commercetools has been with us every step of the way, and we've kind of grown with you guys in this domain. So basically, we evolved into a specialist in composable commerce through Commercetools.

Anton: So you've got to the point where you have an implementation platform, you're winning projects with it. What is the future? What are you seeing? Like, how can you even further expand this or keep it as it is?

Pim: As it is, it of course already provides a lot of value, but we see a lot of opportunities, of course. And one of the interesting developments is that—well, there are actually two things. One I mentioned that parties—clients are using Evolve by themselves to implement a composable architecture. We have a—

Anton: So they don't use your services; they're just doing them themselves?

Pim: Exactly, yeah. So we have a company here—a client here in the Netherlands—they're called YourSurprise, which is also a Commercetools client. And they have their own development team, which is really mature.

The transitioning from a monolith into a composable architecture is, of course, a big and risky effort. And they saw in Evolve a way to speed up and de-risk that. A lot of the technologies in Evolve were already known within their team. So they were already using GCP, they're already using Algolia, Next.JS and React are already used in their team. So a lot of the technologies, I think, were quite accessible for them, and they saw an opportunity to speed up and de-risk their trajectory to move to a more composable setup of their website.

Anton: So how do you make that change? Because that feels like you are cutting your leg—giving a platform to a customer to implement themselves.

Pim: So we're not giving it away, of course. They pay a license for that, which is really interesting for us because the revenue from that we reinvest in making Evolve better. So I try to look at this as a way to also fund our own R&D efforts in this space. And in this case, maybe this company wouldn't have chosen for a composable architecture if a platform like Evolve wouldn't have existed. So I'm not sure if they were in the market for working with an SI but would always have chosen for a way that they could build it themselves. And this is simply a tool to make that easier and more accessible. So it's a bit of extra—new business for us, a new area.

Anton: So basically, what you're saying is that with—if you have such an implementation platform, you open up doors that you would usually never open.

Pim: You might say that, yeah. And another development—of which you are aware, of course, because you made the introduction—is that the fact that we're now working with basically a competitor of ours in the Nordics, which we feel—we're comfortable with that. It's not in our own backyard, and they requested if they could leverage Evolve as a platform to service their clients because not every SI or agency has the means or the willingness to invest and build a platform like this themselves. So this is a really interesting avenue for us because other parties can definitely leverage the platform to be successful with composable as well.

And I think in the future, if you build composable platforms, then having an implementation platform such as Evolve might become the default. I think starting from scratch for composable architectures is so much work, and I think standards will arise in that area. And I hope that with Evolve, we can play a big role in that. So this is a very interesting development for us.

Anton: Very interesting. And what is the benefit for such a partner in Nordics to use you? Because if we would put a standard agency founder hat, we would say: Okay, I'm using their solution, so I'm basically reducing my billable time. And then the other agency gets a benefit. So how does it work?

Pim: So I think by having a platform like this in your approach—well, the benefits that I mentioned already, like speeding up, de-risking, having a solid architecture from the start—they work in your favor, of course, if you're competing with other parties in an RFP, for example. But long-term, I think that doing a project without a platform like this simply isn't feasible anymore because it becomes more expensive. So it's only a matter of time, I think, until this becomes the default, and not having it would mean you'll probably outprice yourself for these types of projects.

Anton: Okay, and then are you open for other partnerships, or are you for now good with what you have in Scandinavia?

Pim: So yeah, we're absolutely open to that. As I said, we're not doing it in our own backyard just yet, but we're always open to speak to parties who might be interested in this around the world, even. I think the technologies in it that we use are widely adopted, and it's all built in a way that you can deploy it anywhere in any region across the world. And so we're absolutely open to those types of collaborations.

Anton: And for the agency that would like to build their own solution, how would you advise on balancing their financials? Like, how much should they invest? Should they invest a lot? It's always a very delicate balance. So how would you approach this?

Pim: Yeah, so to be honest with you, we started with this also because we believe in it. Of course, we have a rough business case for it, but we noticed that the more we standardized, the more successful we were with customers in terms of scoring deals. So it's also—in the beginning, it was kind of a gut feel that this is the right way to approach things. We're now a bit further in time and have a more measured way of working, let's say, and simply look at what we think is necessary to invest in Evolve to achieve our plans with Evolve itself. So it's part of our budgeting rounds, so to say, and we make really deliberate decisions about how much we invest in it or if we continue to do so.

I find it's very hard to put a number on it—how much it should be or how it should be balanced. I think an agency, especially boutique agencies, should always work on what makes them unique, and that costs money. And in our case, those funds go to a lot—a lot of those funds go to R&D because that's what makes us unique. Another company might have a bigger sales force, for example. We don't have a lot of people working on sales because we have a product that also helps us doing sales. So it's—you should ask the question: How strategic is it for you? Maybe that's the underlying message.

Anton: And what’s this like in terms of capabilities of the team? Do you just need developers for this, or do we need some other capabilities in terms of like skills of the team?

Pim: Yeah, absolutely. So of course, it starts with building a product, and that's highly engineering-driven. But as soon as you start positioning it more as a product, things like product management become important, marketing, sales, managing a pipeline. Basically, you're creating a company, and you need to have those functions.

Anton: You need customer success, as you mentioned.

Pim: Exactly, you need to have those functions filled. And it doesn't mean that you need to have a single person for each of those disciplines in the beginning—one person could handle multiple things—but that's the way that we're building it while also expanding, of course, the engineering team that works on it.

But you definitely need different disciplines for that. And being able to build this within Lab Digital, of course, means that we can lean on Lab for a big part. Like the financial stuff, we can leverage the HR department, we can leverage what we do in marketing. So we have a lot of things that are—and processes that are already in place that we can leverage. And you don't need it on a full-time basis, but we can simply use that. So try and use what you already have, I would say.

Anton: And when I talk to agency founders, often I hear—like the biggest—the ones who are just introduced to the concept first time, their first criticism is usually: Well, if I'll build something and give it to a customer, this will lower my potential billable hours and my potential profit from the project. So do you—from delivering a couple of these projects, do you feel the same way that it lowers your profit?

Pim: Yeah, I think I don't fully agree with this statement. Factually, it's true—your projects become smaller—but they will anyway because the industry is evolving, is innovating, and you need to basically keep up with that. I wouldn't say your profit declines because the—your implementation projects simply become smaller in terms of hours, but profit—I don't think profitability would suffer.

For us, it's a way to do more projects, but also to—at the stage where we're in now—I think we'll be able to deliver faster than the competition. So this means that the client saves money that they can spend elsewhere, preferably in innovation and stuff that we do with them, but that sits in an area that makes them unique rather than plumbing stuff together. So I believe in continuously delivering more value to clients through making stuff easier, faster, simpler—basically delivering more value for money as a company. I think that's a way to keep clients with you and to make them successful.

Anton: If you would have to start over, what would you do differently with the accelerator/implementation platform that you have today?

Pim: Yeah, so I think for us as an agency, it was kind of difficult or strange to ask money for IP, basically. We never did that. So if I would do it over—if I would do it again—I would probably start charging for Evolve earlier. In the beginning, we didn't charge for it, but when it becomes more successful and you see that there's demand and you want to invest more in it, then you need to find a way to fund that. And for us, that means that clients pay a license fee for Evolve. And I think we could have started with that earlier and could have invested more in it earlier and be more successful earlier. That's probably what I would do differently.

Anton: So you charge for the platform, but you also—there's also sort of implementation fee. So there are sort of two components of it, right?

Pim: Correct. So clients purchase a license agreement with us for Evolve, and with that, they gain access to Evolve and its updates. And then there's, of course, an implementation project. And most of the implementations are done by Lab Digital, but we have the first one commencing hopefully quite soon with an agency in the Nordics.

Anton: So with that, you are still more competitive in deals than the partners—the agencies that just do the full custom work, right?

Pim: Yeah, I believe so. Definitely.

Anton: So do customers tell you, "Oh my god, you're so expensive," or...?

Pim: We're not always the cheapest, but we deliver very high quality. And I think with composable projects, there's a lot of underestimation going on. And I think we're usually realistic in our estimations and not necessarily the lowest. And that's—I think also when you're experienced with a lot of these implementations, you know what it takes. But I think we're able to provide a lot of value.

Anton: This was great, and it was a great interview. So thank you for sharing so much of your knowledge and experience, and I think it was definitely interesting for our agency partners and customers of the different approaches you can do. So yeah, thanks a lot.

Pim: Thanks a lot for having me. It was a lot of fun. As I said, we're open to discussing about Evolve with anyone further. So if anyone has any questions, then feel free to reach out to us.

Anton: On that note, how do they find you?

Pim: So we have a separate website: evolve-platform.com

Anton: Okay, cool. Thanks a lot, then.

Pim: All right, thank you.

Anton: Bye-bye.