Welcome back, everybody. This is a very surreal moment because sitting in front of me, I have the man whose idea this show was originally, Matt Althauser, and one of his business partners, Alex Boswell, from Polychrome. Matt and Alex, this is surreal. Welcome. 

Thanks for having me. 

Thanks, Ben.

We're going to talk a little bit about monetization and how the C in costs in the commercial open source software. Before we start, it would probably be super relevant for you guys to give a quick background about Polychrome, the Polychrome companies that you've been working with and investing in, and a little bit about yourself. Matt. 

Polychrome is a holding company where we invest in and partner with technical founders. We like to own companies with no goal of selling them. We want long-term partnerships. We have five businesses that we work with. We're always looking for more. The company was started by Alex, me, and our other co-founder, Greg. All of us are ex-venture-backed, go-to-market, and finance executives who love the earliest stages of business building. That's our background for Polychrome. My background, I've been working at companies like Optimizely and Amplitude in the venture-backed space before starting Polychrome. 

Similar to Matt, I spent the first part of my career working in venture-backed companies. Prior to starting Polychrome, I spent a little over seven years at Twilio, working in finance and operations roles there. When Greg, Matt, and I got together to start Polychrome, we wanted to bring that experience to smaller-scale software companies that are growing and help be on the other side of technical founders and building companies. We found ourselves pretty quickly with you and with Flagsmith, discovering and understanding the open-source ecosystem and building open-source companies and commercializing that. 

What I wanted to talk about is that it feels like, in my head anyway, the big three life cycle phases or metamorphosizations of Flagsmith were us getting to an annual recurring revenue of $10,000, $100,000, and then $1 million. I do feel in my head they're nice round numbers, but there were definitely massive shifts in how the business was being run and the direction it was being taken. Briefly, for people who don't know, maybe you guys can talk a little bit about some of the other Polychrome portfolio companies, how they got to that first $10,000. 

It's an elusive number because what is that? It is $800 a month, right? It doesn't sound like a lot, but it's really hard. There's an interesting story that we can talk a little bit about with Flagsmith. I like to think that we made a bit of a mistake getting our first $10,000 because we didn't put any thought into who our long-term target customer was going to be. We were like, “Build an open source project that we would like to use ourselves, put it on GitHub, and then point three is dot, dot, dot, and then profit.” 

For us, the dot, dot, dot, which we made no effort in doing any customer development or even any research, was to build a SaaS platform. Instead of people having to self-host it, they could pay us to host it. That is not our main source of revenue for Flagsmith now, which we can come on to. Getting people to pay $29 a month for a hosted platform, like a feature flagging platform, when you have no customers and have an MRR of zero, is much easier than selling a $40,000 enterprise license.

Looking back on it and thinking about this discussion now, maybe that's worked well for us. We fell into that. It wasn't the right thing to pivot around subsequently, but for our first $10,000 in ARR, it was achievable. You go from $29, and you get another one or two, then you might sell it. We had a large license at the time. I can't remember how much it was, maybe $100 or $150. You only need to sell a handful of those, and you're at $10,000. You're starting to think, “This is paying for a little bit more than the servers and stuff like that.” How did some of the other Polychrome companies get to that mark? 

We actually asked every founder we've worked with so far. We talked to a bunch of founders, especially in the open source space. How did you come up with the original idea and original customers? So many of them are comments in GitHub. A shocking number of companies get started that way. If you go into your favorite open source community right now, and you see the most upvoted problem that the company hasn't solved itself, it might not be the worst place to consider solving pain for people. 

An upvote is a form of raising your hand. I would say the first step is choosing a real problem to solve that is worth money. The beautiful thing for engineers is that you live hopefully within that community. You understand that pain point. You know what it's worth to you. That has motivated you to ship the original product. I remember Kyle, your co-founder, Ben.

There was a GitHub issue on one of the Firebase open source repositories. You're right. He had 45 upvotes or something. People say the same thing about there being a bunch of companies that have been very successful that have been started either from Hacker News posts, or I can use comments where there has been a bunch of activity around them. 

At least it's enough to get you started on the right problem. There's this huge trough of sorrow. I saw this problem on GitHub. I actually showed something that people can do. For you guys, having the agency as a stable business allows you to be camels in the desert. I don't mean to undermine or oversimplify that for the founders who don't have that steady source of income. That's tough. I do think that if you can pick a problem that you know is real, solve it effectively with software, be patient, and continually let people know in the community that you've solved that problem, that's a pretty good way to get to that initial $10,000. 

