22. Pioneers. with Filippo Conforti

Piotr Karwatka: [00:00:00] Today my guest is Filippo Conforti, founder of Commerce Layer, a headless e-commerce platform. He started his career as a Python, Java, and then Ruby on Rails developer. Actually, he spent quite a few years as an architect Gucci.com. Reportedly it was a custom and pretty pretty monolithic Ruby based platform. Was it the reason that he decided to go full headless, founding a new e-commerce platform? I can wait to ask him about it.

Hi Filippo! 

I'm so glad that you accepted my invitation!

Filippo Conforti: [00:01:21] It's a pleasure! It's nice to be here. 

Piotr Karwatka: [00:01:23] Awesome Filippo. Do you remember your first job as a developer?

Filippo Conforti: [00:01:28] All right. Yeah, it was in right after graduating. It was 2004. I worked for a company that was called Space and we were building a product that was about managing museums.

Piotr Karwatka: Museums? How do you manage a museum actually in a piece of software?

Filippo Conforti: Yeah, it's actually, it's not the museum management. It's like delivering media to the museum, you know, some like media experiences to the museum. 

Piotr Karwatka: Gotcha. Expositions and virtual things multimedia and so on. 

Filippo Conforti: Right. It was very, very nice. The company is still one of the most popular in Italy and they power a lot of museums in Italy. 

Piotr Karwatka: Awesome. What are your key flashbacks about software development in the early two thousands? 

Filippo Conforti: Well, yeah, I would remember that as a developer, you, so the feeling was to get some kind of superpowers, you know, you could still build pretty much everything, you know, and I used to spend a lot of time brainstorming ideas with my fellow engineers. You know, we could build this, we could build this other product or this idea, you know, every day was another idea.

Piotr Karwatka: So it was like feeling super powers. You can change everything, right? You started here Ruby on Rails developer's career around 2007. I remember those years very well. I mean, Rails was a hot topic. How did it change the way software was built?

Filippo Conforti: [00:03:07] Oh, well Rails really brought fresh air in terms of simplicity and, you know, especially to build prototypes, so it was so easy to create an application and web application from scratch.

And that was the number one reason why a developer approached a framework like Rails. I especially remember Rails, especially for the fact that they brought testing and development in the core work flow. Before you know tests were something optional, something that you eventually did afterwards.

And With Rails I still remember the first ebook, it was like Java web development with Ruby on Rails. And, you know, there was a tutorial and there was a Test-Driven Development (TDD) approach in the very first chapter. I still believe a lot in the TDD.

Piotr Karwatka: [00:04:03] Yeah, the book was great. With Dave Thomas, the foreword by David Heinemeier Hansson.  A lot of people were formed by this book, the development process described in this book. And I totally agree with you, you are right that the unit tests were part of the scaffolded structure generated by the CLI. So I think it changed the way people think about the software. But I also remember that this scaffolding, as great as it was also pretty much magical for me. Like it was a lot of conventions over configuration and this kind of stuff. That's that's one point, but there is another point.

I mean, the simplicity and efficiency of Ruby stack. There is no free lunch, right? There, there is a cost. What, what was the biggest cost of this simplicity for you? Especially after building the software for quite a few years? What were your observations and how it would involve the development process?

Filippo Conforti: [00:05:14] Yeah, so I I totally agree with you that there is no free lunch here. And when you start building with Rails, you start using scaffolds and it's all so simple. But I think that the issue with many Rails developments was that many Rails developers didn't know Ruby, you know. Rails is not Ruby. Ruby is not Rails. Rails made Ruby very popular. But Ruby is different from Rails. Rails is just a Ruby gem. And if you want to build Rails applications at scale, you need to learn Ruby, not just Rails. you know Rails brings the magic and also the velocity but you need to know Ruby and the optimization , database optimization, everything you do with the old languages, you know, with those stats is not excluded by a Ruby on Rails stack.

Piotr Karwatka: [00:04:03] Yeah. That's a fair point. I also noticed that in Ruby on Rails apps, everything is pretty much tightened up. In the end it's monolithic architecture, right? 

