Welcome back, everyone. It's a slightly unusual or maybe slightly surreal situation for me as part of this new show series. I'm talking to Kyle, who is the originator of what became Flagsmith. It's surreal for me because we've been talking to each other about software for about eleven years. We've been working together for eleven years or something like that. Kyle, welcome. 

Thank you. It is surreal. I don't think we've been full throttle on developing the product. We haven't sat down and been too introspective about it. This will be fun. Thank you for inviting me. 

It's funny how time can pass. All of a sudden, you're sixteen people and however many years have gone by. Do you want to give a bit of a background on how we met years ago and what we were doing up until Flagsmith, or Bullet Train at the time, came about? 

A long time ago now, pretty much a year after I graduated from university, I tried setting up a software-related business that didn't work out. My first professional job was at Solid State Group. I think it was back in 2013. You interviewed me. We've been working together on many different projects as part of that agency since. We wanted to create a product, get some recurring revenue, and move a little bit away from the agency model. We did that. A lot of luck and a lot of clever people, but we did that. Here we are with sixteen people in a growing business.

For those people who aren't aware, Solid State Group is a company that I founded with another guy, Matt Evans, many years ago, which is a crazy amount of time. We originally started as a hybrid content management system vendor and web agency. That was back in the day before WordPress existed. Content management systems back then were bad and expensive. We designed and built one and used that as a way of winning clients. Over time, it was interesting because we had a few different stages of life, as the agency originally did CMS stuff. 

We did have a product that you could buy. We were doing more startup work because we were in Shoreditch. There were a ton of startup clusters in Shoreditch. We were doing a lot of work on building prototypes and MVPs for startups, which I guess is around the time that you would have joined. Towards the later stage, we were doing some startup stuff, but then a lot more enterprise cloud transformation projects for large companies. We were getting them onto hyperscaler clouds, like moving applications and rebuilding applications, which would now be described as cloud native. Back then, it was just moving stuff onto AWS mainly. What were the projects that you recall working on at Solid State back then, before Bullet Train existed? 

That's the thing. I've got a lot of great things to say about working in an agency, but I wouldn't want to be spending all of my time working in an agency now, having done it for so many years. You get exposed to so many different projects. It's quite intense. Every minute of your time is tracked. On the positive side, you get to work on small startup projects in fitness, in sports, in medical, and in a lot of different industries. We have a lot of experience, ranging from startups to larger SMEs. 

That experience led us to being able to create a better, more well-rounded product because we were 30 customers in one from the get-go. A lot of people starting a SaaS product have an image of what a customer would be like who is selling to a wide range of people. You'd be guessing a lot of it, but we were, which gave us a lot of experience. To any young developers who may want to start entering business further down the road, going into an agency is a super intense crash course for that. 

You get introduced to so many different types of companies, types of end customers, and types of technology. You've got this beautiful moment where it doesn't happen in every agency project, but for us, it happened in a fair few of them, where we got started from scratch. It is all of the tooling, frameworks, platform, infrastructure, and everything you can decide for yourself, which is very rare. We probably didn't relish that enough because one of the things that changed massively when we did this shift was going from an agency to working on a product full-time. There are radically different engineering challenges that you're having to solve for. 

In an agency, you might end up starting four or five projects a year. It is a great crash course in, and also learning how to be efficient with your time, and realizing when you're going down a rabbit hole or going down the wrong path, technically. As you said, you're billing every minute or every hour of your time to that client. This is always in the back of your mind, being respectful of that. It's always there. In a way, it's nice, but then I enjoyed the fact that when working on Flagsmith, that constant background hum of, “Is what you're doing the right thing? Is it efficient for your customer?”

That did ebb away. You can spend more time dedicating yourself to deeper technical things. You were the one who had the original idea for building a feature flag platform. Do you want to talk about how we'd started to think about it? The potted story is that in an agency, you're not always busy. Sometimes, you can have years where everyone is basically flat out if the macro economy is growing, if there's a financial crisis, or something of that nature, and then quite often if you have a lot of spare time. At the agency, we had a fair amount of spare time. We were trying to figure out how to use that efficiently. We started coming up with a framework for this. 

We were coming up with a framework for evaluating ideas. A lot of it came from what we were talking about. Velocity was super important. Your time was tracked constantly. It was always in the back of your mind, as you say, what you spend your time on. I spent a lot of time making the front-end code base quick to spin up and had components for everything, making that process efficient. Releasing those features was something that we hadn't solved. Releasing was nasty. In some cases, where we were working on a large medical product, we were releasing it once every few months. 

