Five Mistakes to Avoid on the Road to $1M ARR as a COSS Company

Flagsmith crossed the $1M ARR barrier a while back as a COSS (Commercial Open Source Software) company. It started as a bootstrapped open-source project built by developers who couldn’t find ‘the Postgres of feature flags’, so we decided to build one.

We saw the opportunity to build a feature flagging solution and open-source it. Five years later, we hit $1M ARR and recently held our first company off-site to get a fully remote team together.

It takes a lot to build an open-source project to the point where it stands up as a commercial open-source business. It’s a long road, and we learned a lot along the way. But the best thing about the open-source community is that once a problem is solved, if it is shared with the world, we don't have to solve it again. 

Here are five mistakes we learned from along the way.

1. Not Defining Your Target Customer Early Enough

We built Flagsmith to solve problems that we were having as developers, so initially, it was built for us. We didn’t start out by figuring out a target customer and creating a business model around them, because we were building the tool for ourselves. 

As engineers, we were thinking about new features, new languages, SDKs and the technical aspects. Our tendency was to get stuck into the code and build, so we skipped past a lot of valuable customer research in our early days.  

The message here is this: do the work that you know deep down you should do. It pays to do it right early on. 

If we were to go back, we would focus on identifying the right customer and their needs earlier in our process. If you can focus on the customer and build around what they need—based on research and conversations with them—you’re in a much better position. 

This is where the open-source community can come in, too. When you’ve identified your target customer, the open-source community can be a great resource for communicating with the right people. For example, we now use tools like crowd.dev’s Eagle Eye to engage with customers and the open-source community.    

2. Not Structuring Repositories Right

When we started, we didn't have a mono repo. We had repositories for every component of the application. The front-end dashboard and the backend API were split out into their own repositories. 

This was a bit of a nightmare for GitHub’s metrics. For example, it wasn't obvious which repo you should star, and because it wasn’t clearly navigable, we split our stars in a big way. Having a mono repo lets you aggregate all the stars in one place. 

Without a mono repo, contributors, forks, viewers, and issues can become split, too. Issues are particularly crucial because sometimes requests might span across repositories. If we created a feature that needed front-end work and back-end work, we needed to have two pull requests. 

Restructuring repositories can cause additional work, so it pays to structure things correctly at the start.  

3. Difficulties Finding the Right Open-Source License 

Finding the right open-source license is not always straightforward. When we were building Flagsmith, we knew how to engineer software and were familiar with open-source projects, but we had never navigated open-source license issues. And it’s high stakes—you don’t want your code and license to be abused, as has happened with a few open-source companies we’ve spoken to along the way.  

When we were choosing our license, we knew what we wanted and what we wanted to defend against, but we really didn't know what was best. So we made some mistakes, like putting code that we knew we were going to charge for in the open-source repository. This made it difficult because it’s much harder to back peddle when the code is already in the repository. 

The lesson here is that license helpers and the open-source community are fantastic resources. Finding the right license will likely boil down to looking at the different options and what they mean for you, your project, your liabilities, and your business. 

We have BSD3 licensing now, but the right choice for your company might be something different. It pays to take the time to understand the legal side and find the right license for your project. 

4. Not Realising that Small Teams are a Superpower

It’s easy to be intimidated by huge closed-source companies in your space. It can feel like going up against Goliaths. But small teams are a superpower. When you've got a small repository, team, and project, you don't have as many people submitting issues and pull requests. This means you can be incredibly agile and responsive. 

You can work on a pull request quickly, try to get it into the main repository, thank the person personally, and so on. As your project and repos grow, that gets more difficult. But it's so valuable to keep a high level of communication and support as a growing open-source project. 

When we were starting out, we received a pull request one evening. One of the team was on the train home from the pub with a phone and the GitHub app. The PR was reviewed and merged in four minutes. The person that submitted the PR messaged us saying how amazing it was because often people can wait for weeks for a PR to be looked at by the core team!  

As a small team, one of your superpowers is being able to be highly responsive. We’ve stayed very human and communicative with customers, and have noticed that offering genuinely great support to customers counts for a lot. 

5. Choosing the Wrong Brand Name

Before it was called Flagsmith, our company name was Bullet Train. We loved the name, but it wasn’t the result of a naming strategy. It was just an idea we had. 

The problem is that if you Google “Bullet Train” you don’t get a lot of results that are related to feature flags and DevOps. Whereas if you Google “Flagsmith Ruby” you will likely get results that are relevant to Flagsmith and our Ruby SDK. 

Choosing a name is a very important part of building an open-source company (or any company), and it pays to take the time to look at the possible implications—and Google results!  

Conclusion: Advice for Open-Source Creators

If we were to choose one piece of advice for someone in our shoes when we were starting out, it would be this: 

Don’t expect things to happen overnight. 

We’ve hit $1M ARR and are really proud of where our company is. We have a solid team, we love the problem we’re solving, and we’re excited about what’s to come. And it’s taken us over five years to get here.  

When we started Flagsmith, we were also running an agency and Flagsmith (or BulletTrain) was a side-project. This was really helpful because we weren’t pushing for overnight success or quick wins. We were just building something we were excited about at a pace we were happy with. 

Getting the first few stars on GitHub was a process. The amount of energy it takes to get things rolling is easy to underestimate. Mistakes are inevitable, too, so it really is important to choose a project that you’re passionate about and to take the time to grow it into something you’re proud of. And remember, the open-source community is amazing and can help a lot!

‍