Another way that we've seen people do it effectively outside of solving a community problem is by creating a community, understanding that community, and solving problems for it. I know the devtools podcast guy has built an amazing community around devtools. I'm not surprised if he built something off the back of that. We have similar opportunities here, through the connections that we've built with this show. There are ways that you could also say, “I can build the community and then solve problems,” or “I can attack an existing community and solve a real problem for them.” That tends to be the best way, at least with devtool or open-source type products that we see. 

Alex, are there any companies that spring to mind that are relevant in terms of their journey to $10,000? 

As Matt said, the key thing is that everyone has a story of why they started the company. You and Kyle put a lot of thought into why feature flags. We look at Joel with Browserless. He had basically been doing browser automation at his previous company. He knew the problem. He knew exactly what sucked about it and what to solve. You probably hear that a lot. It's not necessarily solving your own problem, but it's understanding why that's a problem and going after it. 

Just to add to that, I'm very cynical of myself. Kyle is very much the opposite. If I were having a problem, I'd be sitting there probably thinking I'm the only person who has ever had this problem because of imposter syndrome or whatever. Kyle would be like, “No, there are going to be millions of people that have this problem.” Sometimes, you do have to take that leap. Let's be clear. Luck plays a big part at this point in the journey. As you said, Matt, having an agency meant we could fire off several shots. We didn't have to go and live in our car or do anything like that. 

It took time, but it is being able to iterate that loop quickly, build something quickly, and then be able to say to yourself, “This isn't working. I need to go on to the next one,” and then avoid that sunk cost fallacy. The other thing I'd like to say at this point, when you're zero sales, if you put a website out there and you have a decent marketing stance that is above a certain level of good, no one knows you have $0 in sales. It's amazing the number of people who don't ask how many dollars in sales you've got. When was the last time you asked a supplier, “How big are you?” That always amazed me. I'd be like, “They're going to assume that we have $0 in sales.” As long as your website is okay, then no one is going to know. So many people make that mistake.

Putting lipstick on before you go out is always a good idea. It's so funny. The open source community makes a big deal about stars, but I totally remember when we got to 1,000 stars, we were like, “It's one at least symbol that we're somewhat legitimate.” There are other things that you can do to try to show progress and adoption. I'm not saying that that's the best one, but it's interesting. 

In fact, I would say four of our five companies that we work with all solved community-driven problems that led to the founding of their product, which is cool. Two of the four were agencies that spun products out, you guys and Marker.io. Two were deep in a community. Terrateam was actually in part of the OpenTofu fork, which led them to build a cloud offering for that community. Totally, from this community is where you see the best companies get born. 

Another episode might be an interesting thing to dive into as well. If you do that, you do have to be super careful and calibrated about your approach, and understandably, as engineers, especially because they get sold to so much. There have been projects that have done a bit of a rug pull on their communities. Do think you have to be calibrated about that and respectful of that. Everyone knows. You know when you see it. Getting from $10,000 to $100,000, this is the point in Flagsmith's life where I met you guys. That was a very important, timely introduction. 

Just to set the scene, I can't remember exactly what it was, but it would have been maybe $30,000 in ARR at the time or a little bit less. We were starting to get approached by very large enterprise organizations that wanted to run the platform on-premises. We hit this big problem that you knew some of the answers to, which was, how much do you sell an on-premise license for what is 98% free open source software? That's a difficult question to answer, almost impossible if you've not got much experience of it. If you do have experience with it, then away you go. How do you remember that period? 

It was funny to me because I remember we had massive organizations sending support questions in. You're like, “Wait a minute. They're on the support channel, but they're from the biggest company I've ever seen in the world.” I remember asking some basic questions because, as a non-technical person, and I don't know about you, Alex, I've never worked previously in a company that sold on-premises licenses. It was all cloud that we had sold, all closed source that we had sold previously. Alex, was that the case for you as well? 

Yes. 

