Sebastian Rindom, Medusa.ai CEO Interview | Craft of Open Source Podcast

Check out our open-source Feature Flagging system – Flagsmith on Github! We’d appreciate your feedback ❤️

Episode Transcript:

I have Sebastian Rindom with me, who founded Medusa, a headless eCommerce store doing great traction and growth on Github. We were super interested in speaking to him.

---

Sebastian, welcome.

Thank you so much. I am super excited to take part.

Do you have some experience in the eCommerce space prior to Medusa?

That is correct. The story behind Medusa is that one of my Cofounders, Oliver, and I had this agency while studying at a university where we worked with a bunch of clients, and among those are a lot of eCommerce companies that employed our services. We learned a lot from that. At that time, we mostly did WooCommerce stores, Shopify stores, and even a bit of Magento.

We got around the block and found out that building eCommerce is about the client asking for something, and then you, as a developer, find out a way to make it work. The client is happy because they can see that the feature they asked for has worked. As a developer, it hurts your heart a bit because you know what is going on behind the scenes. It is more of a hack than real software development. We were super lucky to have this one customer that wanted to go the bespoke route, and that gave us an opportunity to build the software that we always wished existed. That was pretty great.

You were building sites. Are they not API first platforms, Magento, and things like that?

Yes. Many of the tasks we had were something like, “Make my system speak to X system.” Those are ERP integrations or analytics integrations. That exposes you to the APIs of these different solutions. In other cases, we also had customers who wanted to have customized experiences on their site. At that point, it can get a bit tricky depending on the solution you are working with but also how well the API is designed to accommodate these customizations.

You are building these sites. Have you got fractured technology platforms in terms of different things that you are building on top of seeing common problems amongst your clients?

The most interesting class of problems was that a customer would ask for a feature, and then we would go ahead and implement it. It would work, and they would be happy for a short time. They would come back to us and request some addition or change to that feature. We always had to redo all of the work because the only way that we could make it work in the first place was by doing some hacky solution because the platform was not created for the purpose of making that feature work. It became more of a trick than supporting the feature in a native way.

I remember working with this customer who was doing customized bikes where you could change everything from the saddle to the wheels. You can imagine the number of combinations that were possible with a solution like that. I cannot remember if it was WooCommerce or Magento, but the platform itself did not support these add-ons or customized features in a nice way.

When we had to stick this custom product together and add it to the basket, it quickly became this hooking into a number of different steps in the add to basket process. We had to make sure that the business logic was keeping its integrity throughout. When they were doing new features to this customizer, we ended up doing way too much work compared to almost building it from scratch. That is an example of the problems that we come across often.

I have installed Magento a couple of times way back, and it is a pretty crazy platform. The database schemers are out there, the existing open source landscape. Am I right in saying it was very much around deploying websites? You install WooCommerce, hit run, and you have got a fake store somewhere.

Yes.

You are trying to target because the world and eCommerce have changed a lot. Is that a lot of what your agency was doing?

If we had to sort in phases of eCommerce at the beginning of eCommerce and online commerce in general, it was only for enterprise-level companies that had lots of resources that we are able to employ expensive solutions to sell online. As things moved along, we got more people interested in also being able to sell online.

With people knowing anything about how to build a website or what HTML was, it became very much a necessity to be able to both offer the frontend and the design of the website with the functionality that makes sure that when the order contains $100 worth of goods, then the payment also made for $100. All the business logic and the storefront itself have to be coupled together in a nice way so that you can get started easily without too much concern about what is a server, storefront, and stuff like that.

What then happened was that we started having mobile devices and things like chatbots. POS systems were also a necessity because all the eCommerce companies that became big wanted retail locations. The need for being able to sell in multiple different places, but with the same centralized system that makes sure that everything is kept correctly and the inventory levels are being handled. That necessity became a lot bigger, and those APIs started building out.

There was no solution that decoupled those things. When people start building APIs to make sure that you can also use your solutions in different locations, in your mobile device, or your POS system, the way that the APIs are going to be designed is with a very deep-rooted DNA in the coupled world where the data is also the representation of how it is being displayed in an eCommerce website. That introduces some complications when the shopping experience is not necessarily the same or comparable to how it would be in a traditional eCommerce store.

Were you influenced by the headless CMS world? That started to solve these problems several years ago.

We had this one customer who wanted to go a bespoke route because they wanted multicurrency support. They wanted to have a platform that they could grow with over time. They were very ambitious about where they wanted to be. From the get-go, they wanted something that could support them throughout the lifetime of their business.