That was a stressful thing because there was a load of code. There were often merge conflicts. It was a complicated, stressful process. I hadn't solved for that. I was completely focused on making the next project easier. That's where the idea of that came from. Above all else, I needed it. I was looking around. There was nothing I could use for different reasons. One of the big ones was Firebase. Firebase allowed you to do remote configuration, quite similar to feature flagging, in that you can specify some configuration. 

That was remote, so that meant that you could change the behavior of your applications remotely. That was part of the way to what I thought we needed. They only supported mobile applications. There's this nice historical bit of the company that we can relate to and refer to. I asked the question on GitHub to people at Firebase, “Why don't you support web applications that we want this tool, but we have web and mobile applications that we want to service? It isn't suitable for us.” That led me to look into the features flag space a lot more. It came from a real need. The needs were a bit different from all of the different customers that we had. That helped me piece together a strong road map of what I thought we wanted. 

I remember. To describe that medical product and project, it was a Bluetooth-connected asthma inhaler that tracks how often you've used it throughout the day. It was syncing that data back to your mobile phone or to the app that we were building. A few people have gone down that rabbit hole of low-energy Bluetooth devices, how they talk to each other, and incredibly complicated. 

We were building mobile apps. I remember releasing those in the app store was horrendously panic and anxiety-inducing. A lot of different Android devices have slightly different policies around how that Bluetooth LE stuff works. We were like, “Jesus, this has got to be a better way.” Quite often, we were delaying releases for months and months because someone on the test team had found a problem. “My inhaler never synced,” a horrendously painful problem. It would be hard to conjure up a more prime target for feature flagging. 

We went through a process. Anyone in the company working in the agency who had an idea for a side project could put together or fill in a proposal document, which answers some questions, “Who's the target customer? What's the product? Why would we be good at building this?” I'm looking. Some of these were written in 2016. We had about twenty different ideas. We built some of these as well, didn't we? They ranged from a Battle Royale top-down 2D mobile game to a Notion-type competitor, a wiki-type product. We had a mobile app that was trying to help people split bills in restaurants, and all sorts of different stuff. One of those was Bullet Train, which was the proposal that you filled out. 

When I first joined in 2013, we were working on what was very much like Slack at the time. It was inspirational coming from a business background that the fact that we could do this thing. I was sitting down thinking at the time. There is one key difference with Flagsmith and some of those ideas in that, with a Notion application or a Slack application, you could be one of the target customers for those products. You're servicing a wide range. 

Massively, almost any company in the world.

Coming up with all of the use cases for those different areas in business is difficult and impossible with our team. With Flagsmith, we were the core customer. We had a lot of customers in one place. As an agency, we were a startup, we were an SME, and we were all of those things at once because we were delivering products to those people. We were a bunch of talented engineers, so we needed to use our strengths. 

That's why I wanted to build a developer tool. One, to help us out, and secondly, to be the first customer before releasing it wider. I saw when we were servicing some startups, specifically, they have this behavior of coming up with excuses for the products. They would almost like blaming the customers, “Are they not understanding the product right?” If you're multiple customers in one, the proof is in the pudding. Can you use your own application or not? 

I'm looking at the template, the proposal document that you put together. One of the questions was, “Is this a problem you know exists or a problem you hope exists? If you know, how do you know? Be honest.” The answer was, “Because I'm the target audience.”

This was the easiest question. It was so easy. I had such a strong idea. I didn't even know the concept of feature flagging. I didn't know that existed in its infancy. It was definitely a lot different from what it is now. I didn't know that existed, but the ideas of what I wanted felt completely into what that was, not at the time, but what it is now. The roadmap, we've dealt with a lot of other stuff, but a lot of the things stand up to today, in terms of what we needed to do.

The other interesting thing is that the core product still looks almost identical to that MVP that we built years ago. Another question. Does Solid State have any unfair advantages in the market? Yes. We're the target customer. As you said, there are so many things that fall off that. Probably one of the reasons why there are so many issue tracking projects that have ever existed and things like that, because it's almost like you're not a seasoned engineer unless you've tried to build your own issue tracker. 

It is being our own target customer, being able to dog food our own products, and not having to rely on this enormous loss of information. If it were for a different sector, sure, you could go and interview 50 or 20 software engineers and ask them what their problems are around releasing products, doing deployments, and things like that. There's still a massive amount of information loss by interviewing someone for half an hour compared to having lived it for seven years. 