For me, I was trying to ask these obvious questions, like, “They can just docker up our product and get up and running?” Ben was like, “Yes.” I'm like, “Okay, but I don't understand. They need our support, right?” “Yes, they need our support.” There's this willingness to use our product and pay. I couldn't put together why that wasn't our target customer. I don't think it was super popular at the time to build software companies that focused on an on-premise delivery model, as well as the cloud delivery model. I think it was less popular, but it was glaring to all of us when we started asking the basic questions, like, “Could we build a company where this didn't suck for customers?” There are always reasons why different modes of infrastructure are terrible for customers or companies to support. 

I remember pretty early being like, “What if we make it in a way that's cool for our customers, it works well, the upgrades are easy, and we make the infrastructure bulletproof?” That ethos led to a lot of how you guys think about building product and who we build it for. I always think that if the first rule is to choose a problem to solve that's worth money, the second is to now choose a subset of those users who want the problems solved that are actually worth a lot more as a customer. That helps you get to the next level a little bit faster. That can be based on seats. It can be based on tokens, units, or whatever people are saying for the newest pricing model. Doubling down on an area was pretty obvious to us at the time, to keep asking questions. 

Alex, I remember coming from an agency where you do a month's work, and then you send them an invoice. They ignore your invoice for three months. You moan at them, and then they pay it. We've gone from that to a company asking you, instead of for a year's invoice up front, for two or three years' invoices up front because the single most important thing that they're trying to do is to de-risk the acquisition of that software license and to not have any bumps in the road for those three years. Can you talk a little bit about those people buying that software? You've had a lot of experience working with them and what their needs are, right? 

Yes. In starting a company, it's great that you're aligned with the customer in that way. They're like, “We want to pay two or three years up front,” or you're able to get them to pay two or three years up front for a discount. On the same side, that was the fuel we needed to keep building the business and keep running the business. It is super well aligned. That comes to the whole pricing of these deals. When you're dealing with enterprise customers, and you haven't spent a lot of time with enterprise customers, how do you price? We were learning that as we went. 

Matt and Greg both had great experience having sold and priced tons of enterprise customers on the SaaS side. When we started thinking about on-prem, it was a new model. You had the old, where you sell a perpetual license with 15% to 20% support on top. That's gone now. It's more of an actual recurring license that includes support and includes everything. It's a matter of figuring out what the willingness to pay from customers is. That's the sales process. That's discovery. You get into that in those deals. 

One other thing that I want to cover with you at this. To set the scene, at this point, we've got a positive cashflow cycle. We're getting people paying us for work that we haven't done yet, which is good. It's a bit of a Faustian pact that you have to agree with yourself. I remember thinking, “We've got this money in the bank. Let's go and hire some more engineers and hire some more go-to-market people.” 

You're like, “No. We haven't earned that money yet. It's sat in our bank, but we haven't earned it yet.” That was definitely the right thing to do. Did you have some guiding principles? The problem is if you're always making sales, that cake is growing in front of you. You're like, “I want to go and eat that cake. We'll hire more people.” At some point, it does make logical and rational sense to dig into a little bit of that. Can you talk a little bit about how you went around the numbers and the metrics around that? 

A core thing for us with Flagsmith and with any company that we work with is we want to build a very sustainable business that can live off its own profits and be a long-term, profitable, and ongoing business. You don't want to get too risky and start to use all that upfront cash. The way that we looked at it was that we initially wanted to use some of that upfront cash. 

We got to do one-off projects that we knew were important, paying for things like the new website and things like that, that we could pay for without those that weren't going to be recurring costs. At the same time, we were keeping enough money in the bank to make sure that we could support that customer for the long term and that we weren't burning through it right away and running out of money. 

As you grow as a business, and those upfront payments and enterprise sales become more repeatable and more dependable, you can start to use some of that free cashflow a little bit more because you know you're going to sign three more deals the next month, five more deals, or whatever. When we were signing one every six months, we didn't know that there was going to be another cash influx. You can't use that money. 

Once we've gotten to a little bit bigger position, I like to think of wanting to cover a decent percentage of the unearned revenue that we have out there and also making sure that we have three months, maybe even six months, covered in terms of what the costs of running this business are going to be if we don't have a bunch of free cashflow coming in ahead of the business. 

The non-recurrent was a super important part there because then if you do have a bad quarter or whatever, you can be like, “We won't do another big marketing event.” The other thing is that I remember this happening quite a lot when we were at this phase of the company. There'll be some enterprise gizmo that a customer needed, and we didn't have the gizmo. In two months, we'll have the gizmo. If you sign the contract, the gizmo will be there in two months. That's the perfect thing because you're building in enterprise value into your product. 