We started building a platform as if it were going to be this one huge platform with a fulfillment system and order system, everything you could dream of that a traditional eCommerce platform and CMS system would have. We realized we could not do all of this well at once. We started picking stuff apart. Every time we had to do these things, removing the CMS system, for example, we had to think in the abstractions necessary for any CMS system to be plugged into Medusa.

As we went along and removed parts of the core repository, we added in different abstractions instead. If you want to work with Contentful, Sanity, or Strapi, you can do that. The first time that we learned about headless was through the CMS systems because we were having so much trouble with both building all the business project that has to handle eCommerce experiences while also having to think about how we are going to make it easy for our clients to also manage their pictures and front page.

The notion of headless came with us finding headless CMS solutions. We did not realize that what we were building was headless eCommerce. We started picking things apart. Someone came to us and said, “You are building headless eCommerce.” We realized, “That is true.” It was never the goal from the get-go. By iterating on the product, we came to realize that the best architecture for eCommerce platforms that have to live for a long time is this modular and headless approach.

The design of your entities was you making use of a lot of the experience you had and doing this over and over again.

Yes. Every time we had to take one of these things apart, we were always thinking in abstractions, “What if our client wants to move to the upgraded version of the integration they have? How are we going to make that super easy?” The goal from the client-side and also the requests that they had was, “We want to start with this ERP system, but we know that over time we are going to grow out of the ERP system and move to this system instead.” Being aware of the fact that eCommerce-based businesses and their demands for their stock that they change over time made it for us to also anticipate how we can design in a nice way that will allow this in the future.

These are big platforms. This is not something you put together in a weekend.

That is true. We have been working on it for years but have only started talking publicly about it. We have been battle testing it and working closely with our clients, even sitting in their offices to make sure that we would be there every time something could go wrong, ready to figure out what and how we could improve going forward.

Let’s talk a little bit more about open sourcing. You are in Copenhagen, Northern Europe, ground zero in some ways. That part of the world is very pro-open source advocates. When you started writing that code, were you being paid for it by your clients?

We love open source. It is amazing that we can share code with everyone across the world and borrow from others. It is a huge benefit to innovation in general. With that said, it was not like we started out building this and thought, “We are going to build something that is open source.” We realized that the best way to build eCommerce architecture would be headless, and we need to make it possible for the merchant to take control of where they are going and what direction they are moving in.

That was the point in time where we wanted to open source the code. What this enables from a merchant standpoint is to be able to take control over the code, direct the product development, and add your own customizations to the codebase. You also do real software development versus hacky integrations to a close source platform.

That distinction is powerful because when you start owning the software development cycle, you also start owning the real value that you are creating. You are in control of that value because you ultimately own the code. As we have seen more and more companies realizing that if you want to be a digitally native brand or direct-to-consumer brand, you need to have a pretty strong tech department. You will also hire internal software development developers.

For those types of organizations to be throwing so much money where your integrations could be shut down from one day to the other is a huge risk. Ultimately, the value of that goes away. This was when we decided to open source it. We wanted to focus heavily on the developer experience, not only for ourselves but also for these merchants hiring in-house tech departments to make their lives easier and make them more powerful.

Was it hard to persuade them to go with you on that journey? Was that something that you had buy-in from them straight away?

One of the other benefits of being open source is that when you have multiple people contributing to the codebase, you have a lot of users, free, and people can add to what you are building. You automatically get the benefit of being more robust. As a merchant, they were super happy to make this platform more distributed and make sure that people could battle test it even more than what we would be able to do with the small team.

You have had quite an organic journey rather than some grand plan that you started on day one. At what point did you start to sit down and think about how it could be a successful business in an open source project, how that worked in terms of the IP rights of the code, and your existing customers? Those are quite potentially thorny problems.

We were a bit naive, being young founders who have never had to dance with funding and stuff like this. We did not realize that what we were building was something from which other people would benefit a lot. We started slowly opening up to a couple of our friends, showing them what we had been doing, and having clients referred to us through the other clients we had. At that point, we realized that there might be something here that would make sense for us to go even more dedicated to the mission of building Medusa and not building features for all of our clients.

It was at that point we realized that we should spin this out into a company in regards to IP rights. When you have a Medusa project, you install a core NPM package that gives you all of the API functionality and all of the core business logic. You get all of these abstractions I have been talking about, the different defaults where we have made decisions about how to calculate taxes, for example.

After you have installed that core package, where to go from there is up to you. You can rip out that tax calculation strategy and then put your own, or you can add plugins that interface with our abstractions to make sure that the custom functionality that you need is there. You have the open source project, which is the core API, the core NPM package.