It's incomparable. Our experience was an extreme version. You get a lot of big tech companies releasing their own internal products. React Native is a good example of that from Facebook. The difference between that happening and what we did is that they had mainly their own internal company use cases, whereas we had a wider range of things that we were trying to achieve. It's almost perfectly shown by what we've ended up developing on top of that core product. 

We knew how to service from startups to larger SMEs. What we didn't have experience with was serving a lot of data-sensitive large organizations, which we later came to serve quite a lot. We didn't anticipate the features for that in the original roadmap. That took interviewing and doing a lot of customer development. That wasn't what came with the initial idea. We've gone through both.

We did put a lot of thought into what the product was and how engineers would use it, very much answering the questions of the people that were going to use the project and use the product day to day. One of the things that we were quite blind to is that for large organizations, almost always, the person buying the product at the start isn't the person using it day to day. What they're buying, what you're selling to them, and the things that they value can be radically different from what the engineers are going to be using the products that they care about. We didn't put much thought into the combination of open source, self-hostable, easy to deploy, and having a simple deployment stack. 

We were completely naive to the fact that, as you mentioned, that is a bullseye for data-sensitive organizations that can't buy SaaS. We think this is partly due to our experience that we would never have considered being a small company. There were people out there who, legally, weren't allowed to buy SaaS products and have their customer data exfiltrated out of their business on purpose. You mentioned luck as well. Up until that point, there wasn't that much luck involved in it. 

It was years and years and decades of experience trying to build products and trying to deploy products. There was definitely a point of luck where we suddenly started to realize that we had a SaaS product that you could buy. The growth of that was very slow. All of a sudden, in the space of about six months, we started to get a big steady stream of inbound sales requests from massive organizations that all had a common shape. It was that they were data-sensitive for whatever reason. It might be financial services, healthcare, insurance, or what have you. There was luck on that side, but it was fairly obvious to us. I remember realizing that we had to pick that up. That was another potential growth factor for the company. 

You're never going to know 100% what your product is going to look like in eight years' time. We had 2/3 of it locked down. I'm glad that we went through that experience of not knowing, going through, developing, and realizing extra value to the product that we wouldn't have even thought of. Another thing, as well as some of the scale of these organizations and the money saved, is something that blew my mind. It is the idea that an engineering team with feature flags can release code and not need to sit in a load of these release meetings. 

Everyone has to orchestrate this release of code for the QAs and the product owners to be able to do those parts. Empowering both sides to be able to work independently saves hundreds and hundreds of hours for these organizations. There's no way with our experience and the agency that we'd have been able to anticipate that. It's cool to see them so excited about what that means for them. I wouldn't have imagined that would have happened. 

What's your proudest moment in the company's history so far, do you think? 

I thought about this, and it's changed. Initially, it was being in a sales call, doing a demo to some of the organizations that you'd look up to. Some of whom are in the tech industry, whom you think are the people that you dream of talking to, and then liking your product. That was a huge amount of recognition from the start of thinking of this silly idea to some of the largest companies liking your product. That was cool. It's changed a lot. We all flew out to Barcelona. We've hired people all over the world, and we all got to meet up in Barcelona. 

There was this moment. It was 2:30 AM. Everyone was still up. Some of them have been working for the company for a few years at that point. They've gained closer connections to each other. Everyone was up, enjoying the experience, talking to each other. All of that came from a silly idea where those careers are blossoming. They're into working on your product. That is, to me, a higher level of what we've done and achieved. That's the proudest thing for me. 

It's interesting because it does change quite often. I remember when we went up to SaaS API and tripped over one billion calls a month for the last 30 days. I never thought I'd be working on a product. We were like, “This feature flag has got good legs in terms of an idea.” If you'd have said to me four years later, you'd be running a billion calls a month through your infrastructure, I wouldn't have believed that. I'm proud of that. 

With a remote company, getting people together from all over the world, from India, South America, and Europe, that mix of cultures, having different people with different backgrounds, different ideas, and stuff, getting together through it, and shared interest in software, open source, and stuff, that's been fun. One question for you. We can both answer. If someone is building an open source project and received an email from their first potential customer, what's one piece of advice you would give them? 