Filippo Conforti: [00:05:14] Yeah. Yeah. By the way, in those years, the monoliths made sense to me, you know. You built the monolith, and if the model is what was built in a good way, you know it really made sense also the rates brought APIs other than, you know, the test driven development.

So when  you did the scaffold with Rails application, you know you, you also got different end points for APIs. And that was another very interesting thing, but it was still optional, you know, something that you could eventually add to your application. Starting from Rails 5, it's an API only mode. So you can create a new Rails application that is, you know, built to power an API.

Piotr Karwatka: [00:04:03] Gotcha. Makes perfect sense. When you joined gucci.com, was it already implemented using this tech stack? 

Filippo Conforti: [00:05:14] Yeah. It was a Ruby on Rails application. I'll tell you one of the reasons why I was hired by Gucci in 2011. I was one of the few in Italy who had some experience with Ruby and Ruby on Rails.

And we actually spent, because the platform was built in the United States, we spent quite a bit of time in New York. It was really, really cool to be honest. 

Piotr Karwatka: [00:04:03] Awesome. So it was fully custom software or was it based on some platform? 

Filippo Conforti: Fully custom software. And actually it's interesting because we followed that jamstack light approach because it was not a standard Ruby on Rails application. We used Rails at least for some pages, you know, for the category pages and product, we used Rails as a static site generator. And we deployed using the operating the dynamic content on those pages through JavaScript. So it was kind of an early jamstack approach.

Piotr Karwatka:  Interesting. It's mostly because of the performance. 

Filippo Conforti: Exactly. Absolutely. Yeah. I remember that we ran gucci.com had a high traffic e-commerce and we could run it with really small servers as the origin servers. And then it was deployed you know, static pages deployed.

Piotr Karwatka: [00:08:56] Gotcha. Perfect. What do you remember from more working on such a, you know, huge in the end monological application? What did your job look like back then? 

Filippo Conforti: Yeah. So firstly, it was the experience with which it was really exciting because it looked like a startup environment in a global brand. So I had the possibility to work with a global brand of the likes of Gucci. With an amazing team, but the environment was really a startup like environment. I learned a lot about enterprise software software in general and especially enterprise because Gucci commerce was a global commerce with different regions and each region had different requirements. And so it was you know I learned, I really learned a lot about this aspect of e-commerce. So the internationalization. 

Piotr Karwatka: Gotcha. Wasn't a problem for such a, you know, dispersed architecture. I mean a globally rolled out platform with many different forks, customization features specific to the markets and these kind of situations that are you know very typical to such an architecture. Wasn't that a tough job to deploy the next features? I mean, it was still monolithic, right. So it was a big bang deployment I guess. 

Filippo Conforti: Yes it was. Because also, you know we should be very careful in deploying the next feature because yeah, it was a monolith that powered and all the, you know, the international eCommerce website.

Piotr Karwatka: [00:10:44] So. I'm asking such a question because I'm heading towards headless. There are no the Commerce Layer is all about, and I just wanted, you better understand the, the background for, for this platform. And actually that might be a good next question. Was this experience with monolithic architecture, pushing you towards headless, or maybe you just we're quite happy with this architecture, and Commerce Layer was answering totally different needs? 

Filippo Conforti: [00:11:25] Well, it actually pushed me to this architecture because part of my job (especially when we replatformed the Guggi.com e-commerce) was to interact with the agency. So there was the marketing team who worked with an agency, a digital agency and they designed a complete experience. And then we had that platform, a backend platform and in order to make the two layers work together, my role was to interact. You know, I was at the edge of the backend platform, interacting with the agency and building an API layer on top of the monolith to unleash the creativity and the design that was built by my agency.

Yeah. So that, that was definitely the moment  when I really thought you know why shouldn't be this way natively? You know, why shouldn't the backend just expose an API so that the front end developers and their best digital agencies can innovate and can work and can build whatever the customer experience they want.

Piotr Karwatka: [00:12:41] Gotcha. That makes perfect sense. So let me paraphrase. What you said is something like the need for headless was mostly to lead the front end folks, the creative team works at their own pace. Not being limited by the backend development, right. To separate those two concerns. 