That is what we are building that has the MIT License where you can do whatever you want with it. The individual merchant projects are the merchant’s own code. If they want to open source it, sure, but usually, that is not where they want to go. There is still a quite clear distinction between what is open source and what is not open source in this regard from a merchant perspective, at least.

How did you go about figuring it out? Can you explain a little more in terms of how it made sense to spin out a business? What were your thought processes around how to build something sustainable that can pay you guys to work on and build it?

What you are asking about here is how we are going to make money in the long-term. We were still young founders and did not know what we were getting into. From the beginning, we thought that we had to figure out a way to monetize this as quickly as possible because if we do not do that, then we are going to die. We realized over time that there are investors who would give you money, be able to build the product, focus 100% on that, and figure out how to monetize down the road. We went the funding route and have gotten investors on board.

That has allowed us to focus all of our efforts on building the product as well as possible, focusing on getting the developer experience nailed and making sure that everyone that picks up Medusa has a great experience. That has been powerful. The way we want to monetize down the road is by growing this community around the open source project, making sure that everyone will tell their friends about it, and growing the community.

When we have that community, we are going to figure out how to monetize by adding services that people would pay for. The idea is that if you take the whole ecosystem of Medusa, what we want to do is capture the value of 10% of that ecosystem, not necessarily taking everything to ourselves. That was also one of the reasons why we went with the MIT License.

We would love to see other companies build with Medusa as the order engine in their software. If you are a company doing restaurant tech and need an order module, you would reach Medusa, build this application, and monetize it without worrying about paying us. Everything is focused on building a great community. We are going to figure out how to give services to this community in a nice way.

You have built an order payment fulfillment obstruction thing and it does not have to have a web store on the front end. It could be a restaurant. It is funny how these things bubble up. It is tremendously powerful. In the funding route, is it an industry that you are not going to be straining for ideas of things that you can monetize?

There is a pretty clear path to how we would be able to monetize through hosting services. As a matter of fact, we have created the blueprint for how we wanted to create a hosted solution for this. The goal is to have it released by the end of 2022. The reason for going this route is we focus a lot on the developer experience. We want to make it very easy for people to get started and have a great experience with Medusa.

We often encounter this friction of figuring out how you deploy a server and make sure that the infrastructure is configured correctly. By being able to offer that out of the box, you superpower the developer experience even more and make it less or more frictionless for the developer to get started. That is a way that we want to explore. That is the first idea that we have.

Let’s talk a little bit about the S word. Your GitHub description as the open source Shopify alternative. It is interesting thinking about it because Shopify is a juggernaut, elephant, gorilla, whatever you want to call it. They are massive. In the shadow of Amazon, they still seem the challenger brand. You’re rooting for the storefronts that they are powering. It is a nice freebie that they get. Everyone still thinks they are mom-and-pop stores. Talk a little bit about that. You are encountering that problem from a completely different direction. Have you fought the urge to, “I want my customers to be able to press a button and have a default beam of all front end to peer?” That must be a difficult pull.

To make it clear for anyone reading, we do all of the backend stuff, business logic, everything that happens on the server. Generally, we don’t touch the front end.

Is that by design?

Yes. If you start a Shopify store, you will get a website up and running immediately. That is not what you get. With Medusa, you get the engine that can power your eCommerce experiences. It is up to you to decide if that happens on a website, app, or wherever you want it to happen. It is by design that we have chosen to go and focus on, exclusively building the engine and making sure that the APIs are nice and comfortable for anyone who wants to use it in whatever storefront they want to implement it into.

To address your question about if we have had to fight the urge to build this one-click experience, yes, we have. It would be nice to be able to give the customer the experience of going onto a website, clicking, getting started, and then having both the storefront and the server there. The reason we have not done that is we are still very much focused on making sure that our APIs are incredibly good. That is the most important thing for us.

What we are seeing happening is that there are so many companies coming online for the first time. Coronavirus has accelerated this a lot, with a lot of companies realizing that online sales should be a primary sales channel and not thought of as a secondary sales channel. The fact that so many companies are coming online and these companies also being a much more varied group makes it very hard to design great experiences for this group of companies.

We can make decisions about what we think would be a good shopping experience. We would probably come up with a three-product grit with the option of clicking an image, getting to a product page, and then adding it to the basket. We have some checkout flow that we have designed. If we do that, we also strip ourselves from being able to cater or at least show that we can cater to a much more varied use case spectrum. The reason that we have not gone this route is for this exact reason.

Your users and customers’ community are developers rather than people who are selling whatever in Shopify.

