In the following exchange, Flagsmith’s founder and CEO, Ben Rometsch (@dabeeeenster), talks about an open, unrushed, methodical way of building that has enabled them to see through some endlessly debated decisions — agency vs product, bootstrapped vs VC-led, and others — and prioritize choices that work best for them.
— Why build an open source, feature flagging tool
— Running an agency alongside an at-scale product
— Bootstrapping and the genius of upfront, multi-year deals
— Having the time for an ICP to emerge on its own
— Serving on-prem and Flagsmith’s open source philosophy
— How to choose a fitting open source license
Why build an open source, feature flagging tool
The truth of the matter is that while we’ve been running the agency (now 22 years old :)), we’ve always tried building a bunch of stand-alone side projects. That list has included a time tracking and invoicing tool for agencies, mobile apps, mobile games, and all sorts of stuff.
Also, for years, we’ve had this experience of having an idea (“oh, that would be a good project management tool”) and then eventually realizing that that market is already bustling with competitors.
To the extent that we got to thinking that most good ideas had been used up. Feeling that, “we’re engineers and rubbish at marketing, there’s no way we’d stand out in crowded markets with dozens of players attacking it from loads of different angles.”
So when we were coming up with ideas for the next internal project to build within the agency, we had a few ideas and a sort of scorecard for each of those; addressing questions like:
— How easy is it to build?
— How competitive is it?
— What’s the addressable market?
A feature flagging platform was one of those ideas. When we looked at that market we learned that there were only really a couple of major products in the market.
And most people just knew about one of them and that, too, was really expensive. Plus, at the time there was no open source — an aspect that we knew would help us drive distribution — tool.
In hindsight, combining those two realizations really made it a great opportunity. Even though we didn’t start Flagsmith saying, “it’s the best time to start a feature flagging company.”
This category has definitely matured and has gotten much wider since we started 5 years ago.
Some companies or products like ours focus more on being a solution for engineers whereas others focus more on being a solution for product and data teams; selling testing, behavioral feedback etc.
And although we’ve been open source all along, we’ve never positioned ourselves as an open source alternative to X (that is the product that everyone in the space knows about), because that would entrench their position as the thing.
Running an agency alongside an at-scale product
Importantly, I started the agency with a business partner and we’ve always had a shared ownership of the business. Very fortuitously, as it’s kind of like marriage, we’ve been together for 23 years.
If it was just one of us, we would then have had to make a decision between running a product and an agency. Instead, we arrived at a natural split. Where I was leaning more towards growing Flagsmith and he was focused more on the agency.
The agency funded Flagsmith until it was able to financially support itself. We definitely split them into two legal entities. As we’re bootstrapped and had no runway pressures, the key decision was to say, “I’m going to go full time on Flagsmith for 6 months and see if it works.”
Luckily, it did.
We never had the thought that we were bored of agency life.
There’s a reasonable strategy that uses agency work as a dependable springboard to do all sorts of projects that might become legitimate businesses on their own. 37 Signals did it with Basecamp. Many others have done it since.
But there’s also a little bit too much negativity around that or in the insistence that “you have to stop doing agency work because there’s something intrinsically crap about it.”
There’s a perception, especially among startups, that for some reason agency work is lesser than product work. I don’t subscribe to that.
If you’ve got nice clients and interesting projects, agencies can be very enjoyable engineering environments. Because you often tend to start with a blank sheet of paper with a set of tools that you like using.
You’re not dealing with 10-year old code. You’re not spending weeks upgrading packages owing to security problems. The sort of drudgery engineering you have to do to keep projects going for years and years.
This gets even more rewarding if you see client projects being successful.
We had a couple of fitness applications that we had been working on that became mega successes. They were featured in the App Store and in major magazines.
That was such a great project to work on.
And we wouldn’t have had that if we’d all been focusing on Flagsmith.
Bootstrapping and the genius of upfront, multi-year deals
The decision (to bootstrap or to raise venture capital) entirely depends on who you are, what the company is, what the product does, and what you’re trying to achieve.
Having bootstrapped all our projects, I’m not saying it’s better.
Some people are too polarizing about this.
Recently, I was looking at Hacker News and saw that Fly, a really good hosted platform, had announced that they’d raised a zillion pounds from Andreessen Horowitz. And it was surprising to see how the 1st top comment there was furious with them.
They were like, “give it 2 years and your prices are going to quadruple, you’ve sold out, the only thing you’d do now is fill the pockets of yourselves and investors.”
Just pure fury!
Guess it’s partly because Fly is such an impressive piece of technology and very impactful.
But also the amount of money people were raising up until very recently was just insane. It was difficult to raise similar figures in Europe compared to the valley.
I’d notice companies signing up for Flagsmith and check out their business, then come across how much they had raised with no customers. That bloat is definitely there. Distorting a lot of things. What I read on Hacker News the other day was an echo or a reaction to it.
We did think about raising money about 2 years ago as we saw that the growth opportunity was good. What made us not go in that direction is actually quite interesting and not something that not enough people talk about.
A bit of a secret I guess.
So Flagsmith serves all manners of people.
From tiny, one-person teams running it on their laptop or home servers or whatever, all the way up to some of the largest companies in the world.
But the majority of our money comes from large enterprise organizations. And they want to pay you for years in advance for your tool. Because they want to lock in the support and the services agreement and security and upgrades.
They have to do that, right?
Coming from the agency world, that still blows my mind. I know it’s different for different countries, but in the UK, you do a month’s work in an agency and raise an invoice at the end of the month. Then, on average, you get paid for that invoice 45 days later.
That’s called a positive cash flow cycle.
And it sucks!
Because that makes it really, really painful to grow a business. Fairly often people pay you 3 or even 4 months later. So it’s very difficult to build enough cash flow.
With Flagsmith, we have got a negative cash flow cycle. People are paying us, literally asking, “can we pay you for 3 years upfront now?” We’re like, “you certainly can, sir!”
That’s a big reason behind not needing to raise external capital. We don’t need to give equity away. Obviously, we’re really careful about how we spend all that upfront cash as we need to service these clients for years. We’re very respectful of that fact.
But if we’re constantly selling these deals that are 3+ years out, the cash flow cycle compounds over time. That’s been a huge benefit.
I know there are a lot of services that finance based on converting MRR into ARR. These upfront payments represent a similar sort of financing for us. Of course, in our case, they’re coming directly from customers. It’s genius!
So yeah, the problem with the bootstrapping vs VC question is that people are myopic about the choice. They think there’s just 2 options.
Bootstrap and don’t grow at all.
Or raise a gazillion pounds and then if you don’t achieve the growth that you’ve raised on, you get tossed in the trash. There are a lot of options in between.
If you can build a reliable cash flow cycle, you can grow the team the way you want.
We’re still really careful about hiring as we’ve not had a sudden infusion of $10m, but the upfront payments have meant that we can hire sooner than we would have been able to had it all been pure monthly revenue.
To add a personal point to this question.
I’ve been working for myself for a long time. So the thought of there being a calendar event every 2 months to attend a board meeting with a bunch of people I have to answer to is a bit…Well, I’d do anything I can to avoid that from landing on my calendar. 
Having the time for an ICP to emerge on its own
I’m happy to hold my hands up and say that settling on an ICP is something we could have done better.
Because we built Flagsmith for ourselves and some of our agency clients at the time, we saw ourselves as the target customer. Rather than what we should have done, which was not starting with preconceptions on this front and talking to a bunch of people.
We did get there gradually.
That was the other great thing about it being a bootstrapped side project. We didn’t have the time pressure to urgently scale from 0-1 under such and such period.
Many startups in that position have to scramble around to find product-market fit. Onboarding users only to realize not enough of them would pay or not pay enough to aim at profitability. Or lead to lots of support issues.
Anyway, we, on the other hand, had the chance to let that ICP appear and solidify in front of us over time, instead of desperately running around with our hair on fire to figure out who we should really be selling to.
Within a couple of years (which doesn’t seem that long a time given that this began as a side project) we started seeing a pattern in the business. That more and more enterprise customers wanted to run the product on premise and wanted to pay us well to do so.
By the time the 15th email requesting that arrived, we knew this was it. This was even better than reaching out to people and getting their opinions. They might say one thing and you might hear something slightly different.
But it was hard to argue against clear inbound interest where companies wanted to pay us loads of money.
Yes, that meant the small-agency thinking of, “let’s just put up a Chargebee front end and start charging monthly” was wrong and we had to revisit how much and how to charge, but those were all nice problems to have.
I think the most important thing was how the way we were structured allowed us the time to get to this understanding.
Serving on-prem and Flagsmith’s open source philosophy
Once we started looking into this, the closed, on-prem direction felt very natural.
There have been large, successful companies that have followed the same path.
Sentry and GitLab are certainly among the influential ones.
Especially with feature flagging as it’s generally regarded, rightly so, as critical infrastructure. When you’re implementing such a product, you have to make sure that even when the service goes down, your flags are behaving sensibly.
We had these mega corps telling us that this was critical and how they needed to care for and look after such a service the same way that they’d look at their databases or application servers.
They were like, “we’d run this open source thing, it’s a Django application, it’s got Postgres, it’s simple and we get platform infrastructure.”
But as, by and large, they were huge orgs, some with tens of thousands of employees, we realized that keeping everything open wouldn’t be sustainable.
We needed to have a philosophy to think about application features (that formed the core Flagsmith product) and system features (ex: 2FA, access control). So we’ve drafted the following, addressing the business and moral side of the open source for us:
We don’t want to withhold Applications Features in our open source offering.
Doing so stifles the value of the product to the people that actually give a shit about it: the Developers that use it.
Doing so is irrational; why make your product worse for developers?
The trick is to charge for features that don’t make your product objectively better to the developer.
Developers want to write code and build products.
They may appreciate the importance of 2 factor authentication, but they don’t really give much of a shit if the product doesn’t have it. It doesn’t get them out of bed in the morning, and it doesn’t make them more effective at their job.
CTOs, Project and Product Managers, Compliance and Procurement Teams and suchlike are the ones that mandate System Features.
This mandate is the point at which we can capture the paying customer.
We sell on: “this speeds up our development philosophy”.
The customer buys on: “we have to have 2fa and an audit log otherwise I will lose my job”.
How to choose a fitting open source license
There’s a really good site that GitHub has put together, choosealicense.com. That just boils down different open source licenses. Because they can get really complicated. And I hate reading legal documents. Like I’m physically incapable of going through them.
Knowing how licenses work will help you answer some central product questions: Whose responsibility is it? What can other people do with it? What sort of conditions apply? The open source licensing decision is at once a moral, political, ethical, and commercial one.
You have to find a license that fits you the best.
I remember using Linux in 1995 and my own practical understanding and opinion of open source has changed a lot since then. The licensing choice we’ve made might upset a few people. But I’m fine with that.
As at the end of the day, we feel that we’ve built a pretty high quality product and platform. That wouldn’t have existed if we hadn’t made the decisions that we’ve made.
Related reading from the Relay archives:
— Typesense’s co-founder, Jason Bosco, on why open source remains an ideal bet for dev tools
— Pulley’s founder, Yin Wu, on why you shouldn’t build for an obviously large market
— Thematic’s co-founder, Alyona Medelyan, on how they stay capital efficient