Filippo Conforti: Yeah. That was the number one driver for sure. 

Piotr Karwatka: Gotcha. So how did you found the Commerce Layer? Do you remember the day you started the company or maybe the idea came to you? Tell us more about the beginning. 

Filippo Conforti:  [00:13:24] Yeah. So first I tell you a fun fact. So the name Commerce Layer comes from an idea of creating the like the 8 OSI model layer, you know, so. Like initially it was like a side project of mine, it was an Open Source project and they wanted just to build an API for commerce based on the experience they had. And so trying to create a model, you know, a model that made sense. And with no assumption, essentially, you know, so this was the idea.

Then it came to onboard the first client and I realized that in order to make this project a product we needed to do something different. So I created a backend application, an Order Management System. So the very first version of the OMS that comes with Commerce Layer today. But yeah the core is still the same, the core of our product is still the same common layer is an API, and then we can build, we and our developers can build around these this API to, you know, to create some sales channels, to create some integrations. Because by the way, it's not just about headless because the headless is only the front end part, which is a gain number one driver. And it's probably the most important part. You know, the most the main benefit of going headless. But it's not just about headless.Iit's about API first. So you know, it's not just a headless commerce application with you know, with some API. It's an an API first platform on all directions.

Piotr Karwatka: [00:15:15] Gotcha. Makes sense. So what's the business model for Commerce Layer? 

Filippo Conforti: [00:15:21] Yeah, it's usage-based. I like to think of  Commerce Layer as an order machine, you know? And soit's like when you purchase a bandwidth from a CDN you get charged by the bandwidth of the CDN itself. Our bandwidth is orders you know. We charge based on the order numbers. We don't go into revenue share because we know from our own experience that especially the larger brands, don't like the revenue share model too. Absolutely. So its based on the usage is mainly based on our desk, then there are other metrics, but again it’s not the revenue share model.

Piotr Karwatka: [00:16:08] Gotcha. Interesting. And who's the main client, I mean, of course retailers, other folks entering e-commerce, but on their side is like CTO or CMO?

Filippo Conforti: [00:16:21] I'd say more the CTO.  We are a developer first platform and we want to keep this focus on developers because we really think that you really want to become a developer too, you know, to create. And there are so many ways to build commerce nowadays. You know, itt can be a website retaining a social channel. It can be integrated, you know, just the form with a forum, for example, or a Google or whatever, you know? So we really want to become a kind of commerce operating system for developers so that they can build on top of our platform.

So the CTO, in general engineers and technical, tech-savvy people are more our clients. You know, our client, I mean, the, we signed the deal with the contract with the brand, but as you know let's say, our positioning is more developer-first.

Piotr Karwatka: [00:17:18] Gotcha. Do you think that you need to educate the market? I mean you, you said CTO’s, developers, they absolutely get your idea and architecture and the benefits, but. The folks that are spending money on the retailers side are very often marketing folks departments. They have the budgets and do they expect to have a “batteries included” product buying the shop platform?

Filippo Conforti: They sometimes do. So in general did the promise of you know, of providing a monolith that does everything you need is very appealing, actually, the marketing departments or executives, because they, you know, they have the idea of purchasing one product that does everything and let's see it, you know, it's very easy, you know, maybe the cost is higher, but maybe they don't care because, they are looking for something that just works.

I mean the model is monoliths you know, 10 or 15 years ago made a lot of sense. But now they can't live up to the shopping experiences that the brands want to deliver to the customers.

So to differentiate. So I think, yeah, this is the reason why the headless approach is becoming so popular. And to answer your question. Yes, we, we need to educate the market for sure about the brands, because they know that they need to go headless. Maybe they don't know all the benefits that this can provide them.

I think that we should also help develop us understanding they had this better. Because not all developers are created equal, you know, so some in my experience, when a developer approaches Commerce Layer, they get the benefits, they get the API. I mean, we don't even need to explain too much about how we work.

‍

(...)

‍