Value in Open #1 - PostHog

We are super excited to announce the first episode of our very own podcast! Inspired by the likes of rework.fm by Basecamp and Distributed by WordPress, valueinopen.fm is a sister-project of Meilisearch, intended to operate as an independent but values-aligned entity.

In this podcast we interview founders of open source companies (COSS). There is a lot of stigma around money in open source. "Commercialization" can sound like a dirty word for many, and is sometimes even viewed as the antithesis to openness. At the same time our community is fraught with burnout and churn. Countless projects that underpin billion dollar enterprises are run by volunteers in their spare time.

A new breed of open source developers are trying to combine their open values with sustainable business practices in the pursuit of long term stability and an ecosystem where the creators get their fair share. These are the people we will be talking to.

In the spirit of open source we are putting out these episodes long before everything is nicely polished and figured out. Any comments you may have on production quality, questions asked or the content in general will be greatly appreciated. Please contact us however you please.

---

Episode #1 - PostHog

[

PostHog - James Hawkins

Quickly and easily listen to Value in Open for free!

Value in Open

](https://player.captivate.fm/episode/e4572233-5e90-4783-a0cc-778237b3ac2f)

Big thanks to Jakob Terjesønn Rypdal for the awesome intro tune!

Transcript

Erlend: James,  thank you very much for joining me today.

James: Yeah, thanks for having me.

Erlend: You, together with your co-founder Tim quite recently wrote an extensive blog post about getting $3 million in funding for your open source startup. Can you very briefly lay out what you announced there and what has been happening recently with your company?

James: Sure. So we're PostHog, we provide open source product analytics. We started working together back in August last year, and went through a couple of pivots. We did the Y Combinator batch kind of January, February, March this year. We started over from scratch in January, launched in February and kind of started doing the seed round, I think in April/May.

We just announced that we've raised about $3 million. So it was kind of quick as a turnaround to go from nothing to that. And that was just a really exciting time because we're able to kind of, increase our engineering team basically.

Erlend: Let's go all the way back then to see what sort of journey led up to this. You had this funny little note on your website that in the early days you even had a career, or at least an attempt at a career, as a pro cyclist?

James: Yeah, I spent 10 years, sort of like from about the age of 15 to 25 ish, doing it all the way through college and afterwards for a bit, kind of racing around. I live in the UK, but we used to go to Belgium every summer for a few months and there'd be like five of us living in a farm house with often no running water and just really bad living conditions, trying to win.

And the only way to survive was to try and win money. The good news is in Belgium it's so popular. Getting into the top 50 is usually enough to make some money. It wasn't the case of winning so much as just trying to get by. But yeah, I did that for a really long time.

Then I had a few, very big crashes and thought I should probably get a proper job. But it was a cool, it was like a slightly weird style.

Erlend: So that eventually turned into a career tech and internet businesses. Your first job, was a job that you came into or that you bootstrapped yourself, this marketing company that you first worked with?

James: I used to do web development stuff in the evenings to get a bit more cash. This is a nice thing to do when you're sitting down after a long day on a bike. I wound up bootstrapping a company. It was owned by someone else, but for me it was kinda fun cause I could just do whatever I felt like.

We did lead-generation. So, we’d find homeowners who wanted to buy stuff online, often like big home improvements or solar panels. A lot of renewable energy products. Visitors would come through our websites. They’d book an appointment with us, and we would explain how it all works with financing and stuff.

And then we'd, if they wanted to go ahead, we’d connect them with the installer that covered the local area. We’d transfer them on the phone to an installer who would then put in an appointment and go out and do the meeting. We charged per apartment. It grew pretty quickly.

That's where we started doing analytics. Conversion rates are really, really important. We had a lot of algorithmic stuff for how we phoned people. So someone makes an inquiry on your website; there's a lot of science behind how to ultimately call them. So we got really into that. We had an open source dialer that we heavily modified to try and work out who is the best person to call next. That’s the first time I used heavily open source stuff.

But yeah, the analytics has always been of interest because I'm a little bit commercial as well as quite technical. It was a quite fun place to work, but it wasn't really something we thought we could get really big at some point. So we eventually decided to move on.

Erlend: What was your impression of these open source projects that you were using at the time? Like, were you curious about how they came to be and how they were maintained?

James: I think I didn't appreciate open source enough back then. So for us, it was much more something that we ended up forking and just putting all these like weird modifications into ourselves for just our own self hosted thing. And we used CodeIgniter which was like an old PHP framework, to build all of our data handling stuff in.

But again, I wasn't in the habit of doing pull requests and contributing back. In hindsight, that's absolutely what I should have been doing. Cause it would have helped me become a better developer to kind of generalize the use cases that we were building and the code quality would probably be a lot higher.

So I think I would have learned much more if I had realized that early on, but I just didn't at the time. It was my first proper programming that I ever did, so I was maybe a little bit naive.

Erlend: So lastly, about this first venture of yours, the bootstrapping part of it, what exactly does that entail? Were supporting yourself on the side with different work while building this business?

James: Yeah. We started off with no revenue at all. The person who owned it was happy to pay my salary at the time. I think cause I was kinda new and young, so not that expensive. We wound up doing about a $5 million a year run rate with about 50 people on the team. So that grew quite quickly, but it was a real balancing act. There was a lot of pressure to be really on top of things like invoicing and collecting money from our customers in order to then pay our advertising bills. Cause we're spending a ton of money on, like ad-words, Facebook ads, all that kind of stuff.

That was actually where most of the stress came from. I think we over-focused on that area. we're dealing with a lot of small businesses who are often late paying. Sometimes they’ll be struggling financially. They often depended on us to help them generate revenue.

And so there'll be nasty side effects where for example, one business would be like, all of its sales would come from the leads that we're providing, but if they get behind a bit we can't just cut them off because it could kill the company. And so then they would never pay the bill. And also it's really sad for them.

So we end up having this strange kind of balancing act of trying to like collect all this money and on-time in order to be able to increase our spends in all my marketing. So the financial side of that was probably the most stressful side of the whole thing. The upside of it was, it kind of forced us to find a level of product market fit.

It forced us to build a real business very quickly. The downside, I think, was those sort of fairly short term problems like chasing money off people were really distracting for us. So it made it harder to really focus on the technology. There was so much more thing we could have done with that.

Erlend: So you ended up moving to this other company called Arachnys where you met your now co-founder, Tim. Can you, briefly lay out how that came together? Like how did the two of you connect there in this company and started talking about a new venture?

James: I guess the reason I ended up moving to Arachnys really is, it was just like a really professional company filled with really bright people. It was just kind of obvious when I met them. So I kind of wanted to go there just to get a bit more experience before doing my own thing again.

And I thought the founder seemed really, really bright. I got on really well with him the whole way through, and he ended up becoming one of our investors at PostHog afterwards, which is really nice.

Tim, I used to.., I was supposed to run our marketing, because I'd been running like a big online marketing kind of business before, the tactical stuff. I wound up running our sales team there, doing Enterprise sales and SAAS. We use to sell compliance software to large banks. Tim used to run the R&D sort of function. So he'd build prototypes of new functionality.

Often Tim would build new functionality that I would take into big exec meetings with someone really important in the bank to show off, Hey, this is what we think the future of the software could look like. Do you have any feedback? Do you want to maybe spend another million dollars with us in order for us to productize this for you?

So the two of us worked together, not intensively, but we certainly worked together with lots of customer meetings, that sort of thing. So that's how we got to know each other. Tim, from my perspective was just incredibly strong at engineering and he was incredibly quick. Really knew what he's doing.

Erlend: How did you recognize that? What were you seeing in him that made it clear that he was a very strong engineer?

James: The level of speed, was just really obvious. Like you can say, Hey, we've got this cool idea from a client. And the next day that'd be something that I could walk in and demo to them in real life. So that level of speed was really important.

Our first big enterprise customer, it was a very large tier one bank. And the contract at the time was about $700,000 a year or something. We won that. They had gone with another vendor. We persisted. We kept trying to say, Hey, we think we're a better solution. The other vendor failed to deliver. And then the we delivered in 48 hours what the other vendor had failed to do over the course of a year.

Tim was always great at if you really need something done that day. So that was the thing that really impressed me about his work.

Erlend: Mm. So the two of you started thinking about doing a company together. What were the earlier conversations like between the two of you? Was it mainly just, we want to start something together, anything?

James: So Tim got another job somewhere else. And then within about five minutes of hearing that I was like, man, I need to go speak to him. I started feeling that as a head of sales, I just thought there would be people who will be better than me at my own job once we got beyond a certain point.

So I was sort of thinking maybe I should go do that startup idea. At this point, I had a couple of ideas to work on. Tim quit, which then was like, okay, right. I think I need to get on with this. So as soon as I knew that he had a job somewhere else, I thought, Hey, I'll buy him a beer and then we'll go talk about some random ideas that I've got.

That was how we started. I ended up leaving a few weeks later, and then we set off building our software, speaking to users, and trying to get traction, for quite a long period off of that.

Erlend: And the company you first set out to make was quite different from what you've put out to the world now. What was the first idea you pursued and how did that turn into a pivot later?

James: There were actually two ideas. I've only written out one of them. This is too much stuff, it's kinda confusing, but okay, let’s try it. So the very first thing we tried was: I used to run a sales team, and I just felt from like knowing lots of other heads of sales that, people don't use much data to drive their management of their own teams.

So they'll often have a forecast and you kind of list out every single deal that's supposed to be closing. But the problem is, everyone focuses on the stuff that's supposed to be closing, whereas it's kind of irrelevant. Like if you have enough pipeline overall, not just like the very late stage deals and you're managing towards that. Even if some stuff falls out, you're going to be fine. So we built a tool that would help sales managers do one-on-ones with a team, and it would use predictive analytics, integrated with Salesforce to highlight deals. The deals that statistically looked like they were going to drop out, even if they're like really early stage and no progress is being made, it would say, “Hey, this early stage deal; we think it's going to die”.

So we built that out. We didn't do a very good job of speaking to potential users. Like we spoke to lots of them, but there's a really good book called the mum test. I don't know if you've seen this,

Erlend: Yeah, I'm familiar.

James: Where the premise is kind of, don't talk in hypotheticals with your users. If they haven't actually done anything to try and solve that problem, they're probably unlikely to want to spend money on software to solve it.

We didn't do that very well. We were much more like, Hey, would you pay for a tool that would help you judge which deals to talk about so you kind of get more out of your management time with people. We built it very quickly. We launched it, we sent it out to 15 friendly heads of sales or VPs of sales that I'd kind of met through networking.

And I think the end result was like one of them clicked the link and promptly used it for a single week and then stopped. It was kind of obvious that we had a problem at that point.

Erlend: At this point you had not yet applied to Y Combinator or anything like that. It was just this first trial run of, let's see if we can build a product and a company. Didn’t quite work out on the first go around. And so now you move on to a different idea. Are you already, at this point, thinking about, we also want to try and get funding for this.

James: Yeah, we started off thinking we're going to bootstrap and we kind of just defaulted into it. So we kind of thought, well, we've saved, you know, a year's worth of money or whatever from having been working for a long time. And so we thought we can give this 12 months, and then see where we get it.

And if it fails we'll just have to get a job again. So we started off bootstrapping. That was probably helpful when we were doing SAAS thing, because it encouraged us to talk about money with people. So people would pay for stuff really soon.

Eventually we tried another idea around solving technical debts.

The two second summary is we built like a little survey that would integrate with your Git repo. And we'd seen some challenges with this when our engineering team got bigger, and we heard a lot about it from our other engineering friends. We started signing up lots of engineers. We got to a couple of hundred users, but we just felt that we weren't really solving the problem properly.

It was around this time that we applied to Y Combinator. The reason why we decided to switch gears is we looked back at what we chose to do in our careers. We kind of took the view we want to try to do something really big and make a big change. And we felt that VC will let us do that more quickly. I think with bootstrapping, we probably could, I think we could have pulled off being able to cover ourselves a salary and building something up, arguably more sustainably.

But it felt like we may well spend five years getting back to the same kind of level of income that we already had because we had quite good jobs, so it started feeling like it would be a lot more stressful along the way. And along the way, we're gonna earn a lot less money. So it's going to be quite painful and stressful and slower.

I just started thinking like, well, I could see in like two years time, we might start struggling for motivation or to keep the pace up because we both liked doing stuff quickly. So yeah, that's kind of like the chat we had and then we just sort of, we just felt on the VC side, we can very quickly go over this.

There's so much financing available, or certainly like pre-COVID, at least. So we thought, like, why not? Let's take a much bigger moonshot and just see if we can land it or not, because the outcome is going to be the same either way, like, we'll end up having to get proper jobs afterwards if we failed in either of these cases.

And so that was kind like the conversation we had early on, where we thought we're considering switching.

Erlend: Yeah. And in your application to Y Combinator, like what is the gist of that? Cause you've described it on your blog as maybe not the strongest application. But it must have been pretty strong since it worked out! But you didn’t feel that going in?

James: Yeah, there was this sort of aura around YC for Tim and me because we're just both avid fans. We read loads of engineering blogs and it always felt like some mysteriously impossible thing to get into. And neither of us had raised money before.

So we were like, well, maybe we need to network and try and hustle our way in, or something like that. And we just weren't getting in if we don't do that stuff. But in reality, we basically just followed the instructions. I think if you're listening and you think you fit Y Combinator, you can just follow the application process.

Initially we wrote out this really long application spending way too many words, describing what we did, and trying to be overly sophisticated and clever. it was about 10 o'clock the night before, and we sat there and just went, this application is not very good.

So we deleted it, started from scratch and rewrote the whole thing in about 25 minutes. The gist of it was basically: we've achieved like a bunch; we’ve got tons of users really quickly. This is how we think we can solve this problem. This is why it's a big problem. It's a problem we've seen before.

We just kept it incredibly simple. I've also been shared a few applications from founders have sent them to me.

Erlend: So you get into Y Combinator, you move to San Francisco as well, both of you. And you kind of get into the YC sprint of sorts that they do. But not that far into this journey, it sounds like you're you realize that this isn't the product that you should be building.

James: Yeah. So I think as soon as we went into YC, we had  been pretty disciplined about trying to make significant progress every week, because we kind of knew it doesn't matter what size you are. It matters the direction you're going in and the rate of progress. So we've really been quite big on trying to make progress each week when we got into YC, it just felt like there was more pressure.

We also have more business focus because we, like at the start of the program, I think Michael Siegel says, Hey, this gives you a socially acceptable excuse to look after yourself, exercise and work and not very much else, which is exactly what happened. So we just started working. It was the most productive period of our lives, for both of us.

I think we just very quickly started realizing that we're not solving this problem very well. We met tons of heads of engineering in person talk about what we were doing. We spoke to existing users, but we just kinda realized that we weren't solving the problem very well.

Tim and I also kind of felt that we're not really the right founders for the problem that we were trying to solve. We both quite like kind of growth marketing analytics combined with technical stuff. and along the way, we'd got frustrated with our experiences with product analytics. The partners were like, Hey, it feels like you should switch. So we just did.

Erlend: That change of direction seemed to coincide with you going the open source route. So what precipitated this? I understand you had certain talks with people who had made other successful open source companies. So I'm very curious what those conversations were like. And what, in particular that you picked up on there that made you go, okay, we're gonna make this an open source product and make a business out of that.

James: Part of the reason we founded PostHog is that we just didn't want send a lot of user data to third parties; we felt it was a little bit invasive.

And then there's a couple of like pet features that we wanted to build into our analytics as engineers. So we're kinda thinking like, well, how would we like to target product analytics at an engineer to make it useful for them? I'm not really thinking so much about product managers who typically have used those tools.

And we thought, well, how would we let you self-host it? We'd have to give you access to the source code so that you can install it and stuff. So we might as well make it open source. We then got really stressed about licensing and started reading through the licensing of Elastic, MongoDB etc.

We started getting weirdly paranoid, we’ll get left out or something. So we spoke to the partners at YC and they kinda said, we don't know, go and speak to a bunch of open source founders. And we just asked their advice and they were pretty much universally really friendly. Within about a weekI think, just to learn what we're doing.

We met with Ian Tien, the founder of Mattermost. It was incredibly helpful. He spent like an hour on the phone with us. Then he gave a talk by chance that we went to. GitLab was also really helpful. We had a couple emails with Sid who's the co-founder. But also because GitLab documents everything transparently it's a really easy way to understand how they work. Sentry was also helpful.

I met David Kramer when we were actually thinking of pivoting. I was like, we’ve built this thing for technical debt, like, what do you think? And you could just tell he didn't care. So I was like, there’s this other idea: do you have like a big, complicated self hosted product analytics? And we just started talking about it.

There were kind of three or four founders like that, who just kind of told us what to do. The premise is basically, don't worry too much about licensing, just launch it and see if anyone cares. Just make sure you document stuff properly. Don't try and make money out of like an individual engineer for something open source.

Just give freely to people and you'll get inbound interest from bigger companies. So we did exactly that.

Erlend: So the advice was essentially. Don't worry too much about licensing. Just put it out there in the open, get users and you can worry about protecting yourselves later.

James: Yeah. If you've got a community of thousands, it's going to be contentious to change the licensing. But if you're just getting started, I mean, we looked up the main kind of existing models for this, you know, like open core, charge for hosted versus self hosted or kind of services based.

We ruled out services cause we just felt, we just felt it's not as leveraged. Like you're always gonna have to focus on margins and it's gonna be human intensive. We do have a services offering, but basically it's so we can learn new functionality that can automate a lot of that work.

We just decided that a lot of our benefit is allowing you not to send your user data to third parties, if you're like a really big company or if you're more privacy focused. So for that reason, we just felt cool open core kind of makes sense for us.

So we'll just start with that and we'll build an MIT license product for totally free for now. That's all we're going to try and launch. We're not going to try and build like the paid version of the product with better functionality for very big customers. You've got to be successful for someone to bother copying you and you're not successful when you're starting.

For the same reason you probably prefer to drink Coca Cola rather than the one from like your local supermarket, we just felt that you don’t win by following. So yeah. We just launched and stopped worrying about it. And then that just gave us enough feedback that we're then able to learn what to build next.

Erlend: So is it fair to say that being open and especially self hosted is PostHog’s main differentiator compared to the competition? It sounds like that was your main priority. That these other ones, they're just sending your data someplace to some server you don't have control over, whereas with PostHog, the customer will have more control over that.

And open source is essentially a very standardized well-understood way of giving users more control over their software.

James: Yeah. We have like two hypothesis for this to start off very early, where we're like the, exactly that like you want control of your data. We imagine the big companies that want control of user data. I mean, there are lots of developers who want this in smaller companies where a startup may not care that much, but an individual developer really does care about this because it's kind of considered wrong to show data quite often.

So we kind of thought like this will get us enough people who care about this, that we think we can then grow from there. The other thing we kind of believed in was, if you're tracking all the event data that's happening in someone's website or application, and if you're providing a hosted service, you're going to build up all this data, which will cost you a bunch of money.

It's a host, so you kind of have to charge some proxy on your usage, on their usage level. So they're like the volume of users, the volume events or whatever the problem is. Like some users are really valuable and others aren't. So if you're in B2B and you're selling, like accountancy software that you use for your payroll, you know, you might charge like $50,000 a year for the app, and then you have a couple of users, but then if you're a B to C you know, you’re Pinterest or something, you'll have very low marginal value per user, but a massive volume.

So we believe that, when you get beyond a certain scale of usage, the, pricing model based on the number of users is going to get really unappealing at some point, cause you're having to try and make money and you're kind of guessing how much it's gonna cost to host, as well.

So we just felt like we can be more on the side of our customers if they're very big. We spoke to a few people who starred our repo. If they worked at like cool companies I’d often just try to buy them a coffee, just to understand like, Hey, how'd you think about this at the moment.

And we kind of learned that really big companies very frequently self-built their stack for this stuff. So we thought, Hey, PostHog is an alternative to doing a lot of that. Eventually when we're going to get more scalable and stuff, one day.

Erlend: Yeah, I've, I've written a bit about this myself as well. That being self hosted, it just also builds in this kind of transparency into your business and the way you do pricing, because you're essentially competing a bit with yourself as well by having your product so easily usable and so easily inspectable by others.

James: Yeah, I think like with open source, it kind of makes it easier to get a lot of users quite quickly. I think it will make working out how to generate revenue significantly more challenging, maybe, because it will end up coming a bit later.

So, it is kind of on the downsides that you need to work this stuff out. But one of the big things that we're doing is we're focused on engineering adoption rather than product managers. We want to help the engineers themselves understand who's using their stuff. So if you're going after engineers, being super salesy and having non-technical people dealing with them, we just felt was a recipe for frustrating people. So we're just trying to be really straight forward with this stuff. and giving people the choice.

They're not a group that are easily swayed, apart from features and functionality benefits. It's quite clean cut, which is a cooler way to do business. Cause you just spend less time, you know, playing off against each other over pricing and stuff.

Erlend: So, can you speak a bit more to that. At this point you're on your way to this larger funding round. And during this time, as I think you still are, you were very engineering focused and focused on building a community. So what did that look like in practice? This building of the community around PostHog?

James: Yeah. So, what we try to do basically is, when were back Arachnis, when we sold, like, our first, really big enterprise deal. We, the company just did a really good job of looking after them, which sounds kind of obvious. But basically every time they offer something, we either gave a reason why weren’t gonna do it, or we built it really quickly for them.

And so we've tried to give that level of service to our open source people. So if someone's, you know, good enough to write an issue, get feedback, raise a bug, we'll just solve it for them pretty quickly. And we've just repeatedly done that because it shows people that we care about the feedback that we're getting.

So it encourages people to give you more feedback or to offer more features. I think it's a challenge to keep the products reasonably well defined so that you don’t get pulled in a weird direction or, you know, engineering it for one particular user. We do our best to ask for context around what are you trying to solve with this feature?

But probably I would say most of it is we'll get like random bugs being raised. Those are obvious. Like it shouldn't have bugs, we should just fix it. So, we've just tried really hard to be very responsive to all the early people who've kind of believed in PostHog from the first few weeks.

So I think that has probably helped give us a good reputation at least. And that's how we're trying to invest now. It's this key focusing on our engineering strength. I'm not hiring customer success people that just escalate all these cases and don't really solve the actual problem. So we're trying to connect engineers with engineers as much as we can, which is capital intensive.

Like we need to invest in this to do it.

Erlend: Yeah. In your funding blog post you also mentioned during this period of March and April, the time around there, your bank balance was already going up. Was that like seed funding coming in or early customers or..

James: I was just trying to explain how this probably looks in practice.

Basically it turns out you'll hopefully have a few angels investors who can give you like smaller checks and a lot of advice and help and introductions. And they'll stay there and they're still incredibly useful to people, to us. Like we'll ask random questions all the time. It gives you like a little bit of a momentum.

But it's towards the end that we found the process just really sped off. Like suddenly you got one offer, then you got like another three or four, if you've managed to speak to everyone at more or less the same time. So it was just to try to get a sense of like, Hey, we're steadily getting like small checks coming in.

But towards the end, it just ramped almost immediately. It's really odd if you're lucky to get into that position. It's very strange going from kind of selling all the time to then having to be really picky over how you kind of compile the rest of the round so you don't have to sell too much of the company too early.

Erlend: And so all of these investors. A couple of years back, it would, probably sound strange to people that there was any investment at all in in open source companies. But did you find that the ones you talked to, they just understood it when you essentially said to them, like, we're just making this open source product. We're gonna get a bunch of people using it and we'll figure out the money part later. Is that essentially what you told them?

James: yeah, it's shifted. So first, I think we were less confident going through that. Like if you raise money and through that kind of fundraising process it's almost like getting a load of consultancy over your strategy because you'll get pushback from people and you get like a lot of standpoints and some people who directly contradict each other or whatever. Yeah, we started off thinking, okay, the plan is we'll build a paid version sooner rather than later, so we can try and get more control of our spending and stuff. And it just makes it, it feels sensible to do. But then we like in the process of doing all these pitches, I was like, Hmm, this doesn't feel like it's landing that much with people.

And then we started talking about ourselves. and then we started looking at like other companies that got really big, that did open source and we kind of just felt that, if we want to actually really build something big here, it seems irrational to stop focusing everything we have on.., like I've done sales before, I'm kind of happy cold calling a bunch of people to try and sell a contract. But it's just if we do that now we'll have to build the paid version of the product, which means our whole engineering focus will switch. And we won't be able to pay attention to the community as well, because it's inevitable that we'll have to build a paid product, which will pull our focus.

And then we'll build something that's kind of sensible, but it's not the kind of big swing at something much larger a venture capitalist is going to want. And that's also kinda what we want to just try and do with what we're here for. So for us, we just felt like the other route equally have worked, but it just wasn't landing with a lot of investors, and then it made us realize that maybe that's actually not the right thing to do. We'll keep it even simpler. Like just make the free version. Awesome. Then work it out from there. Yeah, that really became a bit softer. Well, and that's also what we now really heavily believe in.

Erlend: So you got your big funding round. We're pretty much up to present day now. What are the basic stats of the company at the moment? Like how many people are working there and what's your adoption like?

James: Sure. So we're kind of getting about, probably around 20 new companies install it daily now, organically, which is great. Some have come from a couple of blog posts that we've done that got popular on the web. Just writing up about what we're learning. Most of it is coming from word of mouth, which is pretty cool.

We're seeing a lot of organic growth. I think the things we're needing to work out now are.., it’s kind of ironic when you do product analytics that you're like, Oh, we need to have tracking over like, how are we growing properly? But often we won't have the features that we need to do our own tracking, so we'll have to build them first.

So building out, we've been trying to build out all the things that we actually needed to track our company's growth. And so we're trying to do two things really: We have product work that’s just features that we believe are going to be helpful, that we've learned about from user interviews.

So we're trying to turn into more of like a product experimentation platform, that means just feature flagging. So we believe that by integrating feature flags with product analytics, you can give developers more control. Like here's some crazy features. Because it's crazy, you should probably deploy it to 1% of your user base and then look at the impact it actually has on your metrics.

That's how we can give you as an engineer, more autonomy, which is why the product will become more appealing. And we've learned that a lot of the like very big tech companies have built this in house. So we thought, Hey, we could like productize this. And so we're trying to build more functionality like that.

And so we have people focusing on that, like just a small team. We’re still, six people at the moment. The other side is, thinking about growth engineering. So kind of saying, okay, we've got some stuff that's come from these interviews that we're working on. The other slice of stuff we're thinking about is, is there functionality that will help us to grow faster?

The dream is basically if an engineering installs it then more than one other engineer, joins as a direct result. Because then we'll end up with an exponential growth rate. That means like, okay, when an engineer installs it, how do you get the rest of the team to use this tool. So, some of the product functionality we work on that we think will help, like if you're using it for feature flagging, other engineers will really need access to it, which could be cool.

But also things like, letting people collaborate over their stats, so tagging and analyzing graphs. So we're going to have a couple of people who are more focused on, functionality for that purpose. But that's pretty much it. We're not hiring any salespeople.

We're not gonna spend a ton of money on marketing. We're really, really trying to keep it driven from the product itself because it’s getting organic traction. So if we can just lean into that, if we do spend money later on it'll just be way more effective.

So I think by trying to like be very product-led it allows you to be more focused and you can build a product with very high standard because you're not getting distracted by doing sales and stuff, but that will create revenue pressure at some point.

Erlend: Where are you interacting with your users? Like naturally there's GitHub. So what are the other channels that you're talking to your users on?

James: that's a really good question. This is something that I'm not sure if we're getting it right or not at the moment. So GitHub is obvious. We get issues there. We’re remote first, so all of our discussion happens in the open and we'll often get bits of feedback from developers who see stuff, and it gives us a sense of what's going to be popular and what's not and therefore what we should put more effort into it.

We created a community Slack group. which has been fantastic for getting kind of like more intimate discussions with people. So if someone's trying to debug something and they want to share some screenshots, we’ll create a channel for that company and get a couple of their engineers into it.

That's really helpful that way. But the flip side is, it feels a bit, ideally we'd actually have that as more of a forum. So that it's indexable and easier to search. The reason we haven't done that so far is I often feel personally like the bar to posting a forum is quite high. It would make me nervous if I'm a newer developer, it's like, Oh, this is gonna be on the internet forever.

As opposed to some random Slack message. So we felt there was a trade off between the two of them. I would love something that would convert our Slack into a forum automatically. It would like sync them or something, for that reason. Cause that would probably really people who would like to see other problems people have had.

So that's something that. It's kind of annoying me. I don't think we've nailed yet, but, Slack seems very helpful so far.

Erlend: Yeah. I think a lot of us are waiting for the perfect chat-forum hybrid that can easily give you that early user group of people just ephemerally talking together and being very low stakes and have that gradually transition into a full fledged forum where we can talk more async and then also have content stored in the public and in perpetuity.

James: t’d like the general room to basically be a forum. And then for the people to have to go to messages, one-on-one if they've been uncomfortable for some reason. And then the ability to hop the conversation out into the public one. If it's like, can we. So, yeah, the dream one Christmas, maybe.

Erlend: Yeah yeah. I'm very curious what your thoughts are on VC funding in open source. We talked briefly about this by email and I thought your answer was very interesting. So I'd love to hear your expanded thoughts on how does VC funding interact with an open source product and where do you see the incentives aligning.

James: Yeah. So I think, something that maybe not enough people.., I might do wrong, but like my perspective is basically I think open source is fantastically well positioned, to disrupt a lot of SAAS, which should make it appealing for VCs. the specific reason I think, I believe that is if you believe in product growth, like, yeah, if you look at the way Slack has grown or, any of these companies like who have just done an exceptional job of the product, be incredibly useful and also naturally getting across lots of users from like one user to many, open source is like an even better version of that. Potentially.

Obviously you need to build features like that, that are gonna help you grow here. But by being open source, you can go into production in massive enterprises without any information security with no vendor risk management. You know, if they can see an MIT… or much less than you would have with having to bring in a new SAAS provider, because the data is staying on your infrastructure, you can access all of the codes so you can inspect it if you've got any security concerns yourself. And it just allows to get adoption to much, much bigger companies, really easily, as well as also be more appealing for digital developers. So it just takes friction out of the adoption process. So yeah.., it wouldn't apply to any kind of SAAS. Like if you're a CRM, I could see being less successful, maybe, because it's not something a developer would use. So they're not gonna care as much about doing pull requests or raising issues. But if you're building things a bit closer to products, I think it's really, it's like just much more appealing.

Like if I'm an engineer, I see something open source. I'm likely to want to install it. If I see something that’s SAAS I'm like, do we need another account somewhere? I'm going to get a sense of lock-in, You know, it's not free forever anymore. I just think if you're building something engineers are gonna use and there's a SAAS version but not an open source version, I think there's a really easy route there. I think some investors have started really seeing this where I think the mentality is almost like if something open source is getting popular.., like pick a developer off the street and ask them what open source libraries they're using. That's probably what I should fund. So some are absolutely like that.

(…)

But there are definitely some investors out there who just want you to build something that gets really heavily adopted and becomes incredibly popular and then they believe it will work it out. And so yeah, we found it was quite polarizing when we spoke to people, how they thought about this stuff.

Erlend: And, How do you feel about the VC pressure? There is that sort of expectation of going big in some way and about having that type of exit. How do you feel about that and how does that come into play with just the day to day product development?

James: That makes sense. I'm sure there are some VCs who maybe are annoying to work with. But our experience was, they were incredibly friendly. We just didn't come across the stereotypes that we're expecting, from reading about it online, like people gave us good feedback on why they would or would not invest.

They're helpful. They're nice. They send nice WhatsApp messages. So I think VC pressure maybe happens in a vacuum. Like if you aren't opinionated, when you go in, you maybe will end up with their opinion, steering your decision making. And so, like, I think when we were earlier, when we started doing the first few pitches, we weren't as strongly opinionated.

Like we hadn't thought through the strategy enough, we didn't strongly enough know what we're doing, but it forced us to have a much stronger picture. So towards the end it’s like none of this money is going on a sales team. It's going on engineering and products and the design of the product.

We're going to follow product-led growth. We're not going to charge users like individual developers. We're going to focus on the free products. Now it's aligned perfectly with building a cool community.

We know later on it's inevitable, like maybe series B or C, whether it be way more pressure on revenue. So we will have to work that out. but early on, I think if you're really opinionated and you truly believe that's the best way to build something great, you’re on their side. So yeah, I think I'd almost argue in SAAS as opposed to open source the incentives are further away from the users perspective. So with open source, even if we like, something goes wrong, like the repo will live forever. So, it's almost a little bit better for that reason. If it's early stage, I think that's maybe why some people adopt open source libraries when you're earlier. Whereas with SAAS, you're like, Oh, if this service disappears in six months or something we're stuck.

And so, yeah, I just haven't felt that strongly as you'd expect from maybe reading stuff online.

Erlend: What is your relationship now to open source? Like you kind of came into it a little bit from the outside, only dabbling with it as this, nice little for-free benefits as many developers do. To suddenly being fully invested in it as an open core company. What's your relationship to open source now? Do you feel like you're part of the movement. Are you a part of the group now?

James: yeah, I've like completely fallen head over heels in love. It’s just like, I've been missing out. Like where has it been all my life? There's just so much cool stuff with it. I'd be kind of absolutely loathed to run a non open source company ever again.

People are really nice. They give you a good feedback. Sometimes the feedback can be quite blunt or direct, but that's kind of what you need if you're trying to set something up that needs improvement. And you see expertise from like a really diverse group of people.

You know, whether it's something through the accessibility, like we're trying to host it in a particular way or like an unusual use case. And it's just, it makes it easier to build something useful for people. And then there's a cool sense that like, people can use this totally for free if they can't afford it, you know, to give you money.

So it just feels more welcoming, as an approach. And the cool thing is that means you get, like, when we're hiring engineers, that's a huge plus that we can get really good people much more easily, I think, than we would've otherwise been able to, because they also want to like get back to engineers and stuff.

I think I've be missing out by not trying this sooner. Maybe I was paranoid. Not knowing how you could set up a company around it perhaps was the subconscious bias I had.

Erlend: These days, what would you say is the purpose or primary function of open source to you from your perspective?

James: Good question. So, for me, it's just  control. Like you just don't get locked into something. It's powerful. It gives every engineer, like users more control over what they're doing. Like if you don't like something, you can change it. you can do a pull request to build some to extension if you want to.

So I kind of just like the freedom that it gives people. And that's on both sides. When you get engineers working on your repo, doing some pull requests to improve something, or even just raising an issue and saying, Hey, wouldn't it be cool if… And so you just get that kind of level of feedback from people because it's kind of nicer for people to work with.

You just get much more Goodwill. And I think that comes out of like, there's a bit more freedom involved in it.

Erlend: Have you found that you're also getting motivation from the activity that you see coming from the outside, like other people's energy kind of giving you energy as well in building this in the open.

James: Yeah, it's really cool. Cause we’ve tried to do it the whole way through it. Like we've just kind of like completely leant into it. So that's kind of why we've got a transparent handbook so you can see our expenses policy or how we hire people or whatever is all detailed.

So we're seeing like a lot of other open source people who are running open source projects that are wondering like, Hey, can I do this as like a full time thing? Or maybe I'm like stuck, like a very early stage startup and I'm trying to grow. So, yeah, we’re starting to get quite a lot of people reaching out who are trying to like get cool projects out there. It's just really fun trying to help other people to get more cool tech into the world that can modified. So yeah, that side of it is particularly motivating, I think at the moment.

Erlend: For those who want to start their own open source centric company, where would you recommend they start their journey? Where should they begin their reading?

James: So I think, I think the first thing is you need to have some sort of pain point yourself. It’s going to make your life a lot easier. You could just try and do it for its own sake and you don't actually know what the project is going to be. Or at least you need to have like a couple of random ideas that you are willing to really heavily test.

If there are pain points you felt, at least you've got over the first hurdle of finding one user that would use it. Like it needs to be something you would use. Once you can work out what that might be.., we just used to keep a big Google doc, and every time we got annoyed writing software we'd write down a little pain. So we have like a couple of pages of ideas. Once you've got one that you actually feel excited about solving, like that's, I think is key. If you're not excited, this is one of the mistakes we made with our other idea. We just, we weren't excited enough about it.

And you're going to end up doing this for a really long time. And you're going to be up for like midnight writing code to solve this problem. So it needs to be something you really think is cool. And it can be really small to start off with, once that's happened you need a rough plan for how you're not going to run out of money. If you've got a full time job, you can do stuff in the evenings, make sure that you're allowed to do that with your employer so the work doesn’t belong to someone else. If you save some money, like give it six months, like, especially if you're in an engineering role, there are tons of jobs available. So if you want to like spend six months just set a time period to try and get this thing off the ground. You’ll probably manage to get another job afterwards, if something goes wrong. And like the upside of that is, you can end up working full time in open source, which is really fun and can be really great for your career.

The alternative is, if you move jobs, you might end up finding a better job anyways. So, you know, it just felt irrational sometimes to not just try it. I created a personal budget. I knew how long I had to get stuff done and I just worked really hard.

I think finding a co-founder is very important. You could build something kind of cool by yourself, but I think you could like lose your mind in the early stages when you don't have any users and you start questioning what you're doing. So I think the two of us has really been very helpful, like when we were fundraising. Basically I exclusively fundraised and Tim did literally everything else: Handling the entire community, all the pull requests, all of the engineering and development. And the two of us managed to get that done. I think otherwise I'd got disheartened in fundraising, perhaps if I was trying to do like all of this other stuff at the same time. And there's two of you both committed, so you kind of have to not let the other person down.

And then on the funding side you're gonna need some level of traction. If you build something good, like, put it on Hacker news or whatever, just to see if anyone cares and do that sooner rather than later. Like before you feel like you're actually ready because you're better off spending four weeks building the wrong thing than spending six months building the wrong thing.

We gave ourselves precisely four weeks, to go from nothing to putting it on there. And that gave us all the growth we needed to do the fundraise. So, you know, just give yourself a window. But don’t try and get to perfection. Like it can be really rough, it just has to have like a readme, some of the other documentation and it needs to sort of solve your problem and not be hideously buggy. But there’s enough good-will that you'll probably get there. So you need some kind of small time period, to launch soon, and I think it's probably really key.

Erlend: Very good. Well, just one more question then. What app out there, like a closed app, would you really like to see an open source alternative for?

James: Good question. There's like a few of them. The community one is I want personally. I’m not convinced you can build like a very big company around the thing we’ve already talked about but that's something I have repeatedly wanted.

I really wanted like something that would like Google docs, but would let you work with Mark down. And would be open source and really easy to set up and use. It kind of bugs me that we have some stuff in Google docs still. I wish I could put this into our issues or into markdown files in a repo. But I like the collaboration. I sometimes like the inline collaborations. So some cool way of doing that.

My advice would be look at the SAAS stuff that you're using as a developer and think through like, could I think of a way to improve this functionality wise and would open source make it nicer.

Erlend: Yeah, exactly. All right. Well, thank you so much, James. This has been great. And I wish you the best of luck onwards with the company. I'm sure you have quite the journey, still ahead of you. It's going to be very interesting.

James: Cool. Take it easy.