15,000 GH stars in a year: how we did it

It has only been a bit more than a year since we decided to raise funding in the quest of building the best OS composable commerce platform for developers with Medusa.

Since starting, we have had +10,000 project starts, raised $9M in funding, and gone from 30 to +15,000 GitHub stars.

Below are some of my takeaways on how we managed to build strong early traction. While at it, please leave a on our repo if you like this article: github.com/medusajs/medusa

TL;DR - 10 lessons:

Solve a problem that hurts:

• 1. Clear user pain point: Make sure you understand the user pain point you are trying to solve.
• 2. No good alternatives: What you are building needs to clearly differentiated from what is already out there.
• 3. Why does it need to be open source: Ask yourself whether an OS solution is needed or if proprietary solutions actually solve it.

Create a delightful product experience

• 4. A focused product approach: It can be easy to get distracted, so keep the focus on your core product priorities.
• 5. Support your community: Building traction requires you to ensure that your community feels your commitment to their success.
• 6. Invest in your DevEx: Make it easy to get started with Docs, quick onboarding flows and supporting tools.

Get the word out there

• 7. Make it easy to understand: Have a simple product description ready that makes it easy to comprehend what you are building.
• 8. Focus on dev channels: Ensure your product gets attention in forums and blogs where developers are present.
• 9. Make big bets and follow through: Prioritize events you know have the potential to send your product viral and make sure you execute these well.
• 10. Make it authentic: Build content that is authentic and useful to developers instead of regular marketing messages

Below I will go into a bit more depth with each of these steps

Find a problem that hurts

Your project must address a pain point for developers that really are meaningful to them. Three things to watch out for are:

• 1. Clear user pain point: Make sure you understand the user pain point you are trying to solve. In the world of ecommerce, we knew from experience how painful the developer experience was with many proprietary tools (e.g. Shopify) and legacy open source tools (e.g. Magento and Woo). All of them build with an all-in-one monolith architecture, that forces developers to pursue hacky workarounds for customizations and new integrations. Having experienced the pain points ourselves from our previous careers made it easier to verify, that there indeed was a problem to solve in this space.
• 2. No good alternatives: What you are building needs to clearly differentiated from what is already out there. In our view, the ecommerce landscape seemed to crave innovation. API-first solutions like Elasticpath, Commercetools, etc. seemed to focus on enterprise sales and less so on developer experience while their proprietary nature made it difficult for them to offer the same customization options as an OS tool. On the open source side, most existing solutions were offering PHP-based backends staying out-of-touch with modern developers, and no one had nailed it with a JS-based alternative yet.
• 3. Why does it need to be open source: Ask yourself whether an OS solution is needed in the space, or if proprietary solutions actually solve it. It can be tempting to assume that open source is always the path forward, but it might not always hold true. With ecommerce platforms, the complication is that user needs vary a lot for different business types (e.g. just from serving B2C to B2B customers) and this means a proprietary one-fits-all-solution is seldom the right path when a use case is a bit outside the box - which explains why more than half of the world largest ecommerce sites are still built with a custom or open-source commerce backends.

Create a delightful product experience

Identifying the problem is not merely enough. Building a product to solve it and investing in the community and DevEx around it is key as well.

• 4. A focused product approach: It can be easy to get distracted, so keep the focus on your core product priorities. Building open source, the community will have lots of opinions on additional features, plugins or functionalities to build. Some of this feedback will be less relevant to your core audience. Therefore, be selective of the inputs you get and build the few features that will make a meaningful impact for your core audience instead of a lot of half-decent features for everyone.
• 5. Support your community: Building traction requires you to ensure that your community feels your commitment to their success. From our early days, we have been razor focused on our community. We do this through a wide array of activities from community events to our transparent product discussions to our continuous focus on building community support materials. Likewise, we are dedicating a lot of time to answering community inquiries on GitHub and Discord helping devs get started.
• 6. Invest in your DevEx: Make it easy to get started with Docs, quick onboarding flows and supporting tools. We prioritize the developer experience by putting a lot of focus into areas such as our Documentation - which we treat as a product of its own with a full-time team member dedicated to it - while ensuring that our onboarding flow is easy to get through with supporting project starter templates.

Get the word out there

When you have a great developer experience set up, your key task becomes to create awareness around the project.

• 7. Make it easy to understand: Have a simple product description ready that makes it easy to comprehend what you are building. We focused a lot of our messaging around being the open source Shopify alternative which instantly resonated with developers (see e.g. our HN launch). In reality, Medusa is much more than open source Shopify as our modular architecture better fits more bespoke ecommerce cases than typical mom and pops Shopify stores. Yet, the simplicity of the messaging makes it very easy for developers to categorize the solution when quickly hearing about it for the first time.
• 8. Focus on dev channels: Ensure your product gets attention in forums and blogs where developers are present. We have always remained focused on developer channels and spent energy creating content and initiatives to target these; e.g. leveraging Reddit to make a lot of mini launches or setting up a Writers Program to produce content for channels like Dev.to, Medium and Hashnode. Other tools like Supabase focuses on Twitter, while Digital Ocean is a prime example of own channel content done right.
• 9. Make big bets and follow through: Prioritize events you know have the potential to send your product viral and make sure you execute these well. Once in a while, we have events we believe have the potential to make Medusa go viral, e.g. ProductHunt launch, Series Seed investment announcement or our recent Medusa Hackathon. For all of them, we prioritized planning ahead and making a structured campaign around it to ensure maximal exposure, sometimes preparing videos, announcement content, and website updates weeks or months in advance.
• 10. Make it authentic: Build content that is authentic and useful to developers instead of regular marketing messages. In our 12 months, we did not spend a single dollar on ads for Medusa. Instead, we focused our resources on building content that was authentic to developers through articles and tutorials that were centered around explaining what our product did instead of more sales-oriented messaging.

A word of caution

I hope the above gave some useful inputs from our journey. One last disclaimer: In all honesty, GH stars can be a bit of a vanity measure for a project's popularity when used as a standalone metric.

I will be an advocate for looking into more usage-related metrics as well such as project starts, active developers, monthly contributors etc.

Where GitHub stars do serve as a fine indicator is to understand if people are interested in what you are building - and it is one of the few OS metrics that are comparable across projects.