There is also the fact that so many different frontend frameworks are being created now. If we make the decision about which frontend framework you should be working with when you get your Medusa store up and running, then that locks people in a bit. It restricts them from what they would be able to create otherwise or at least makes it harder for them to create something that would work better in their case.

Instead of making decisions about that, we try to stay away from it. We encourage people to do starter templates. We have our own starter templates and different frameworks that you can get started and play around with. They are generally very bare-bones and simple to get your curiosity going.

You push a bunch of codes to a GitHub repository. What did you do, and what happened? Were you surprised at the response? Did you work hard trying to market that, or did it come naturally?

We were around on the 10th of September 2021, after having spent a summer where we were doing a lot of product development and pushed a lot of new features. We were sitting around and like, “Maybe it is the time to tell people about this.” You keep postponing that date because you can always think of more things to add. We were a bit reluctant, but we ended up deciding to make a submission on GitHub or Hacker News for the project. We submitted it, looking at each other and saying, “It is not going to be anything.”

A couple of hours afterward, we start getting text messages from our friends. They are saying, “You guys are on the main page.” We all had to double-check. I was at a dinner, and everything was a bit hectic. What was even more impressive or shocking to us was that people responded to it in a nice way. They were saying nice things about it. They could see the ideas. They understood what it was that we were building. Looking over the comments on the Hacker News post there, we realized that this is something that people want to pick up.

After that point, we started slowly realizing that we had to do a bit more in the marketing area. Every time we do something, it is always rooted in the product itself. Either we write guides about how to get started or a blog post about if we have done some new feature that needs awareness that we want to tell people about out. It is very much still focused on the developer experience and the product. Given the fact that we are mainly focused on trying to make developers more powerful, it also makes a lot of sense to keep it that for the time being.

What tools have you used to manage and grow that community?

We have set up a Discord server where people can join in, and in there, they would be asking questions and showcasing their projects. We also do community calls from time to time where people can call in and ask questions. We can give ideas about what we want to be building over the next period of time.

Is it in this quarter as well?

The way we have been doing it has been over Zoom for some of them, but then we have also been testing Twitch to see how that format would be. We are still trying to figure out the best approach to doing this thing. Hopin or these conferencing tools would maybe make sense in this regard. The most important thing here is to get the format right so that we can make sure that the community is engaged and they can ask questions and come up with ideas without it getting too technical about how to get started with that.

In establishing the level of abstraction specificity around these API interfaces, I would expect that people have very different opinions about where you should land in terms of that. How have you managed that? The horror story on these shows is someone gets out of the blue a 10,000 line pull request that is going in completely the wrong direction. They are like, “I wish I would have found out about this sooner.” I can imagine you would be potentially quite susceptible to that.

It has not happened yet that this type of work gets PR’d. At least from the abstraction level, it is still very much the core team that makes decisions about this, with inputs from the community to make sure that the use cases are also being served in the correct way. In general, we think very long and hard about how to write the abstractions in the correct way. We also think about, “What if this abstraction is not the correct way of doing it? How can we then make sure that we can still recover from those situations?”

We have two levels that we operate on when speaking about abstraction. One is the abstraction interface level, where if you are building a fulfillment plugin, we expect that the fulfillment plugin will be able to create fulfillment operation and return operation. We also sometimes have to make decisions about ways that we think would be the correct way of doing a tax calculation, for example. In those situations, we not only provide the tax abstraction layer, but we also provide a strategy that you can override, customize, or change in order to make it possible for you to hook into those areas where we have made decisions on people’s behalf. We have strong defaults. That’s the idea.

If those defaults for some reason fail, we give you the option of picking it up and changing it without everything breaking and you being in a situation where you cannot upgrade your packages. That is the approach that we are taking. This is something thing that we have only started working more aggressively on over the past couple of months. Over time, the idea is that everything from the order layer to the product layer to the way that we handle payments should all be abstractions where we have some defaults that we give you. If you want to break out of those defaults, you have that option.

How do you figure out what to work on next? I would imagine globally that there are hundreds of payment gateways. There must be more than that number of fulfillment centers and logistics platforms with impenetrable APIs. How do you figure out what to do next?

One thing about eCommerce is when it comes to things like payment gateway and fulfillment solutions, everything is very localized. In Denmark, there are certain fulfillment providers you want to work with that are not necessarily the same as the ones that you want to work within the UK. It is very much a question of, “What does it make sense from our standpoint to build as a plugin?”

If someone needs something else, either they go out and build it themselves, or we can help and assist in that process. The point that you are making here is there are so many options that we cannot make sure that everything is integrated straight from the get-go. We are very much aware of that. That is also why when we design the abstractions and interfaces, we think long and hard about how we can make it as easy as possible to do an integration with the X fulfillment solution.