You're eventually going to get paid for it, and everyone is happy. This is the fundamental difference between a venture-backed and a bootstrap company. The last thing you want to do with a bootstrap business is go and hire people who suddenly make that collapse that runway. That's definitely super important. They can even be quite chunky as well. If you know that and you're getting to the number of orders that are coming through and the number of servers that are coming through, once they get over a certain number, they're not too erratic. The numbers become a little bit more stable. 

I haven't talked about team size here. I remember we got to $100,000 in ARR. We're still a tiny team, absolutely minuscule. To get to $1 million, you need to start considering the team. I was like, “If we can afford ten people at Flagsmith, then we hire nine engineers and a project manager.” For Flagsmith, that was not the right answer. When we got to a headcount of ten, Flagsmith didn't look like nine engineers, right? 

No, for sure. People do underestimate the other roles that tend to be of high value, marketing, sales. We do put a lot of technical support. We also have a pretty good ethos about making sure an engineer is responding to your questions on the support side. We do try not to have too many non-technical people on the team at this point in time, and hopefully for a long time. Generally speaking, yes, you've got to even it out. You've got to have people running the day-to-day and managing customers and renewals. There's a lot to be done there. At $1 million in revenue, I still felt like we had day jobs at Flagsmith. We were still heavily involved in trying to make sure that as much as possible could go back into the engineering organization. It takes a community to build a business.

My complete blink of vision was just build the product, build the product, build the product. We need more engineering. We were hiring. We had two marketers quite early on. Now that's so valuable. The work they do is so valuable to the business. The other thing as well is guarding against large customers churning and making sure that customers are switched on after they've gone through acquiring the license or the product. That again was something that I was naive about as a role. If you want to grow and you've got a negative churn rate, then that's a superpower as well. It was something that I was completely blind to as well. Alex, what aspects of businesses at $1 million are you thinking are most important? 

At $1 million, we are still engineering-heavy organizations. It's building the engineers. One of the best things at Flagsmith has been that we brought in technical support, but the engineering team did a ton of technical support early on, and still does. That was super important. The next thing we did was we brought in an enterprise seller, someone who could work with these enterprises and build those relationships. 

As you said, this is about getting new sales in the door, but it's also about expanding those contracts that we already have because those are the easiest dollars that you're going to come by next. It's much easier to expand an enterprise or move into another department within that organization than to sell a whole new enterprise. It is having someone there. We did start to build the customer success or CS team. 

There were people who were following up, not just people who wanted to close new deals, but people who were having check-ins with enterprise customers and building that, engineering-heavy. There were all those other things related to supporting and closing new deals and bringing those in. Marketing was an early hire we made. That was important. Early on, you do want to have an understanding of your financials, your metrics, and how you're building the business against where you're going. 

Someone in the organization can take hold of that and do your accounting metrics, financial forecasting, planning, and things like that. Hopefully, that's someone in the org who can do that with a portion of their time early on. All that helped guide the company and make sure that we were on a path that had a lot of thought around it. We weren't overextending ourselves anywhere. 

One important thing about that is that a lot of value in the fact that you were only doing a small portion of your weekly work was on Flagsmith. You were a little bit detached from it emotionally in that way. It allowed you to stand back a little bit and say, “Here are the numbers. We can afford to do this marketing thing,” or “We've got a budget for this,” but not to get drawn into making decisions emotionally and not making them in a rational way. Having someone a little bit detached and doing that side of things works well for us. 

I definitely felt the benefit from that. Finally, before we finish up, in terms of licensing, how do you feel that affects everything that we're talking about here? Different licenses can steer where your product goes, how easy they are for people to contribute to, how easy they are for people to deploy on-premises, and things like that. What thoughts have you got around different licensing, different licensing models, and how that can affect a company's life as it's growing? 

Let's say we started with the road to $10,000 here. How do you get to that first $10,000? At that point, you're making the decision around what your monetization model is going to be. There has been that evolution from the beginning, where it was support. We started with SaaS on top of that. Flagsmith moved to your dual license or open core type model. There are a lot of options within that. In terms of what the actual license you want, you choose based on that. You want to pick the goals that you have around your business and how you're going to grow it, and choose the right license for that. 