I can relate this back to when it happened to us. The first thing I would say is prepare for that upfront. Be optimistic about your own product. Prepare for it. As engineers, we're stereotypically not good at dealing with that situation in terms of pricing as high as it should be for larger organizations. I remember when we got our first contact out. It was after hours. We were at the pub. We were like, “We don't know what to do.” Prepare for it. Have an answer ready. If you're not sure how to price a product, get in touch with someone who has experience with that. You set yourself up for success for that and respond quickly to that. Don't leave it. Even if it's a holding message, respond back. Show that you're active and you're engaged. What about you? 

Mine is simple. It's interesting because I remember that moment. They were asking on our web chat, which was one of the other ideas that we had before we started using Crisp. A shout-out to Crisp, which is an amazing product. We built our own web chat. We were using that. It's weird. There are these two product ideas. One of them was the one that was generating this inbound lead. The question was, how much does it cost for an enterprise license if you're a platform? 

We were so unprepared for that question that we thought, “What's the best answer in terms of the number that we should give them right now?” The actual right answer wasn't to give them a number at that point. I didn't know about that. If you're in enterprise sales, if you're buying stuff on the enterprise side, I'm sorry that that's the answer, but that is the right answer. I've learned that now, having spoken to people who've got way more experience than me in terms of doing that. 

I'm going to be a bit of a cheat on the question here because the advice I'd give you, if you've got one inquiry come in, is to wait because what you're looking for is a pattern. For us, it was that the signal of the types of companies that were contacting us was so obvious. You didn't need to be this sales genius to figure out what that pattern was and who it turns out our target customer actually was compared to the assumption we've made. 

I wouldn't say it's an incorrect assumption because the revenue split of the business now is probably 70/30 to on-premise enterprise customers, to SaaS customers, but definitely waiting for a signal and a pattern. What you're looking for is repeatability. If you don't have repeatability, then you're going to be spinning your wheels. In the worst case, that first email might not have been a data-sensitive company. That might have been someone completely different. We would have gone, “We've got our first inbound lead. We need to figure this out. Maybe we should start building a ton of stuff in that direction.”

Just by chance, unluckily for you, that first lead isn't your target customer. You don't know that at the time. You're excited about it. That's completely understandable, but wait until you've got a handful of bits of data that you can then try and figure out. It might be that there's no pattern. You're going to have to go, “Maybe we're selling to a generalist population,” like Slack Art. Their target market is everybody. That's a signal in itself. For me, looking for a pattern in there is important. Final question. What's the most important thing to you in terms of building the company? What's the one North Star thing that you've got in your mind? 

Feature flags are not saving lives. The main thing is that people like your products. Nurturing the open source community is definitely a huge thing for me. I get less and less shocked now by big companies coming to us and doing demos to big companies. The one thing that remains that means a lot to me is when people are submitting pull requests to your products. They care enough to take time out of their day to contribute because we've had some meaningful value-added stuff like features, even bug fixes, and documentation. I love to see that grow. The company itself is doing well, but I want to see more in that direction more than anything. What about yourself? 

For me, it is making sure that everyone who works for the company is excited about it and enthused by it. One of the things that probably deserves another episode of this series is the challenges around having a remote business, because that was a COVID effect. We were having to build a company where you couldn't travel. We knew we needed people around the world to support a global customer base and things like that. 

That remote aspect of the business has been very different from running a business based in London, where everyone is coming into the office every day and everyone knows each other face-to-face. It is being able to solve the problem of making sure that everyone is happy, excited, and enthused with the business when, for 99% of the year, the closest you can get to each other is a Google Meet or whatever is tough. 

That's making sure that we're solving that problem, which is important. A lot of things flow from that after you've solved that, but that's been challenging. We're still constantly learning about the problems. My favorite example is we hired a guy in Ecuador. They didn't have a functioning postal service at the time. They didn't have a functioning delivery service at the time. I'm trying to figure out how to ship a MacBook to them. It's like, “I wasn't aware that this was going to be my day today.” Kyle, thanks for your time. Have you got any final thoughts? 

No. It's been great to sit down, talk about this, and think about our journey because it's been so fast-paced. It's nice to sit down for around an hour and talk about it. Thank you.

I might speak to the other Solid State guys. It might be time to publish all those proposals to give people an idea of what else we were thinking about at the time. That's one of those sliding door moments. I think there were a couple of other projects that weren't that far behind feature flagging as an idea that we thought had legs. Maybe that's a nice historical document. Kyle, thanks for your time. It was great to chat. 

Thanks.

‍