Usually, it is not more than implementing a handful of functions in a class, and when you have done that, then you are ready to go. This was something that we realized a lot when working with these clients that were growing over time that the demands change all the time. Every time they hit the next milestone, they have to move parts of their stack around. If they do not do so, they lose a lot of opportunity costs. Being able to integrate with new solutions quickly and easily and without long re-platforming cycles makes it even more powerful. It is part of the abstraction layer.

Have you had any problems or problems? Are you constantly saying no to people who ask you to build a store for them?

With the background that we have where we have been working with certain clients and come in and have friends who want the same solutions, we have situations where we have to say no. Usually, we work with other agencies to hand these customers off to. They take on the implementation phase of storefronts.

We have a lot of ideas, knowledge, and things that would work for many cases. Sometimes it is hard not to be able to share that or not get the opportunity to share that and follow the process all the way through. Having these agencies that constantly provide us with feedback where we can have a foot in the door in the implementation process is helpful for us and great for the agencies.

In terms of the componentization, did you spend a lot of time arguing with each other about monolith versus micro-service? If I build a Royal Mail fulfillment plugin which is a UK organization that tries to deliver your parcels, is that something that lives in your main repository? Can you talk a little bit about that design?

When you start a Medusa project, what you do is install the core NPM package into your node project. When you are ready to go, you deploy that project somewhere, and all of the plugins and code live on the server that you deploy. In that sense, we take all the plugins and translation code that lives right next to the Medusa project. This gives the benefit of making sure that the integrity of your data is there and not having to worry about dealing with server outages on 1 or 2 of the micro-services that you would be operating with. It is not possible to host it in a micro-service way. It would require a bit of more work to make that possible.

We have people in our community doing things like this where they take the core repo, break everything apart, spit them into different instances, host those instances, and make them communicate with each other. You can do both. What we generally recommend or at least make possible is to do it in this centralized hosting manner where everything can go. That is fairly easy. It does not require too much work. If that pattern does not work for you, there is nothing that stops you from going another route.

Looking at your code, you have got a packages folder like Stripe and PayPal payments. Is that something that you are planning on having the ability for me to write one of these packages hosted separately from your repository and bring it into my platform?

You could do that. You could start hosting your own service somewhere. What we would require you to do would be some translation code or a small plugin that would be able to interface with that service. If you are building your own payment gateway, then you could host that wherever you want it to be hosted, but make sure you are communicating with your own service in the correct way. You have to build a plugin that can translate your service to what Medusa expects. That is the client side.

How did you end up building this on a node? Do you like writing JavaScript, and that is why you chose it? Was it a more natural thing for people to work with?

In general, we had experience with a handful of different languages when we started building. We always liked how moving from the storefront to the back end was not too much of a mindset shift. Being able to run JavaScript on the backend felt nice and easy. That was the reason that we went with it. It did introduce a couple of complications like not having type safety. We have slowly also started migrating everything to TypeScript. Luckily, we get that. It is very comfortable, and most web developers feel quite well with working with JavaScript.

We have had the same thing. We have been slowly moving everything to TypeScript as well. It is frustrating that it was not invented years ago. A lot of folks are going in the same direction. Has there ever been anything that surprised you in terms of community engagement? Did there anything out of the ordinary happen that you never expected?

Honestly, we never expected growth and the interest from people. That is the main thing that comes to mind when you ask this question. We have been sitting behind a keyboard, thinking long and hard about building products and making sure that things we were creating were cool, but we did not think too much about its business angle. We are not aware of the fact that this was a problem that other people also had. It is very much the community growth here that is interesting and has shocked us the most.

I keep thinking about what will be exciting to see when we start figuring out how to monetize this and figure out how we can put it into the hands of even more people and evolve. We have a pretty clear vision about giving people the option of getting started with Medusa straight away like you would with a Shopify store just without the storefront, but getting started and moving along as any other eCommerce business would.

When you get to that point where you would usually be having issues with Shopify and start looking to other solutions or having to do complicated integrations is when you will be able to break out of the hosted solution or get your code that is powering your Medusa store. You would be able to do all your customizations and still host it on the same Medusa cloud offering. You have the same project at the core at all times. Once we start giving that ability to people, I am going to be excited to see both what people will be able to do and how that will affect the community around our project.

I want to thank you so much and say a word because it is a cracking rate of progress you are making. It is one of those products where you’re like, “That should have existed.” It is great to see.

Thank you so much for having me on. It was a lot of fun.

Sebastian, take care. Stay safe. I will keep my eye on your repositories.