For example, if you have a more permissive license, you're going to get more contributions. You're going to get more people adopting it. I know we've talked to a lot of enterprise customers where they're only allowed to use open source software that has a few of these specific licenses. You can say, “This other license is the same, but it's not just on the list. I can only use it if it has MIT or Apache 2.0,” or whatever the list that they have is. If you're going to go dual license, that's probably the model that's the best right now in terms of if you're trying to monetize open source with an on-prem side. 

If you do the SaaS, you could be more permissive. You don't need a dual license. If you're doing a dual license, it's having your open core license with a permissive license like MIT or Apache, and then having an enterprise license that's closed and you sell. It has a couple more features, security, or whatever you decide as your differentiator between those. Choosing the license is important. If you have a tighter license, you might have more paths to commercialization and commercial success, but fewer people are going to adopt it early on. 

You have to make that choice. At Flagsmith, a pretty permissive license for the open source, and then an enterprise license that people come talk to us about. That has worked well. That's my recommendation most of the time. As I said, that allows people to come and adopt it across the board, contribute, and be interested, but then also gives you the path to building the business. 

Matt, what are your thoughts? 

The other part is that we came into the business to support your vision, Ben. That's important about what our role was as a partner. I remember we kept having conversations about licenses that were almost like religion. We took a step back, being like, “What is everyone's ethos on open source?” and choosing a license that aligned with that ethos. We were going to benefit from the community, but we weren't going to cross certain lines and break that trust over time. That actually made building a go-to-market way easier. It's like, “There aren't these variables moving around for our community. They don't have to worry. They can commit. This is how we think about things.”

I appreciated that you took the time to share what your ethos was. That made the company building and the monetization frameworks for Alex and me way easier. As the founder, one thing I would say is start looking at licenses, take a step back, and think about why you are going open source. What would be painful for you as a person to change or double-cross that is against your standards? No one is judging you. You can have any standards. We're not religious about this at all. That helps everyone around founders and around teams get on board and say, “This is the field. We have to optimize within it. Let's get to work.” That was a helpful thing that you did for us. 

One final thing to add on that is, in my experience, most people that we've met on our travels, and I'm not going to use the word journey, unless you're egregious about the license and do something out of left field that's like, “Hang on a sec,” most people drive cars. They're not car guys. They want to get from one place to the other. They don't care about the engine, the turbocharger, or whatever. In open source, most people are the same, as long as it's roughly the right shape and size, and you're not doing anything absolutely wacky. You will come across people from time to time who do that. Especially commercially, that happens very infrequently in a commercial setting. That's definitely my experience with it.

I know, historically, and especially with open source packages, like standard libraries, libraries become very popular, then it gets a lot more difficult, and it becomes a lot more emotional for good reason, because the guy in Nebraska, we should talk about almost every episode. If you're building and selling an entire application or suite of tools that people can use, and they can run themselves and use Docker and all that stuff, as long as you're doing something absolutely out of left field, then most people don't mind. It doesn't come up. We're trying to make this a little bit shorter, a little bit punchier. If you've got any final closing thoughts, Matt? 

The biggest one is thank you. Thanks for working with Polychrome. Thanks for letting us be on this journey with you. 

You can't say journey. You're not allowed. 

Sorry. Thanks for letting us be on this ride with you. We've learned so much from you. We're having a lot of fun still doing it. Thank you. 

Alex? 

Thank you, Ben. It's always great working with you. Final thoughts. I like this idea of, “What do you do to $10,000 AR, $100,000 AR, and $1 million AR?” One thing, and Matt said it, and that's why I'm thinking right now, is stay patient. It takes a long time. It was never as fast, even when we thought things were going super well, but it's fun. You get to celebrate the wins and have a good time. I hope that people enjoy that part of it. 

That's an important point, time. That's one of the beauties of running a bootstrap company. You're not under this constant time pressure grind. You can have the business run and build at a natural pace. It's something that doesn't get talked about enough. You're right. You'll have quarters or months that are amazing, and then you'll have quarters or months that will be like, “My god.” The combination of accumulated gains that you can get is something that you have to be patient about. Thanks again so much for your time. We'll be posting some photos from the crazy Italian bike ride. Maybe we'll have to do a blog post about that.

Thanks, Ben.

Cheers, guys. 

See you.