Beyang sits down with John Kodumal, CTO and co-founder of LaunchDarkly. LaunchDarkly is a SaaS feature management platform for developers that allows them to iterate and get code into production quickly and safely by separating feature rollout and code deployment.

John begins by talking about his first experiences with computers and programming in the 80s, including teaching himself to use a Dvorak keyboard in the first grade, experimenting with Bulletin Board Systems in elementary school, and programming his TI-92 in BASIC to let him use Reverse Polish Notation (RPN). John shares how he pursued his interest in programming languages throughout higher education and shares stories and lessons from his time at Coverity and Atlassian. He talks about how the lessons and experiences from his prior jobs ultimately led him to found LaunchDarkly in 2014 with his former college lab partner, Edith Harbaugh.

John dives into how he and Edith settled on the problem area of feature toggles and feature flags, and then talks about the engineering challenges LaunchDarkly has encountered. John concludes by sharing how he has witnessed LaunchDarkly impact the developer experience and the ongoing, transformational benefits of utilizing their feature management platform for their customers.

Subscribe: YouTube Apple Spotify Google RSS

---

Show Notes

• John tells the story of his introduction to computers, beginning with BBSes and CompuServe in elementary school, and his first forays into programming with BASIC and Turbo Pascal in the early 80s (00:24-7:55)

• John talks about his interest in programming languages that fueled his pursuits in higher education (7:55-13:32)

• Beyang and John discuss the current wave of low code tools and the direction it’s moving (13:32-16:40)

• John talks about his work experience prior to starting LaunchDarkly, including a stint at Coverity, and then at Atlassian which he credits as being where he learned to build a company and scale teams (16:40-20:54)

• Beyang and John talk about the future of static analysis (20:54-24:57)

• John delves into his time at Atlassian and explains what it was like witnessing the company’s growth from a 150 person operation to IPO, and emphasizes Atlassian’s high caliber culture of collaboration that continues to influence his leadership style at LaunchDarkly (24:57-27:32)

• John talks about some of Atlassian’s positioning relative to other developer-focused companies like Fog Creek and GitHub, and Beyang and John imagine what could be in store for workflow/change management (27:32-35:57)

• John shares what inspired him to leave Atlassian and found LaunchDarkly with Edith Harbaugh, then talks about the challenges of starting a company in the developer tools space in the early 2010s (35:57-41:02)

• In answering the question “How did you get into feature toggles and feature flags” John talks about the internal flagging tool he helped to build at Atlassian, and how his experience with the pain points on that internal platform influenced his idea to start LaunchDarkly, and then relates a story of hacking Optimizely to temporarily patch a bug in the Atlassian purchasing system (41:02-44:21)

• John talks about LaunchDarkly’s first customers and the realization that most companies were already feature flagging, just doing so badly, and Beyang and John discuss targeting enterprises early in the life of a dev tools start-up versus mainly SMB (44:21-49:04)

• John discusses the engineering challenges that LaunchDarkly has encountered in terms of scale and reliability, and solutions such as eliminating remote calls, getting updates pushed over persistent HTTPS connections, and optimizing individual user context (49:04-56:49)

• Beyang and John talk about impact of using feature flags on developer experience (56:49-1:02:15)

Transcript

Beyang: Welcome back to another iteration of the Sourcegraph Podcast. Today I’m here with John Kodumal, CTO and co-founder of LaunchDarkly, the popular platform for managing feature flags and feature toggles. John, welcome to the show.

John: Thanks. Really excited to be here. Thanks for having me.

Beyang: Awesome. Thanks for taking the time. So, to kind of kick things off, what was your initial entry point into the world of computers? When did you get into programming?

John: Yeah, I started out with computers really young. So, I’m—you know, my age is going to come out at some point, and so at the time of this recording, I’m 43 years old. So, I got into computers at an early age. And at an early age for me, we’re talking about, like, the early-80s. So, we’re talking, like, WarGames era, just past a coupler modem into, you know—but still in the, like, modem and BBS era for a lot of people. And my first computer was, like, an original IBM PC—this I’m really dating myself—like, to 5 1/4 disk drives, 256k of memory, like, CGA graphics. And the deal with—my dad bought it from my brother, who’s eight years older than me, and bought it for him for, like, typing and for school and stuff like this. And my brother, like, had no interest or desire to use it. And so, I kind of just, like—I was, like, five—six years old or seven years old, so, like, really young. I kind of just shoved him aside and I was like, “Let me go at this.” And so, like, my dad had bought him a modem. It was like a 300 baud modem, and I was the one that, like, set it all up, like, got—you know, basically set the thing up and started using it. And then I quickly got into, like, the online world, which back in the day, as I mentioned, was like, BBSes and, like, CompuServe was, like, kind of the first service that I was on.

Beyang: What is a BBS and what was CompuServe, for, like, younger listeners who—

John: Oh, yeah. This is great stuff.

Beyang: —don’t know what that is.

John: So, BBS is for ‘Bulletin Board System.’ And basically what it was, was it was a lot of, like, hobbyists. These weren’t companies; they were largely just, like, other individuals who were computer enthusiasts. And they had, like, a handful of modems that connected to a hosting service, their own personal computer that was set up as a hosting service. And literally, like, the number of people that could connect your service was proportionate—was exactly the number of, like, external phone lines that you had.

So, like, we’re talking, like, you paid the phone company for, like, six phone lines, and, like, six people was, like, the maximum number of concurrent users on your board. And each board had, like, a mix of, like, files that you could download, which could be, like, images or, like, honestly, like, a lot of pirated content, like, games and open stuff. And then message boards were, like, people formed some of the earliest online communities.

Beyang: That’s awesome. So, it’s kind of like a combination, like, file server slash chat system?

John: Yeah, yeah. And then there started being, like, these online collaborative games called doors. It was a really cool experience. It was a really early time, and the people that were into it tended to be the people that, like, just had a lot of common interests, you know, in computers or other things, like lockpicking; the MIT Guide to Lock Picking, like that was like, one of the most popular files. And, you’d come into school with, like, dot-matrix printouts of your MIT Guide to Lock Picking, or, like, Anarchist Cookbook—

Beyang: That’s amazing.

John: —or other content like that.

Beyang: Man, early internet. That’s really cool. So, did that get you into programming at all? Or was it—were you strictly, like, kind of an end-user of the internet and computers in those days?

John: Yeah, so this is all—man, this is all really dating me, but, like, my first exposure to programming was BASIC. And my first actual exposure to it was they used to—you could go to the bookstore, and now, like, bookstores are barely a thing, but, like, you’d go to a bookstore and you could buy a printed out—like, basically printed out BASIC programs. Like, and basically you would, like, bring that book home and you would just type in the entire program.

Beyang: [laugh]. Long before GitHub. You would literally just, like, buy a book and type in the program. That’s amazing.

John: Yeah, the workflow sucked but it was all you had, right? So, you’d go to a bookstore, you’d buy, like, a printout of, like, these BASIC problems, and most of them, mostly, they were games. And you’d type them all in, and debugging was like you with, like, to print out and the, you know, what you coded in and, like, you’re just looking at them side by side and going, like, where did I screw up the logic here? And yeah, that was my first exposure to programming. But then from there, like, as I grew older, as I got into, like, middle school and beyond, like, I started getting into real programming, like, I think Turbo Pascal was probably the first programming language, like, Turbo Pascal for Windows, so it’s like, doing Windows programming back in the day. And then eventually, like, in college, that was like when I first took an actual programming class, but I’d done a ton on my own.

Beyang: That’s awesome. Do you remember, like, it was there anything in particular that sticks out in your mind that you built-in Turbo Pascal for Windows during your middle school, high school years?

John: Not in Turbo Pascal but for—okay, so I had—in high school I had a TI-92 you know that TI calculator? Like, the—

Beyang: Graphing calculator? Yeah.

John: Yeah, the graphing calculators.

Beyang: The 92 sounds pretty intense. That’s—was that was the ones with the—

John: That was the one with the full-on Qwerty keyboard. Like, you could do—

Beyang: [laugh]. It’s awesome.

John: Yeah, it was great. Because it, like, it did all of your calculus for you.

Beyang: I think those were banned. Those were contraband of my school. [laugh]. Ridiculous.

John: And so, I had that, the TI-92. I was like the kid with the TI-92 while everybody had a TI-82 or whatever. And I built a Reverse Polish Notation shell for it.

Beyang: You’re kidding?

John: Yeah.

Beyang: That’s so cool.

John: There was always, like, the TI people versus the, like, I forget what the other—there was another competing calculator. It wasn’t from—

Beyang: Or something like that?

John: Somebody. But, like, their whole thing was like theirs was an RPN and TIs were not in RPN. I was like, “RPN is great.”

Beyang: What is RPN?

John: Reverse Polish Notation.

Beyang: Oh, okay. Okay, got it. Yeah. So, it’s the—

John: Yeah, so it’s like you enter 5, you enter 4, and then you hit plus, and then it op—you know, it’s like.

Beyang: Yep, yep, yep.

John: And so, I was like, “Well, I want the best of both worlds,” and so I built a new, like, interface for the TI-92 that put everything into, like, RPN mode. So, like, basically, it was like a stack calculator that I built for the TI-92

Beyang: Cool. So, you prefer the Reverse Polish Notation when it came to, like, arithmetic [crosstalk 00:06:41]?

John: Yeah, I have always been an odd person when it comes to, like, my choices—

Beyang: Because you’re a robot. I think that you’re a robot. [laugh].

John: I’m always trying to find that thing that’s, like, a little alt or, like, a little bit of, like, what people are not doing, like we talked about this. But, like, when I was in first grade with that IBM PC, I taught myself Dvorak. So, when I taught myself typing, I didn’t learn—I’ve never learned Qwerty so, like, I literally [crosstalk 00:07:06]—

Beyang: That’s incredible. How did you know about Dvorak in first grade? Oh, that’s incredible.

John: Yeah. I was like, well, this is highly inefficient, right because, like, the whole backstory—which I think is not really true—

Beyang: Yeah.

John: —the whole backstory—

Beyang: I heard it’s apocryphal, yeah.

John: Yeah. This is designed for—the Qwerty layout was designed for manual keyboards to avoid jamming. And so, I was like, yeah, like, Dvorak, that makes more sense. So, I learned Dvorak and I never learned Qwerty.

Beyang: That’s incredible. Do you—what is your typing speed? Do you know—

John: I have no idea. I think—because it’s not actually better, right? Because it turns out you’re optimizing the wrong function. It’s not the amount of travel your fingers have, it’s like, alternation is more important because alternating is faster than moving small muscles in one hand.

Beyang: Yep, yep. Okay, cool. So, you got started very young. You’re very self-taught. What was it, like, going into college and taking your first quote-unquote, like, “Real” programming class there? What was that transition like?

John: It was interesting because it brought a formality to something that had formerly been a hobby. And whenever you do that, it’s sort of like, am I going to lose the passion of this? Is it going to go from something that I have, like, a curious—like, an intellectual curiosity about into, like, a chore? And, to my surprise, and happiness, it absolutely didn’t do that. I was so excited. In fact, when I entered undergrad, I went to Harvey Mudd, which is an engineering-focused school in Southern California. And I actually went in as an engineering major, and I thought, I’ll keep computers as my hobby because I’m so excited about them, I don’t want it to be that, like, the thing that I do for work. And then I, like, as I got more into the curriculum, I was sort of like, I had to make a choice between taking more programming classes and taking more engineering and math courses, and I was sort of like, “Well, at the end of the day, if I get through this program and I get my degree, and there’s, like, a whole bunch of stuff that I could never learn because, like, I just didn’t have access to those classes, I would feel really disappointed.” Like, I had just—that, like, curiosity and drive, like, I really, like, it really got more and more excited about what I was learning. Like, when I took theory of computation and learned about, like, state machines, and, like, finite state machines, and, like, automata, and, like, Turing machines, it just unlocked this, like, level of curiosity around computer science that was just even deeper than what I had before. And at that point, I was like, I really have to major in this because, like, I can’t imagine… I can’t imagine ever exhausting the, like, body of knowledge and feeling like I wasn’t excited about this anymore. And so, that went to me completing my undergrad in computer science and then going straight from undergrad into grad school in computer science.

Beyang: That’s awesome. That’s awesome. What was your—was there, like, a domain? So, when you went to grad school—you did a PhD there—what was your, kind of, specialization? Was there a particular part of computer science that, you know, kind of drew you into that?

John: Yeah. So, as an undergrad, the class that I enjoyed the most, absolutely, thoroughly loved the two classes that I loved were formal logic and programming languages. And so, the languages class was really cool. We—in that class at Harvey Mudd at the time, you basically built an interpreter in SML. So, you programmed in SML, so you got to learn functional programming, which has been, like, it’s something that I’ve always been really excited about, and you got to build in—

Beyang: Is it a variant of ML? SML? Or—

John: Yeah, ML—standard ML is just one variant of—

Beyang: Oh st—okay, got it. Got it.

John: Standard M—SML, New Jersey, whatever. And then later on, I learned OCaml, which is, like, another variant of ML.

Beyang: That’s a very math-y language.

John: Yeah, they’re great. So, I fell in love with functional programming. I fell in love with, like, compilers and interpreters and the process of creating languages. And so, then when I went to grad school, that, coupled with, like, “Hey, I’m really interested in formal logic,” I started—I basically went—I started to get really excited about programming languages. I actually started out my grad school degree in human-computer interaction, but the way that I bridged that was I was working on visual programming languages. So, I was thinking about programming languages, like, from a human-computer interaction or interaction design perspective. And I was thinking about ways to bring visual programming into the world. And then eventually, even in that, I was like, I’m actually really a lot more interested in the formal process of—the formality of programming languages. And so, then I just shifted into programming languages and did my specialization in programming languages.

Beyang: Yeah, that’s awesome. That’s awesome. Are you familiar with any of the, like—I know, there was like one project out of MIT that was kind of like teaching kids how to program using a visual grammar of sorts. I’m blanking on the name, but, like, projects like that.

John: Yeah, there’s a handful of those. I wasn’t really directly involved in it. There’s, like, there’s a bunch of scheme variants where they sort of like teach you scheme, by, like, exposing, I think it’s like Dr Scheme. I think [crosstalk 00:12:21], Matthias Felleisen’s work, maybe. I’m not a hundred percent sure I have that, right. But I was peripherally familiar with that work, and it’s always been something that’s interesting to me. That was actually the first set of projects that I did around visual programming was around expression editors and, like, trying to create expression editors that would work for non-technology folks. So, I started, like, doing user studies where I would show, like, these recursive expression builders to non-programmers, just, like, lay people, people that were doing whatever, like, a piano teacher, and just seeing if I could, like, get them to understand the concepts of recursion and things like that. Turns out, that was really hard on a lot of different levels.

Beyang: Yeah, I feel like recursion is one of those, like, intellectual leaps that you take when you’re first learning into programming it kind of, at least for me, it was like one of those things where it just, like, clicks, at some point, it’s like, it’s very difficult to grasp that concept until you finally get it. And… yeah, it’s tricky. What do you think of, you know, I feel like in the past year or so, maybe two years, there’s just been this, like, huge wave of low-code and no-code tools. You know, it’s become a huge trend now. What do you make of that? Is the time for, like, visual programming, and these kind of like, light syntactical, you know, feels like programming, but maybe, you know, is not what we traditionally think of as programming, you know, like, a terminal or something like that, is that something that is still kind of like keeps your interest? Have you used any of them? What do you think of them?

John: Yeah, we’re actually, we’re customers of Retool, which is one of the more popular low-code platforms. I think what’s interesting to me as a languages practitioner, like, someone who’s really interested in programming languages, is all of the, like, workflow around change management in programming languages is really good at this point, like, very, very good. Like, Git. Gitflow, like, the idea of, like, collaborating, pull requests, merging changes in, or reverting changes, rolling them back, that has gotten really mature for traditional programming languages, and I think that’s probably one of the directions that those domains need to explore. It’s like, how can you regain a lot of that power, that workflow in a non-text-based code world? Because I think at the end of the day, a lot of that tooling is based fundamentally on code being stored as text, right?

Beyang: Yeah.

John: And probably most of that comes from Git operating on text files. And so, I think it’d be fascinating to, sort of like, figure out how to support those types of workflows, like pull requests, rollbacks, change management, audit logging, in a low-code world.

Beyang: Yeah, that’s interesting. I feel like there’s this interesting, maybe, like, intersection between quote-unquote, “Low-code” and developer tools, where, like you said, you know, a lot of developers—I feel like a lot of times what you’re essentially doing in a low-code or no-code tool is coding in a way, right? You’re writing logic and connecting that to components. And then, you know, members, the development team will sometimes get involved in that as well, especially when there’s, like, a more complex piece of logic that needs to be added. But then it’s like, certain things are much easier, much nicer, but then you miss a lot of the developer experience, like you said, you know, change management and other sorts of things that you have from the development side. So, I wonder if you know, those lines will start to blur and the next couple of years as, you know, this, kind of like, cross-pollination happens.

John: Yeah, I think that’s probably the direction it has to go, right? Because you need an escape hatch into, like, a full-blown Turing-complete language at times, right?

Beyang: Yeah.

John: And then you also—like, the reason change management is valuable is it’s valuable to the business. It’s not just about developers, making them more productive. Like, it’s incredibly important to be able to roll back change, to be able to track change. And if you can’t do those things, you’re kind of—I don’t know, you’re kind of in trouble. You’ve lost a lot.

Beyang: Yeah. Okay, cool. So, you graduated with a PhD in programming languages. And what was the journey like from that to eventually starting LaunchDarkly? Because it feels like feature toggles, it’s a bit far afield, from you know, just, like, the very specific domain of you know, static analysis and programming languages. What was that journey like? You know, what brought you in the direction of feature management and feature toggling?

John: Yeah, the first step of that was deciding that I was done with academia. Like, I didn’t want to become a professor. So, I got the PhD and I immediately started looking for opportunities on the commercial side, to do what I was doing, but to try to actually work in a company that was selling that as product. And there were very few companies doing that at the time. This was around 2007 or so, 2006. And so, I worked for—I joined a company called Coverity which was amazing. They were some researchers out of Stanford, out of the programming languages groups at Stanford, Dawson Engler, Andy Chou, Seth Hallam, and a bunch of other folks, incredibly talented researchers, that were commercializing this technology that was around finding defects in software automatically using a lot of the mathematical rigor and the techniques that we were developing in the programming languages research community, things like type systems. So, you know, most people are familiar with type systems, if they’re programmers, you know, they’re using, like, Java, and there’s a type system that helps you eliminate certain classes of invalid programs. And so, we were kind of taking that another level and saying, like, “Well, what if you could annotate programs and use those annotations to assert things about the state of the program, and then use techniques to validate or invalidate the—or prove or disprove the existence of certain kinds of bugs?” So, for example, like, buffer overflows in C or null pointer exceptions, can you statically prove—you know, before a program is running, can you statically prove that a null pointer exception won’t happen? And most of the, like, static analysis out in the world is really just—it’s really not sta—I wouldn’t call it static analysis. It’s just, like, sort of like, really s—

Beyang: Super simple.

John: —really super simple stuff, right? Like, doesn’t even really understand the workflow, let alone, like, what a function call is and, you know, [crosstalk 00:19:03] procedural analysis. And the stuff we were doing at Coverity was really innovative stuff. I was pulling stuff out of my thesis and commercializing it, which was an amazing and very rare experience. I’m extremely grateful for that. So, I worked there for three years, built a lot of really cool stuff. We did a lot of really, really novel stuff. Some of the technology that Coverity built around, like, understanding and introspecting on builds, I think is, like, state of the art even today. I did some stuff on, like, detecting race conditions dynamically in Java programs. So, like, you would run a Java program and the stuff we built would instrument that Java program and just spit out races that were occurring. That was really cool stuff. Incredibly slow, though. It, like, slowed programs down by, like, a factor of 10 or 20 or something like that. And it, like, doubled or quintupled the memory footprint or something like this. So, very academic stuff, but we were still finding applications for it. From there, I got really interested in understanding how to make developers’ lives better, you know, not through technology per se, but through collaboration, making them work more efficiently. And so, I joined Atlassian after that, and I spent six years at Atlassian. And Atlassian was where I learned a ton about how to build a company, how to run teams, how to scale teams. And more importantly, like, what it really took to, like, make teams more productive. I think one of the things that I was really blessed with throughout my career is I got to—you know, like, Coverity and Atlassian, I got to talk to a lot of customers, I got to talk to a lot of engineering teams, and I could see how they were building software and I could diagnose patterns, see what was working and what wasn’t working. Those were really formative experiences in my career.

Beyang: Yeah, that’s awesome. You know, Coverity, you know, from what I know of the company, it seems, like, such a cool technology. And it feels like one of those companies that maybe there’s, like, a—we’re overdue for, like, a new wave of that. Because like you said, I feel like what are we talking about static analysis in the popular imagination, you know, like, JavaScript or whatever, a lot of the rules are still fairly, like, shallow whereas Coverity was doing, like, deep, like, multi-layer analysis and surfacing these, like, bugs by, you know, analyzing the Control Flow Graph and got really deep into these, like, Java and C++ programs. Do you feel like that sort of thing will ever, like, make a comeback in the, you know, web application world or, like, in the world of more web-based or, like, modern programming languages?

John: You know, I think perhaps. I think that there are some critical issues that need to be resolved in that domain. First, from, like, a more workflow perspective, most of those analyses are not incremental in nature and they’re incredibly expensive. Some of the stuff we were doing at Coverity like analyzing the Linux codebase would take, I don’t know, I can’t remember, like, 36 hours—

Beyang: Wow.

John: —on compute at the time, which yeah, computers have gotten faster, but not that much faster. And so, in a modern engineering organization where you have hundreds of engineers working, you know, in a DVCS workflow where you’ve got branches and everybody’s operating on independent branches, and if you have to do a 36-hour analysis for each change from scratch, that’s not really going to fly. What you really need is to be able to store analysis results incrementally and then apply deltas and have that be cheap, to do true [crosstalk 00:22:43] analysis. So, I think, from a workflow perspective, that technical challenge has to be solved. I also think that one of the fundamental problems with static analysis is explaining results to end-users in a way that makes sense. The more sophisticated type systems you have, the more difficult it is to explain to an end-user how you got that result and give them the ability to take action, especially when those type systems or those analyses are imperfect and can have false positives. That was a constant challenge with the technology, is sort of like, all right, you’re explaining this chain of reasoning that involves, like, 15 function calls. And the end-user, like, they’re diagnosing this, they’re trying to follow the line of reasoning, and they’re like, “Wait a minute. Can this actual path even occur? Like, is it even feasible given the constraints on the real data coming into the system?” And you can see this, even in modern programming languages where sophisticated type systems, hard to explain to users, inference-based systems, hard to explain to users.

Beyang: Yep, yep, yep.

John: Explaining, like, unification algorithms to end-users seems really, really challenging.

Beyang: Yeah, I mean, even, like, for—we use TypeScript, and even, like, a fairly straightforward type error—like, because TypeScript types are composable, you can, like, nest them. And so, like, just the type definitions get long to the point of, like, unreadability. And then you as a human just spend, like, you know, many minutes just, like, trying to parse all the brackets and syntax around the type to figure out what’s going on. So yeah, there’s something to be said around, like, making things explainable and I guess, like, you know, crossing the computer-human chasm. Which I guess, you know, maybe gets back to some of the HCI and PL intersection—

John: Yeah.

Beyang: That you were looking into.

John: Absolutely. And there’s actually like—that’s a whole active research area in the PLs community is, like, explaining errors to people more easily. Many of the types systems out there, like, in advanced PLs research, they’re quite sophisticated. And sometimes, you know, they end up being impractical because they’re incomprehensible. [laugh].

Beyang: Yeah. [laugh]. Unfortunate. Cool. So, when you were at Atlassian, you were there for, like, five over six years, right?

John: Yeah, just about that.

Beyang: So, company grew a good deal. I think you joined—how big was it? Was it, like, around 100?

John: I think it was around 150.

Beyang: One-fifty?

John: And I think when I left, it was just prior to IPO, it was around—I think it was several thousand, so twenty-five—

Beyang: Okay, wow. So that’s, like, a vast amount of growth. What was it, like, witnessing the kind of growth of Atlassian into this, like, ubiquitous household name?

John: You know, it took so long for it to become a household name that it was so interesting for us because, you know, when I joined the company, it was really unknown. Like, nobody had ever heard of Atlassian, partly because they were Australian, and partly because they kind of deliberately, like, went under the radar in many significant ways. They were bootstrapped for a long time. They didn’t give out equity to employees for a long time. So, you know, I joined in—I think I joined in 2008 and they didn’t give equity until 2010. So, I’m not quite sure how they were attracting the caliber of talent they were attracting without the equity piece, but they rectified that, fortunately, for all of us early Atlassians. You know, that company, I have nothing but respect for what they built. It was so incredible to see how they were able to preserve the culture of collaboration from 150 people to the size that they’ve grown to now. One of the things that I point to is, like, the company, their products, they dogfood their products religiously. And their products were all focused on collaboration. And that meant that collaboration was this incredible superpower within the company. So, it’s sort of like, by dogfooding their products and by practicing what they were selling—you know, preaching—they were able to multiply their own efficiency and create just really great working environments where even as the teams grew and, you know, you were dealing with a lot of siloed organizations, you were still able to work with each other. And the culture they built was incredible. There are things that I take from that culture and try to replicate within LaunchDarkly all the time.

Beyang: Yeah, that’s awesome. I feel like everyone I’ve ever interacted with at Atlassian has just been, like, a stand-up individual. And they really, really do take their values very seriously. And, you know, their core values is just, like, having a really strong, tight-knit culture of collaboration. That’s something I’ve always appreciated about them. I’m curious, did you have kind of an inside view at all with the… maybe you’d call it, like, the somewhat competitive boundary with GitHub? Because, you know, these days, I feel like, you know, Atlassian, the flagship product is Jira and Jira is one of those products, where it’s been—it’s almost, like, because it’s so successful, you hear a lot of complaints about it, you know? And among developers, you know, it often gets compared to GitHub issues, and you know, Atlassian also has, like, Bitbucket and Stash, which kind of competes with the GitHub main product. Was that, like, a thing that loomed large in the mind of Atlassian when, kind of, GitHub came up during those years, or was the company just, like, focused on, you know, what it was doing, and viewed that stuff is a bit of a distraction?

John: It was a little of both, honestly. There were times in Atlassian’s lifecycle where there was like a primary competitor that the company was focused on. Like, if you talked about—if competition came up—and it didn’t often, honestly—but when competition did come up, in the early days, it was Fog Creek with FogBugz, and then [unintelligible 00:28:42] later on, that was viewed as the primary competitor. There was a famous incident—at the time, it was a big deal to us; I’m sure most of the tech community has never heard of it, but, like, Joel Spolsky, who was the CEO of Fog Creek, wrote a blog post where he basically was talking about, like, their product in comparison to their chief competitors—and he was talking about Atlassian; he didn’t name them—

Beyang: Yeah. Yeah.

John: And he said something like, “The cart is—the wheels are falling off the cart over there.” I think that was the phrase he used.

Beyang: Interesting.

John: It was—

Beyang: Shots fired. [laugh].

John: Yeah. He was trying to say that, like, from a product execution perspective, Atlassian was in a bad situation. And that wasn’t true. I’m not sure why he thought it was. But he wrote that and I think there was like an exchange where, like, we sent Joel, like, a giant stuffed donkey, like, a donkey cart thing. I don’t know. We had a donkey in the office, like, a stuffed donkey in our office with an Atlassian t-shirt on it for a while. So, an early competitor was Fog Creek, and then for various reasons, you know, Fog Creek didn’t take off the way—FogBugz didn’t take off the way that Jira took off. Won’t get into that, but later on around—I think it was, I want to say it was 2012-ish—time is, like, you know, I’ve been around a while [laugh]—where we really felt—we at Atlassian really felt that GitHub was the primary competitor. And this was around GitHub viewing itself as, or being desirous of becoming a collaboration platform for anyone, even outside of software development.

Beyang: Right. Yeah.

John: And if you see the direction Atlassian has gone around general-purpose collaboration, then you can see why that happened. But for various reasons, that really never took off as a competitive threat to Atlassian.

Beyang: Yeah. I remember for a while GitHub was really trying to position itself as, like, not just for developers. There’s, like, a period of maybe one or two years maybe around, like… I think this was, like, fairly early in Sourcegraph, too, so, like, the 2014 or something like that, where you saw a lot of, like, messaging around, like, “Hey, you know, we’re going to get designers involved in this, and, like, you know, people from marketing and sales.” Like, all should learn kind of the GitHub workflow. But I guess it didn’t really pan out. And it seems, like, Atlassian has always come from the side of things, like, let’s build general, like, team collaboration tool, project management, and GitHub has always stayed anchored to more of a developer audience. Would you say that’s, like, more or less true or is that kind of an oversimplification?

John: No, I think that is very true. I mean, I think that was very deliberately GitHub mission for w—I’ve never worked at GitHub, so I’m certain some listeners might dispute my take on it because I have a limited perspective, but it’s interesting because I also—I was recently reviewing GitLabs’ mission vision, and they have the same thing stated in their mission and vision that they want to be—I think their mission is, “We’re building a platform where everyone can contribute, and when everyone contributes, you create better outcomes.” And they even talk about Hollywood directors writing scripts in GitLab. That’s in the mission. But I have a really strong suspicion that they’re not actually executing towards that.

Beyang: [laugh].

John: You know?

Beyang: Yeah. They seem pretty developer-focused, right there—

John: Yeah—

Beyang: —from what I can tell.

John: —I think that they’ve really, really honed in on this, like, one platform for the—one collaboration platform for the software development lifecycle, and they’re really building towards that. And maybe it’s an artifact that they haven’t updated the mission. But when I read that, I was remembering back to the GitHub days and how that played out, you know? My understanding is, like, you know, in the earlier days of GitHub, the legal team has had to write legal documents and submit pull requests.

Beyang: I’m sure they loved that.

John: You know, and I think there’s a kernel of something really interesting there, which is, like, that whole workflow—you know, we talked about change management earlier.

Beyang: Yeah. Yeah.

John: I think that there is something that will eventually transcend engineering in that workflow. And we’ve got to figure out ways for other people to benefit from it. Like, I would love HR processes to be, like, you know, “I could time-travel back and look at what an HR process looked like six years ago,” or something like that, or, you know?

Beyang: Yeah.

John: But that has never transcended developers. There’s something about change management that you wish existed—that engineering rigor—that existed outside, and it hasn’t happened yet.

Beyang: Yeah, just, it’s something beautiful about, like, I can literally go back in time and see every change that anyone ever made to this document, or this, you know, knowledge base, and I can see precisely who made the change and when and for whatever reason, it’s just—maybe it’s that, like, you know, Git is kind of this open-source thing. It’s viewed as, like, the standard protocol, whereas the attempts that I’ve seen outside of the world of developers have largely been, you know, proprietary, locked into a particular product. You know, like, Google Docs has a history view, but it’s specific to Google Docs and it in some sense, it feels like an afterthought, not, like, a first-class feature. And of course, you can never take it to, you know, some other document editor or system that you’re working in.

John: Yeah, I think there’s a ton to unpack there, right? So, I think about this in a couple different ways, like, one, like, there’s a whole configuration-as-code movement and, like, I really think that that whole space is not really about code. I mean, it’s all about that change management, and it just so happens that we’re really good at that change management for things that are expressed as code, specifically as text files. And that goes to the point that you were suggesting, which is that, like, all the other ways of doing this, since they’re not operating on text, they feel very proprietary. It’s really interesting. I wonder whether there’s going to be something that can unify those things because, like, doing everything in text is very limiting in some ways you have no understanding of the semantic structure of anything that you’re working with. Like, conflict resolution, for example, is reduced to the lowest common denominator. But then we don’t really have tools that can work above the level of text, like Git, for example.

Beyang: Yeah. It’s like someone needs to wake up Linus Torvalds from his slumber and get him to write—or, you know, maybe the next Linus, you know, is out there.

John: Yeah. [crosstalk 00:35:30] like, you know, what, this is all about structured trees and all about [ASTs 00:35:36], and we’re going to store everything is ASTs. [crosstalk 00:35:38] ASTs for, like, every [DSL 00:35:41] out there and explore them in version control, and have version control works on trees. Maybe that’s the direction.

Beyang: [laugh]. My mind reels at the thought of that. That’d be quite the undertaking. Okay, cool. So, you were at Atlassian. You saw the company grow from 150 to thousands all the way through IPO. What was, kind of, the impetus for you to leave Atlassian and start this company, LaunchDarkly.

John: Yeah. There’s a lot of reasons why I left. I—and none of them were because I didn’t think Atlassian was going to succeed or that it was a bad place to work or anything. And basically boiled down to, for me, like, feeling like that, in the role that I was in, there was a lot I was leaving for myself on the table in terms of, like, my ability to think strategically, to be more of an entrepreneur. I felt limited as an engineering leader at Atlassian, and I knew I could do more. And so, you know, I left at a very odd time in my life, and since then, like, I had a six-month-old daughter, company was about—

Beyang: Wow.

John: —IPO. Like, [crosstalk 00:36:52] a lot of different levels didn’t make a lot of rational sense. But again, you know, maybe the thread is, like, I don’t necessarily do the most rational things, like learning Dvorak which maybe is not the most rational decision. But I felt like there was an opportunity. I met my co-f—and I didn’t meet, but I had been working with my co-founder, Edith, for a while thinking about, like, building a business together. She’s the one that I met in college back at Harvey Mudd. And, you know, we ended up talking a fair bit and thinking about different ideas. And, you know, one of the things that we realized was like, we really had to find something in the intersection of our interest areas, something that she was passionate about, something that I was passionate about. And so, developer tools ended up being, you know, the natural space for both of us to focus our energy on. And so, that was sort of the start of it. I knew I was going to leave Atlassian. I knew Edith and I were going to start a company together, and it felt developer tools was the space we were going to do it in.

Beyang: Awesome. And this was—when did you get started is around, like, 2014?

John: 2014. Yeah.

Beyang: Okay. And in those days, developer—like, because Developer Tools is considered, like, a quote-unquote, “Hot” investment space now, but in those days, it was much less so. Because I remember when Sourcegraph got started around the same time, and we could not find, for the life of us, like, an investor to, like, sit down and listen to—as soon as you said the word, you know, ‘developer tool,’ they were like, “Oop, nope. No money in that.” What was it like starting a developer tool company back in 2014?

John: Yeah. What year did Sourcegraph start?

Beyang: We were actually mid-2013.

John: Mid-2013?

Beyang: So, we actually predate you by about a year or so.

John: Yeah, I remember this because I thought about applying to you guys. I don’t know if [crosstalk 00:38:44].

Beyang: That’s awesome.

John: Yeah, but—

Beyang: Well, did—I don’t remember, like, chatting with you back then. Did you just like—

John: No, I was really, like, stealthily—like, I was stalking you guys because I was like, I was still thinking about static analysis, and I was like, well, who’s doing anything interesting in this space? Like, because, you know, we had a conversation of, like, maybe there’s going to be a rebirth of this.

Beyang: Yeah. Yeah.

John: And so, I thought, maybe there is, maybe there’s somebody doing it and something interesting. And so, I stumbled upon you folks, and I thought I followed you for a little while and was like, you know, something might come out of Sourcegraph. And so, there’s probably a parallel universe where—

Beyang: [laugh]. What could have been? [laugh]. You’d have been amazing to work with. I mean, obviously, you know, LaunchDarkly is pretty cool, too, but [laugh] it would have been awesome to geek out about static analysis. And—

John: Yeah, for sure.

Beyang: —programming languages.

John: For sure. Anyway, you know, yeah, you’re right. It was a very different world in 2014, 2015, for companies in our space. I don’t think that there were very many successes that you would consider developer tools at that point. Like, GitHub had an exited yet, right?

Beyang: Yeah, yeah, GitHub was still seen as, like, a very, kind of like, high variance. Like, who knows what will happen?

John: Yeah. You had you’re looking at, like, I don’t know, who are the success stories? Maybe New Relic and companies like that that had just gotten to the IPO stage. If you consider them developer tools. And so yeah, it was really hard to find investors, it was really hard to tell the story of what LaunchDarkly was and not get swallowed into, like, isn’t this just an experimentation tool? One of the things that really helped us, we joined Heavybit, which for those not aware, Heavybit is a group of folks that invest primarily in developer tools companies, and they’ve been doing this for a long time. And they were really, really helpful, not just as early money into LaunchDarkly, but also in helping us shape go-to-market and really be foundational partners as we grew the company. But you know, there weren’t many Heavybits around back then; there weren’t many companies that really understood the space and had conviction in it.

Beyang: Yeah. How did you get on the area of, like, feature toggles and feature flags? Was that something that you, kind of, knew was a need, coming out of Atlassian, or they take a bit of, like, user or customer discovery to get—to land on that?

John: Yeah, it did come out of experiences at Atlassian. So, a couple of them in particular. The first one was that we’d built an internal feature flagging tool at Atlassian, but it wasn’t used by very many teams. And my team—so my team was on the—my team was the Atlassian Marketplace team, so we built basically what ended up being something like the Apple App Store, but for Atlassian [crosstalk 00:41:41] more reasonable analogy. And we ended up wanting to do dark launches. So, at Atlassian, they were called ‘dark launches,’ which I realized later was not a widely used term. Which is funny because we named the company before doing that research.

Beyang: [laugh].

John: So, we wanted to do some dark launches on my team and we found the platform, the internal platform for doing this at Atlassian, it was really, really painful to use. And it suffered from all of the classic internal tool problems, right? When you build internal tools at a company, you don’t really apply the same rigor that you do with customer-facing products. Like, you take shortcuts, you don’t have PMs, you don’t have designers. Just, like, a bunch of engineers that hack something together to meet the needs of the day.

Beyang: Yeah.

John: It’s often not coupled with a massive, like, vision around how that investment is going to—you know, what role it’s going to eventually evolve into within the company. And that was the case with Atlassian’s internal flagging tool. So, it felt like there was an opportunity there. And then there was a particular experience that I’d had. At one point, we in the San Francisco office, the engineers realized that somebody had listed—there was some bug in the purchasing system—which was homegrown at Atlassian—and it listed Confluence for free. So, you could buy Confluence at any level—

Beyang: Oh wow.

John: —for free. It was just, like, listing the price at $0. And I think, like, 30 licenses had been bought that morning for free. And the website team, which was based in San Francisco, discovered this, and it was a back-office system problem. That team was in Sydney. We didn’t have an on-call rotation, so we couldn’t page them. Their business didn’t—hours didn’t start till 4 p.m. so we had to do something. And so, they took Optimizely, which was already installed on the marketing website and they rolled out an experiment to a hundred percent of the population that just removed Confluence from the cart. And that was the Band-Aid fix. And, you know, that was an inter—but I knew a lot of teams that were, like, hacking Optimizely in that way to, like, achieve outcomes like that. You know, you realize that there was an opportunity there because that’s not really what the tool was built for.

Beyang: Yeah. Yeah.

John: And really, what should have happened is the back-end change that led to Confluence being listed should have been feature flagged, and then somebody could have flipped a feature flag off and rolled back that change without having to redeploy. So, those two experiences together was, sort of like, a bit of the genesis of the idea.

Beyang: Okay, got it. What were kind of the early days of building the products like? Did you have, you know—who are your first customers, and how did the, I guess, like, vision of what you’re trying to do change over time?

John: The first customers were friends and family. We had—Edith in particular—has an incredibly strong network; it’s one of her superpowers. And she pitched LaunchDarkly to several of her peers that had started other companies. The first customer that had us live in production was a company called Chairish. They’re used furniture, like, high-end, like, collectible used furniture. So, they put us on their site. And I remember, like, flipping out because we went from, like, no traffic at all in the production system to, like, six requests per second. And it, like, blew my mind, like, I could see in real-time—

Beyang: That’s incredible.

John: —[crosstalk 00:45:16]. And so, that was nerve-racking. And we grew from there. You know, we started—I think the first enterprise deal we landed was a company called 10xauction.com, which renamed to 10X. And the way they found us was something that was going to be—we’re going to see as a repeated pattern in the future. One of their engineering directors had left, I think it was LinkedIn, and at LinkedIn, they’ve had a really sophisticated internal platform. He became an engineering director at 10X or auction.com. And he was like, “Where’s my platform that does this?” And they were like, “That doesn’t exist. We have to build our own.” And I remember in the first meeting we had with him, he told us, he was like, “So, I told my engineer, if I Google this and find something, I’m going to be really disappointed in you because I really don’t want to build this myself.” And so, we had done just enough to SEO, he found us. And you know, it was—

Beyang: That’s awesome.

John: —we landed an enterprise deal with four employees with the barest minimum of a platform.

Beyang: No kidding. Wow. Okay, so you all went straight to enterprise, then. You didn’t spend too much time on, like, smaller businesses. It was kind of like—

John: You know, we tried and we didn’t get a lot of initial traction. Like, now it’s a thriving part of our business, but the initial signals came from enterprises, actually. And that was something that we learned is that at the end of the day, tons of people are actually feature flagging. We thought it was sort of like we were going to be in the early adopter curve. Turned out no. No, no, no. Tons of people are feature flagging. They’re just, like, really, really, really badly with these awful, homegrown systems. So, we go into these, like, really legacy insurance companies and we’d be displacing this homegrown system that was like, you know, a couple of database tables and a script, that some engineer could run to do percentage rollouts. And then we’d show them what we have and it would massively change their thinking about what this capability could do for their company.

Beyang: Yeah, you know, it’s interesting, we had a very similar experience. We thought we’re going to go the, you know, quote, “Conventional route” of starting with SMB and moving our way slowly upmarket. But for us, it was like, first couple of customers were enterprise, too, because those were the ones who felt the need acutely enough that they were willing to be early adopters. And I almost feel like there’s—like, nowadays, there’s a lot of new dev tools companies springing up, and I feel like a lot of the founders, like, fixate on individual problems, or, like, targeting SMB, small businesses, early because they feel like that’s a safer route, or, like, those organizations are more inclined to be early adopters. But I actually think there’s all this evidence that suggests it’s actually flipped in dev tools land where, you know, organizations—maybe not, like, the super large, you know, tens of thousands of employees organizations, but a lot of, like, mid-market and enterprise companies actually do want to be early adopters of tooling like this because they just don’t want to build it themselves. They reached the point where the code and entering org is complex enough that they want a tool. They’re about to build it in-house, but they would much prefer to buy a best-in-class solution that’s battle-tested with a lot of other companies.

John: Yeah. And I think that’s spot on. And I think a lot of the hype around PLG kind of obscures the fact that, like, you know, I think to be a successful business, you have to have multiple motions. Like, it’s not just going to be $19 credit card charges all day. You know what I mean?

Beyang: Yeah.

John: Like, that’s pretty hard to do for a B2B company.

Beyang: Yep.

John: And so, we had both motions. You know, we’ve eventually grown to have both be very, very healthy motions, but reality is the enterprise motion, the sales touch motion was really, like, the first place where we were successful.

Beyang: Yeah. So, from an engineering perspective, I imagine that, you know, your feature flags and toggles are on the hot path for a lot of critical code, both in terms of volume and, you know, if something breaks, it probably takes down—you don’t want, like, an e-commerce site, your A/B is testing something—you don’t want, you know, a critical, you know, revenue-generating path to go down. What were some of the engineering challenges that you encountered and overcame along the way in terms of scale and reliability and things like that?

John: Yeah. I think what people don’t realize about feature flagging is they think it’s so simple, is that it’s essentially, like, a giant, distributed real-time database. Like, the contents of the database or, like, really, really small bits of JSON. Like, that’s kind of what we built. And we realized that from an early point on because we realized, like, okay, if we’re going to do this as a SaaS, that seems weird because this is critical infrastructure and you don’t want it to go down and you can’t afford to do a remote call. So, the first challenge is, like, how do you eliminate a remote call when somebody wants to request a feature flag? How do you solve that problem? And we realized, well, let’s just dump it in memory. Like, transmit over the wire and, like, put it in memory and then make the decision locally. So, then I was like, all right, the way this is actually going to work is our SDKs are, like, little interpreters for a very, very specific DSL, which is, like, the flag targeting, the logic of flag targeting. If the user is in Canada and they’ve logged in in the past 30 days, show them this variation, otherwise show them this variation. That’s just an interpreter over, you know, a particular script, which is, like, the user context. So, that was the first thing we did is, like, okay, let’s treat this as an interpreter, the SDKs are, like, interpreters, and let’s deliver the payload in advance and then do the evaluation in memory. And so, we did that, and I think that was one of the fundamental differences between what we were doing and, like, what A/B testing tools do where, like, Optimizely was basically, like, jQuery injection as a service, right? It was basically, like, taking—

Beyang: [laugh]. Right. Right.

John: —[crosstalk 00:51:16] edit the script and that was actually just producing a chunk of jQuery that they would then deliver over the wire and then transform the page on the fly. And we’re fundamentally different. We were, you know, living in your code, in your back-end or in your client-side, and we were executing the flag rules, the targeting rules inline. The next problem that we wanted to solve is, like, well, how do we get updates over to you? And so, initially, that was, like, polling. We’re just going to pull back home every 30 seconds. Turns out polling is really expensive and it has this awful experience of, like, you make a change and then you wait, and then you, like, refresh the page and, like, content changed and did a feature flag get updated? Is it because the polling didn’t complete? And so, we were like, how do we make this magical? How do we turn this into, like, I changed something in the LaunchDarkly dashboard, and instantly all of my infrastructure reflects that change? And so, we moved into a streaming model where we pushed the changes over. And that was also challenging because we live in your back-end infrastructure. WebSockets aren’t really going to work, so we ended up using long-lived HTTPS connect—persistent HTTPS connections and using a protocol called Server-Sent Events to push the changes over. And that was a real innovation, really cool. And then the next real hard challenge that we solved was client-side devices, browsers, and mobile devices, right? We view them as untrusted contexts. Like, you can’t—they have access in a browser and you can, like, ‘view source,’ right?

Beyang: Yep. Yep.

John: We don’t want to deliver a payload that contains who’s getting the flag. Like, we don’t want the, like, “If Canada is greater than 50%, give them [crosstal 00:52:59].” We don’t want to do that in the payload and make the decision locally because if you do that, you’re revealing information about, like, who’s getting the flag, who has access to it—business logic—to the consumer that shouldn’t exist. So, we changed the model there and the way that we changed the model was, we pushed the compute to the flag delivery layer, to the, like, push model now did a transformation step. So, we took the rule, we pushed them to a compute layer that lived closer to the device, like a CDN layer or somewhere like that, and then we transformed it for the individual user context. So, now when a phone connects to LaunchDarkly, it connects with the individual context for that phone. And now when we deliver the payload, we just deliver the results. So, we deliver—you get this variation for this flag, this variation for this flag, this variation for this flag. And the hard part about that is, like, if you change a feature flag, you have to push that change to, like, millions of clients and have all that computation happen for every individual client context. And so, that’s really expensive. Before we solved that problem, we were ending up in situations where, like, some of the big e-commerce customers would, like, change a flag, and, like, our entire infrastructure would, like, gasp.

Beyang: Just, kind of, percolate.

John: Yeah. It would just be, like, “Oh, God. I got to deliver a flag change to, like, multiple [crosstalk 00:54:25] devices.” And we couldn’t keep up with the load. And so, it took us a while to optimize that to the point where now we can handle all of that scale and it’s just all very elastic and globally distributed.

Beyang: That’s fascinating. So, I guess, like, at a high level, the problem that you’re trying to solve is you want sort of a centralized dashboard to be able to change behaviors in applications, but those applications live, you know, wherever in the world, on phones, in people’s browsers, on many different clients.

John: Yeah.

Beyang: And so, you want to be able to, like, give people the capability, like, “Oh, I’m going to turn this off and on,” and have that broadcast out as quickly as possible, and also for there to be limited impact on the latency on all the clients. Is that—

John: Exactly.

Beyang: Kind of the—

John: Yeah.

Beyang: Interesting.

John: That’s a really hard problem to solve. And it’s one that took us a while to solve, but now you change a feature flag in LaunchDarkly, the change is streamed out to servers, mobile devices, browsers, at pretty arbitrarily large scale within, like, a quarter of a second or less.

Beyang: That’s awesome. That’s awesome. And can you use it—so it’s software-as-a-service so, you know, if you have a cloud application, it obviously works. Can you also use it for self-hosted applications? Or set—like, is there, like, a self-hosted version of LaunchDarkly that’s deployable? Or does it all talk to, kind of, the central—

John: No, it’s—

Beyang: —command center?

John: All cloud. So, you still have to phone home, you still have to connect to LaunchDarkly. But we have different connection patterns that can kind of eliminate that or reduce that need. Like, we have a thing called the relay proxy which, it’s a basically a Go microservice that’s open-source that you can stick in your own infrastructure that can disconnect you from LaunchDarkly and act as a middle man. To our SDKs, it looks just like LaunchDarkly. It’s making all the same network interactions, but it’s not connected to LaunchDarkly. And so then, once you divorce, you know, your infrastructure from LaunchDarkly via that this proxy, then you can decide how you want change sent to that proxy. So, you can change something on your dashboard, you can say, “Okay, I’m going to, you know, push that out as a file and I’m going to put a file in a location and then my relay proxy will pick up that change and distribute it to my infrastructure,” for example.

Beyang: Cool, that’s super cool. I guess, like, last thing I would love to cover is the impact of using feature flags on developer experience. So, you’ve at this point worked with, like, many different organizations helping them, like, integrate feature flags and feature toggles into the application. For me personally, when we started using them at Sourcegraph, I found that it kind of changed the way that we did development. It enabled some things that were just, like, not possible before. It made certain things just, like, much easier. When you’ve kind of witnessed how feature flags have impacted development teams at all your customers, are there any, like, big themes or, like, patterns, or cool use cases that you’ve you, kind of, discovered that are, like, noteworthy or perhaps even surprising to you?

John: Yeah. All of those things. Like, the impact has been transformational in a way that I wouldn’t have anticipated. We see teams where, like, the vast majority of the change they push out is protected by a feature flag. And that to me is, like, an indication that we’ve actually fundamentally transformed their software development practices. That’s really cool. We also see use cases that go beyond just the sort of like, I want to mitigate risk by rolling this out, which is, you know, obvious and still, like, you know, the most common use case. We also see obviously, experimentation, right? Like, once you have two different variations, you have a control and an experiment, so the natural thing to do is to do an A/B test. But I think that that understanding of, like, oh, it’s for feature launches or it’s for A/B test is quite limiting and we see a bunch of additional use cases that go well beyond that. Things like long-term control. So, one of the cool feature flags that we have in LaunchDarkly—I think we’ve talked about this publicly a few times—is we rate-limit our APIs via a feature flag. And so, the way that works is we have rules set up that apply different rate limits based on the customer, or the route they’re hitting, or previous behaviors. So, for example, I can say simple things, like, mutative requests, like, patch or post or delete, they’re more expensive on our infrastructure, so they should be rate-limited, you know, at this rate as opposed to that rate. Or maybe there’ll be a time of duress where we see some particular customers stretching us, our own infrastructure in a way that we hadn’t anticipated. Like, they’ll start slamming a particular route that we never anticipated anybody slamming, and so we can just rate-limit that one customer super easily with LaunchDarkly and have that impact be rolled out instantaneously. And we’ll go from, like, incident level to, like, not incident in a quarter of a second or something like that.

Beyang: Interesting. So, it’s almost, like, you have this general-purpose, like, command and control dashboard for your application where you can toggle these behaviors without, like, going through the whole, like, cycle, like, pushing up a patch, like, waiting for a CI to pass and, like, updating the application. It’s just, like—

John: Yeah.

Beyang: You go to this dashboard, you toggle—

John: Yep.

Beyang: —a behavior on and off. That’s super cool.

John: It’s like a—a couple different ways to think about it. One is, like, it’s almost, like, you can parameterize certain aspects of your code and dynamically change those parameters without redeploying your application. So, you can then tune those parameters if you need to. Another way of thinking about it is, like, you can pull business logic out of source code because we have a fairly expressive targeting language. It’s like any kinds of conditionals, different operators like ‘starts with,’ ‘ends with,’ regular expression matching, so that you can pull business logic out of code and put it in a dynamically manageable layer, right? So, like, I can change pricing plans, I can add a new feature to a pricing plan by just, you know, turning it on in LaunchDarkly, giving access to a particular customer or a particular segment of customers in the LaunchDarkly dashboard.

Beyang: That’s super cool. Cool. So, we’re about at the end of time here, but before we head out, if folks are listening to this and want to give LaunchDarkly a try, what’s the best way to do that?

John: launchdarkly.com. So yeah, like I said, we have plans that work for anybody from a small startup, you know, two-person shop, all the way up to Fortune 100 companies. We actually have, like, over 30% of the Fortune 100 count themselves as—

Beyang: Wow.

John: —LaunchDarkly customers. So, any size team, really. Go to launchdarkly.com, you can get started. And I think one of the most amazing things about feature flagging and LaunchDarkly, in particular, is, like, you talked about all of the, like, ways to improve your development teams. And, like, quantitatively, you can show them that feature flags have a massively positive impact on, you know, things, like, meantime to remediation, like incident remediation times, developer productivity, but at the same time, like, unlike a lot of other things that can do that, there’s really no prerequisites that you need to have in place. Like, you can get started feature flag—you don’t need to have Kubernetes, you don’t need to have, like, you know, a service mash or some complicated architecture, or, like, a massive investment in, like, integration tests and testing harnesses. You can just add feature-flagging your workflow in a very simple way if you’re a small team, very easily. It’s one of the most powerful and beautiful things about it.

Beyang: Awesome. Well, my guest today has been John Kodumal, CTO of LaunchDarkly. John, thanks so much for being on the show.

John: Thank you for having me.

Ravi: Thank you so much for having me on.

Beyang: Awesome. So, I’m going to kick things off with, you know, the question I always ask every guest who comes on the show. How did you get into programming?

Ravi: Yeah, of course. So, it’s a while back, I probably got into programming around, like, you know, when I was 10 or 11 years old. This was back in, like, the late-90s. So, we had just gotten, like, the internet at our house, just, like, dial-up modem. It was I think NetZero was the name of the service. And yeah, so basically, I thought this thing was pretty cool and I wanted to make my own websites.

So, you know, I found, like, one of those online free website builder, Geocities-type things and started there with, like, those kind of WYSIWYG UIs and stuff. And I wanted to do more sophisticated things. And by ‘my own website,’ I don’t mean, you know, anything super interesting; I mean, like, a place to share video game cheat codes, or whatever I thought was cool at the time. And so, I think I was using Dreamweaver. I, like, got a copy of Dreamweaver from, like, my dad bought me a copy of Dreamweaver and then I started playing with that to, like, build websites and stuff.

And so yeah, just basically did a lot of, like, WebDev type stuff throughout the next several years, increasingly building more sophisticated things. And then I was really fortunate to go to a high school that offered a couple programming classes, so I learned some, like, basic C++ Java stuff as well, and learned, like, the basics of object-oriented programming and all that kind of stuff. So yeah, really just developed a love for, like, building stuff and seeing the product of what I’ve built. Everything else that I ever learned at that time in my life was like, oh, you learned this cool thing and math class, or history class, or whatever, and it’s just sort of—it feels like it’s just information in your brain. Obviously, it’s sort of building patterns and concepts and stuff that will help you be a good person or whatever, but this was like, “Oh, I learned a cool thing,” and then I can, like, go and, like, hack it together and say, like, “Hey, I made this thing.” That was like, incredibly rewarding, and that feedback loop just sort of grew.

Beyang: That’s awesome. So Dreamweaver, you’re building websites as a kid, and then you studied some amount of programming computer science in high school. I understand that you didn’t go and become a professional software engineer straight away though. There was a bit of a detour in your life.

Ravi: No. I think if you took a kid who had been building websites and writing code since ten, and then took programming class in high school, and then majored in computer science, and—I don’t think you’d get what happened next. But after I graduated college, I was actually a professional musician, like, a DJ slash producer for a couple of years. So really, another hobby of mine, a lifelong hobby of mine has been playing music and then writing music as well. I’ve always written songs. I was in bands in high school and stuff like that.

And so, in college—well, I was in a band in high school and then I went to college, and then I didn’t have a band anymore, so I started making EDM because you can make it by yourself on a laptop alone.

Beyang: Yeah.

Ravi: And then so I got really into making electronic music, I put a lot of my stuff on the internet, and then around, like, 2010, 2011, a lot of my stuff got very popular on SoundCloud and YouTube and then people started paying me to do shows. And then when everyone else was applying for jobs, I was like, “Well, I could keep doing this thing.” So, I kind of kept at it for a couple of years before I went—well, before I made it back into what I was probably meant to be doing anyways. But yeah.

Beyang: Was there anything that you, kind of like, took from the music world that informed the way you approach software and code?

Ravi: Not in a direct sense, but I would say, indirectly, I think the thing I loved—so I’ve been making music my whole life, but, like, when I was in high school, I was in bands with, like, multiple people and you have, like, physical instruments, and then you have to, like, record things, like, on your guitar and vocals and all that kind of stuff, and then you got to spend a lot of time, like, arranging it and putting it together. And it’s like—and then you see a final product of what you’ve built. And that feedback loop is really slow. And then nice thing about—like, I wasn’t even into electronic music.

I got into it because of the ergonomics of how you make electronic music. It can be done all software, all on your own computer, all the digital stuff. And you, like, program in a melody or something like that into a VST, into your thing, and then click the play button, and what comes into your ears is literally identical to what the end-user is going to hear, which is not true of, like, a physical instrument or something like that. And so, the feedback loop is way, way, way far. And also you don’t have to deal with five other people and coordination.

So, that the idea of, like, just, like, fast, fast feedback loops and that reward that, like, instant dopamine rush of, like, making a thing and seeing the thing, and that, like, it’s true of electronic music, it’s true WebDev, and it’s something that I, like, I’m very attracted to. I don’t have the patience for, like, long cycles and planning things out, and thinking through things, and, you know, working in that way. So, I think that’s always been really appealing to me, and that’s why I’ve found myself doing the things I’ve always done. That’s why I’m working on, you know, a SaaS tool now, rather than many other things in the wide world of tech that I could be doing instead.

Beyang: Yeah. Fast iteration times. I think those are, like, really key, and I think a lot of developers out there would find what you just said, just, like, spot on.

Ravi: For sure.

Beyang: Yeah. Okay. So, what was kind of the journey? You’re making music professionally for a while; what brought you back into the software world?

Ravi: Yeah, I mean, so, like, I made music professionally, like, accidentally, to be honest, right? Like, I made music, I put it on the internet, it got popular, and people started paying me to show, so I kept doing it, and I sort of stumbled into it. But the, you know, the nature of it is, like, you’re playing shows, maybe Friday, Saturday night, maybe Thursday night or something like that. Most of—you have a lot of free time, and in that free time, I made music and stuff like that, but I wasn’t a super-disciplined 21-year-old when it comes to that stuff, so I had a lot of downtime. And sometimes in that downtime, I, you know, watched TV or whatever, but other times I just, like, hacked on stuff with my friends.

So, a good friend of mine from college, Matin, right after college, he went to Facebook and worked there for a little bit, but then he left Facebook and was hacking around some startup ideas. And then I kind of worked with him on a few different things that kind of went nowhere. But then, you know, one day he sort of came up with this idea for Heap. And, you know, we started working on that together. I actually didn’t start working on it together with him initially. It was just one of the many projects that he was working on. It was like, “Yeah, that sounds interesting. Whatever.”

But, like, you know, he was persistent and he said, “Hey, I think this is going to be a really special idea,” or something like that. And then he kind of convinced me and I was like, “Yeah, this makes a lot of sense.” So, also kind of stumbled into that to be totally honest. And then we started working on Heap together, we did YC together, raised some funding, and then it became very real, and I was like, I can’t, you know, tour [crosstalk 00:07:15]—

Beyang: [laugh].

Ravi: —anymore. So.

Beyang: It won’t work. The co-founding a company and touring professionally, both—

Ravi: Yeah.

Beyang: —rather time intensive. [laugh].

Ravi: Yeah. A little bit different. So, yeah. And then I was just heads-down on Heap for the next several years.

Beyang: Interesting. So, I think, you know, one of the things folks would be curious about is, like, what were some of the other ideas that you explored? What was that, kind of like, primordial soup, like, of ideas and experimentation? Are they all, kind of like, similar to Heap? Or were they different or—

Ravi: No they were pretty different. I mean, so I wouldn’t even say that, like, what I was doing was exploring startup ideas. Like, what I was doing at the time—this was back in 2012, right—like, I was making music, I was doing my own thing. I was like, it’s fun to hack on side projects. Mateen had left Facebook, he was kind of thinking of it more as, like, startup ideas, but even then, we just wanted to hack on stuff together because we’re friends and wanted to work on stuff together and we had the time to do it.

So, we made, like, really dumb stuff. Like, we have, like, a meme generator. Like, you know, those memes where you have, like, the text at the top of the text on the bottom, we, like, made a thing where he can make those really easily. There’s, like, 100 of them on the internet, but, like, at the time, they all—they weren’t very good, and we were like, “We can make a better one.” So, we made one that was better, supposedly. I don’t know.

And we did, like, a few other things like that, like, really silly, kind of, social app type idea type things. And then I think, like, one of the reasons we built Heap—I mean, Mateen had worked at a real job before at Facebook and he had, like, firsthand struggled with their internal analytics system. And then in a lot of these other things we felt, you know, the first thing you do is you, like, throw Google Analytics on there, or Mixpanel or something like that, and then we always, like, had some pain around, like, oh, you built this thing? We shipped it. “Oh, looks like some people are using it.” “Oh, what are they doing?” “Oh, I don’t know.”

Beyang: Yeah.

Ravi: And so, we constantly had this, kind of like, some minor pain with analytics. And so, Mateen kind of came with this idea, like, the problem that we always had with a lot of these small apps and widgets we made—and that Mateen had a much greater scale at Facebook—was, you know, you ship something, you would track the things you thought were important, and then people would use it, and they’d use it in ways you didn’t expect, and then you’d be, like, “Oh, but I don’t know what’s actually going on there. I wish I had tracked X. I forgot to track them clicking on that button, or I didn’t track that string because I didn’t think it was that important, but that’s actually where they’re going.” So, there’s stuff like that you would think of later, and then the idea for Heap was like, Mateen was like, “Well, why don’t we just track everything people are doing client-side and, you know, vacuum up all that data? And then what do you think of a question later on, you can go back in and retroactively pull out that data point, even if you didn’t think it was interesting at the outset.” So, that’s the idea behind Heap and that’s kind of how Mateen, sort of, came up with that idea.

Beyang: Yeah, yeah. I remember that because, like, you and I go back to college as well and I remember chatting with you in those days. And I think the original way that Heap was pitched to me was, “Hey, like, you’re never going to be able to fully anticipate all the different ways in which users are going to use your product, so why not just track every single user action, we’ll capture, you know, all the CSS tags and DOM events, and then later you can kind of construct your analysis on—”

Ravi: Exactly.

Beyang: “On top of that.” Which is really cool. And talk more about how that idea kind of evolved. So, like, first, it was you and Mateen working on this thing that would allow you to track usage of your own, kind of, pet projects. How did that become a company? At what point did it become kind of, you know, real and, kind of like, a serious thing that you both decided to, kind of like, go all in on?

Ravi: Yeah. So yeah, exactly. It started as something pretty small. Mateen just hacked together this, you know, probably 100-line JavaScript script that you could drop into a website and it would just track every relevant DOM event—every click form submission, tap, page view, whatever—and then just, like, shove that into some database. And then you can just query the database if you wanted to.

And if you, like, forgot to track a certain thing, then you could be, like, “Oh, well show me all instances of clicks on, you know, the div that has the class name, ‘sign-up-button,’” or, you know, whatever. So, that was kind of how it worked. It was just, you know, tracks a bunch of stuff, dumps it into a certain place, and then you can query it, and there was not a whole lot else to it at that point in time. And I remember—like, so actually kind of didn’t work on the initial phases of it. Mateen—like, [unintelligible 00:11:29] projects, Mateen wanted to hack on this and I was like, “Ah, whatever.” Like, that’s kind of how I felt about it.

Because it was more B2B and I had been a DJ for two years, so I didn’t have really strong need for analytics, so it visceral appeal to me. But, so he was kind of hacking on that thing and then I think he just, like, pitched it to a lot of people saying, like, “Hey, here’s this idea. Like, what do you think? Like, you use analytics.” And everyone’s, like, “Oh, yeah, I have that pain point.”

Like, you know, “We always forget to track stuff.” All that kind of thing. So, you hear that enough times you’re like, “Oh, there might be something real here.” So Mateen, kind of like, reapproached me, he was like, “Hey, there’s something actually real here. You may want to work on this.”

I’m like, “Yeah, okay. That sounds reasonable to me.” And, you know, Mateen is a smart guy and I trust him, so, like, a lot of it came down to that as well. So, we started working on it together. And yeah, like, really, like, the way we kind of approached it was, like, hey, we’re solving this fundamental pain point that we had with other analytics tools—Mixpanel, Google Analytics, all that kind of stuff—which was around, like, not tracking all the right things.

But the other things those tools did were quite… fine, right? Like, it’s not, like, Mixpanel funnels are bad funnels or anything like that, right? So, we actually ended up I think, just copying a lot of design patterns from not just Mixpanel, but, like, whatever the best-in-class stuff was the time, Mixpanel, Google Analytics, Kissmetrics, there’s a few other vendors at the time that were doing interesting things—Flurry—and so we said, like, “Okay, like, let’s sort of get to parity on, like, kind of the reporting features and all that kind of stuff and have this, like, core innovation, which was around data collection.” And so, that’s what we ended up doing. And we built, like, a really bare-bones MVP that allows you to track data automatically, you know, specify a CSS selector and an event type, like, a click or form submission or whatever, and then turn that into an event.

And then you can use those events in the typical event-based analytics that you’re used to with funnels and retention graphs and all that kind of stuff. So, we mainly just spent several months, like, hacking that together and building, kind of like, a very early MVP. And we went through Y Combinator and a lot of the early users of Heap were just other Y Combinator companies in our batch. And luckily, they’re also a bunch of tiny startups so data scale was not super large for any of them. So, that was not a thing we had to worry about a ton in the early days, which was nice.

And yeah, and just iterated based on their feedback and things like that. So—and then typical SaaS stuff, did a launch, got customers, listened to their feedback, et cetera, et cetera, et cetera. So yeah.

Beyang: Was there a point at which it, like, really clicked for you? You know, like, whether it was, like, the first customer outside of YC, or you know, a particular user testimonial, or some, like, metric or milestone that you hit when you thought to yourself, like, “Yeah, like, this is really going somewhere, taking off?”

Ravi: Yeah. So… yeah, I would say there is a moment not, like, a specific discrete point in time, but like, there was, like a—there was definitely, like, a period where we kind of, in retrospect, hit a certain level of product-market fit that made it sort of viable business. I wouldn’t say that at the time we understood that that’s what had happened, right? Like, so Heap got started in late-2012. Yeah, we spent most of 2013 just building what I kind of described, like, building the product.

We did a launch in, like, April of 2013. We got a ton of signups for it. Like, the core concept really resonated with people, but there was a lot of ways in which it fell short of the promise. So, one major way was just infrastructure. As I mentioned, all of our early users were small YC companies that didn’t have much data scale, but the moment any, like, real company with any real willingness to pay, tried to use it, it would really—everything would time out and just not work.

So, we spent a lot of time that you’re really just, like, iterating on the infrastructure and making it functional for even, like, modestly-sized companies. So, Dan Robinson, who you know, Beyang, came on board the team at that time as CTO and helped work on a lot of that stuff. So, that was one big bottleneck. The other big bottleneck was—and this was really, like, kind of a mindset shift, too, was we built—Airplane—I mean, not Airplane. We built Heap as a developer tool because we’re developers who are solving our own problem.

But in most companies, the people using analytics aren’t necessarily developers, right? They’re product managers, or marketers, or analysts. And the way Heap worked at the time was, you dropped this JavaScript snippet on your website, it would track every dumb event, every click, whatever, and you would then go into Heap and say, “Hey, when someone clicks on a div with the class name, ‘sign-up-button’ or whatever”—or a button with a class name, ‘sign-up-button’ or whatever—“Call out the signup event.” You have to specify the CSS selector yourself. Most people don’t know—most people who wanted to do use Heap don’t know CSS, so you’re going to have to, like, teach people, “Hey, right-click on the thing that you want to do and click ‘Inspect Element’ and copy-paste that thing over there if you want to analyze it in Heap.” Which is obviously not, like, a super friendly workflow.

And so people—like, we thought of it as this is going to accelerate developers, but what people wanted was, like, low-code, or no-code analytics, really. And so, we weren’t really delivering on that because you still have to understand, like, how CSS and your DOM works. And even if you are a developer, you don’t just have, like, a bunch of CSS class names memorized for, like, what’s in your own DOM. So, you’re still kind of having to, like, do Inspect Element and a bunch of stuff to, kind of like, figure out what you’re trying to define. So, that was like not a great user experience.

And some people figured it out, but the vast majority of people would, like, look at our slick demo video where we kind of gloss over that detail and then get into it and be, like, “Oh, this is actually way more complicated than I thought.” So, we had to improve the infrastructure and we had to build this thing that we call the event visualizer, which was just, like, a WYSIWYG point-and-click way to find events. So, it would pop over onto your website, you could, like, hover over an element, you could see a red box that would say, this is what the element is that you’re trying to find, you click on it, you give it a name, you’d never have to worry about what the CSS selector was. And we’ve put a lot of effort into, like, kind of automagically figuring out what you were trying to click on. Because, as you know, like, the DOM is, like, a nested hierarchy of things, and are you clicking on the outermost div that you’re floating over, or this little button, or just that text within the button?

You know, like, all that kind of stuff is really complicated, so you know, Mateen built, like, a really, really slick interface for sort of defining events and stuff like that. So, we released that, the event visualizer, in February of 2014, and that was the point at which, in retrospect, we—the shipping of that and then we also shipped, like, our improved infrastructure around the same time, some big changes to the infrastructure at that time—so Feb 2014, was the first time where people—people were signing up the whole time because, like, the promise was really good and people were just finding it somehow, but that was the first hour people signed up and, like, a non-trivial percentage of them actually stuck around for the first month, after free trial, and, like, paid and kept paying. We were like, “Oh, that’s kind of new.” Like, they’re not just churning, so that’s cool. And then, like, also, our support ticket volume grew from, like, three to five support interactions a day to, like, 50 in the span of, like, three or four months.

And that was just, like, whoa, people are asking real questions, not just, like, “Hey, can you help me get started,” but, like, “Hey, you know, like, my funnel is showing this data, but it doesn’t really match up with my—” you know, like, that, kind of like, real questions that indicate some level of engagement with the product. And so, it kind of exploded overnight, and in the span of, like, three months, you’re, like, wow, the volume has just, like, really taken off. And so, like that was clearly when we had a sense of, like, product-market fit.

Beyang: Cool. And when you talk about, like, the support ticket volume going up, how did you handle that? Because I imagine the team was still pretty small at that point in time. Was it just, you know, the three of you?

Ravi: Yeah, it was the three of us, and then we had one other engineer on the team. That was, kind of like, the last time I ever wrote code at Heap around that time because I was actually doing all of the support by myself. I mean, we were—like, things that were really specific to something that Mateen or Dan knew well would get escalated to them, but for the most part, I was handling all of it. And so, there was one point, it just got to where I was just answering support tickets literally all day long. And so, that’s what we said, like, “Hey, we should probably, like, maybe hire for somebody to help with this.”

And then so at that point, I basically shifted over onto, like, building out that customer-facing side of the company. So, I hired the first couple of solutions engineers to basically do support and, like, customer enablement and all that kind of stuff. I hired the first few sales reps at that point to handle the inbound kind of people looking to use the product, all that kind of stuff. So, that was kind of the beginnings of that transition over onto building up the go-to-market side.

Beyang: Yeah. I feel like, you know, people talk about, you know, founder-led product and founder-led sales, but we don’t talk enough about founder-led support. I feel like support is one of those critical functions. Because when you’re starting out, it’s literally, like, where the rubber meets the road, right? People are trying to use your product, they’re running into issues and, like, you are literally the only person in the world who can bridge that gap.

Thinking back to early days of Sourcegraph, like, I also spent a good deal of time in the support role. And it seems, like, a maybe, like, not talked enough about thing because it’s so critical to making sure your early adopter users, customers have a good experience.

Ravi: Absolutely, yeah. And I think it’s also—I think something changes when a company sort of creates a dedicated support function and sort of abstracts that away from the founders, the engineers, or whatever. And if you keep those things too separate, which we did, I think, at certain points at Heap, I think the feedback cycle of, like, getting the customer pain points into the ears of the people building products, there’s just a game of telephone that happens there a little bit. And you—whereas when you’re the person who’s both building a product and fixing the issues in the product, like, you have just intuitive sense, even if you never quantify anything at all, of like, what’s wrong, what’s important, what’s not important, what’s repeatable, and you can sort of translate that directly into roadmap in a way that you just inevitably lose, as you grow. Obviously, you gain a lot of other great things as you grow, but you can never really replicate that. And so, I think you should try to not let go of that as much as possible. I think at Heap we let go of that a little bit too soon, in my opinion.

Beyang: Interesting. You’re talking about like that kind of—it’s like the whole user feedback cycle. Like, you know, support—you know, ‘support,’ which is really just you—hears about it, and then relays—in a large company, you’d relay that to the product team and then the product team would incorporate that into the roadmap and trade that off against other priorities. But, like, in the early days, when it’s mostly just the founders and the first couple of employees, it’s like, you are wearing all those hats in some sense, so you can, kind of like, quickly feed user pain and customer asks, just, like, super quickly into adjustments in the product roadmap.

Ravi: Exactly, yeah. And, like, when it’s just the founder doing all that stuff, it’s like, the feedback loop is both fast, and it’s, like, as high fidelity as it’s ever going to get, right? Like, it’s, you know—I feel like when you’re on a certain scale, you’re like, “Oh, we have a support team and a sales team.” And they, like, write all the customer requests into some spreadsheet somewhere, some, like, SaaS product that tracks those things. And then the CEO, 80 customers requested the X, Y, Z feature, but like, that is not, like that’s great that that’s there, but that’s, like, so much thinner than being, like, I directly had the conversation with the customer who wanted the X, Y, Z feature. And, like, actually, the X, Y, Z feature, what it really represents is whatever, right? And I think that, you know, being the same person who hears that and then implements it and scopes that out, that connection is difficult to replicate.

Beyang: Yeah, totally. So, you know, in that experience of running frontline support, were there, kind of, beginnings of what would eventually become Airplane there? Because, you know, as I understand it, Airplane is all about turning these scripts that you might write, you know, as a support engineer, maybe as an engineer supporting the support team to do these, kind of like, ad-hoc or, you know, one-off tasks.

Ravi: Yeah, exactly. I mean, that’s really where the idea for Airplane came from, is, like, the five years I spent running support, sales, professional services, customer success, marketing, all the kind of customer-facing roles in the company. And so, you know, Heap is a fairly complicated cloud product; it’s analytics, and so there’s a lot of ways in which your data can kind of be weird or not the shape you want it to be. And so, for example, you implement a certain identity API wrong and then all of a sudden, you’ve done things, like, grouped 1000 users as one user in a way that’s irreversible or something like that. And then your data is just permanently messed up unless somebody can go and, like, undo that. And there’s no big [unintelligible 00:24:35] undo button in the interface, for obvious reasons.

And so, that kind of stuff would happen all the time. And in these situations, like, our solutions engineering team, or professional services team didn’t necessarily have the tools to, like, solve those issues. Like, these, like, really niche, like, data issues that would take a lot of compute or resources to, kind of, solve it’s not a thing that you just want they have, like, some off-the-shelf button that, like, does whatever. So, what ends up happening is our solutions team, or professional services team, or whoever, would escalate a lot of these things to engineering. So, it’d be, like, these, kind of clean up this data or, you know, somebody wants to fulfill these GDPR requests, or somebody needs even simple admin operations like someone needs and email address changed, or something like that.

Those kinds of things would have to get through, sort of, fulfilled by someone on the eng team. So, someone on eng, we had this library of, like, 70, 80 scripts that we developed over time, so someone from eng would just SSH into a production server and run a script, or run a query, or something like that to solve one of these issues. And then for some of the more common issues, like, these would be constant, like, every few days escalations that people were just getting hit with. And in aggregate, it was happening dozens of times a day.

Beyang: Huge disruption.

Ravi: Yeah. It’s like, it’s very interrupts heavy, there’s a context loss often, like, someone from support will say, “Oh, I need x done.” And someone will do it and they’ll be, like, “Oh, that’s not what I meant.” There’s just a latency issue where, like, “Hey, you found the Jira ticket and then it takes four days to solve because someone, you know, worked on other things.” And so—and it’s just disempowering in general to feel like, hey, I’m customer facing on a candidate solve a lot of their problems myself because I don’t have the tools to do it.

And so, that was kind of the status quo. And the other problem is, like—so we would say, like, “Okay, great. We should just build better tooling for the support team.” And, like, the problem with that is that, like, let’s say you have this script that is very computationally intensive and takes an hour to run, turning that into a tool is, like, pretty non-trivial. Like, you need to put a UI in front of it, you need to have it notify someone when it’s done running, you need to have some sort of mechanism by which it can be rerun if it fails, or something like that.

You need to—you know, what, if it stops in the middle, what are you supposed to do? You need to, like, make sure, oh, this is a, like, very computationally intensive script, it’s not going to tie up resource in a way that’s, like, you know, not what we want. You need to make sure that if it’s sensitive and irreversible, or somewhat irreversible, you need to make sure there’s permissions around so only the right people have access to it. You need to make sure it there’s an audit log around it so that if something bad happens, you know who did it, when they did it. Like, it probably should integrate with your identity provider. When you have a 200 person company, you can’t be adding people manually to this tool every five minutes.

All those things are, like, a big pain to build, right? Like, you maybe wrote that script in a couple hours of work, but, like, integrating with all those other systems to make all that other stuff happen is going to be probably ten more hours of work to really do correctly. And so, that was kind of where the idea from Airplane came. Because all those things I just described, those are kind of boilerplate. They’re the same in every company. The bespoke logic of this script is specific to your company, but the UI, notifications, permissions, audit logs, approval flows, all that kind of stuff is pretty—you know, we can give that to you off the shelf. So, that was the idea behind Airplane.

Beyang: Yeah, that I feel like that pain point, it feels universal. I feel like almost every developer has had an experience where, you know, someone comes to me with an ask, maybe it’s a support engineer, maybe it’s someone on the sales team, maybe it’s someone fielding a customer request like delete this user. Now, I got to go do something. It’s like, not worth building it into the actual product. It’s just, like, a thing that I need to get done. I go hack together a Bash script, I write it once, you know, intending never to think about it ever again. I just need it to do this thing.

And then, you know, a couple days later, same thing pops up and I’m like, “Okay, I guess I’ll revisit the Bash script.” And then later on, someone wants to reuse the script, I send it over and they run it. It doesn’t work and then now I have to, like, field a bunch of questions about this. And okay, so like, that’s the pain point that you’re solving.

Ravi: Exactly.

Beyang: How does Airplane solve it? And maybe we could dive into the product a little bit?

Ravi: Yeah, yeah. I’ll give a high level, and then I’m also happy to show a demo of that, if that’d be interesting.

Beyang: Cool. Yeah, that’d be awesome.

Ravi: Yeah, so basically, the way Airplane works is, let’s say you have that Bash script that you described, what you can do is you, basically—we have a command line utility that you can use to deploy that Bash script to Airplane. And what that means is that we will, you know, wrap that in a Docker container, and then when somebody goes into—and then it can live within your cloud, it can live in our cloud, that’s kind of up to you. We have, kind of, a self-hosted agent which is pretty easy to use that you can deploy behind your own VPC. And then when somebody goes into the Airplane UI, they’ll see that, you know, whatever you named that script, so, you know, call it, ‘Delete User’ or whatever, and it’ll take in whatever parameters you specified and then they can basically just fill out those parameters in a webform, essentially. Hit ‘Execute’ and then it’ll spin up that Docker container, run that script, passing those parameters, and then print out whatever outputs that script generates to the screen.

So really, really simple concept. It’s just sort of like, a wrapper around that script. But the wrapper achieves the effect of not having to worry about, like, the environment in which it’s running. It’s, sort of, serverless; you don’t have to care about it. As the end-user, you don’t have to be technical. You don’t have to, like, know how command lines work to be able to run that script.

You can put some, like, guardrails around it around it, around, like, the input validation rules and all that kind of stuff, so you make sure garbage doesn’t get passed in. Everything that gets thrown in Airplane is audited. If it’s a long-running thing, you can get notified when it’s done running or if it fails. Like, if it’s a really sensitive thing, you can put an approval gate in front of it so that someone can only run it if a second person has said this is okay. So, all that kind stuff is really easy for you to configure as the end-user of Airplane.

The idea is like that Bash script that you described, the first time you write it, you probably just run it one-off. The second time it ever comes up, like, the marginal effort to turn it into an Airplane script should be so low that you never run it a second time, sort of, yourself, right? That should be the idea. And so, we really try to make it so that is literally a one-minute process to turn that script into this shareable, safe widget.

Beyang: Awesome. Can we see that process? Is that—

Ravi: Let’s do it.

Beyang: All right.

Ravi: Yeah, let me—

Beyang: And for folks listening, you know, audio, I will narrate what’s happening on the screen. And you can always go to the site, we’ll drop that in the [show notes 00:30:56], if you want to check out the product directly. [crosstalk 00:30:57].

Ravi: So, this is the Airplane UI. So, this is basically what you see when you log in. And so, this is kind of what an end-user sees. They see a library of, kind of, operations that are available to them. So, all of these represent kind of individual scripts. We call them Tasks, like—

Beyang: So, there’s a giant list. These are all, like, scripts that people have written and, kind of like, productized in Airplane, right now?

Ravi: Right.

Beyang: Okay.

Ravi: Yeah, this is our demo instance, so it’s a little bit messy. There’s a lot of duplication here, but, you know, you can organize things into folders, you can favorite things, all that kind of stuff. But you can basically—it’s just a big list. So, you can search through it, all that kind of stuff, but it’s not super complicated. And so, let’s say you wanted to do something here, you know, like this ‘Issue Stripe Refund’ Task over here.

You just click on it and it’s represented by a webform. And so, as an end-user, you would sort of fill out the webform, you know, type in whatever the details are that you need, and then hit ‘Execute Task’ and then basically, it’ll sort of spin up a Docker container, run that script in, you know, whatever environment that was configured when this was built, and then you’ll see some output over here of what happened. And—

Beyang: Wow.

Ravi: So, you basically have, like, user-readable output over here, which you could just pass in a JSON blob into a print output function that we basically give you and it’ll look like this. And then there’s also just your standar raw logs, which is just, like, stout over here as well. And so, as a developer, you can use [unintelligible 00:32:19] to debug it. If something went wrong over here, you can put whatever you want to stout. But you can also show, like, pretty printed logs to, like, the end-user.

So, that’s kind of what the end-user experience is: very, very simple. You run a script, you get a result, it shows up in this activity log over here where you can see sort of a full history of what everybody has done in here. And so, that’s the end-user experience. Developer experience is pretty simple as well.

So, you hit ‘New,’ and you hit ‘Task.’ And then basically, you get a number of options in terms of how you want this Task to get executed. So, for example, if it was that Bash script that you said earlier, you would pick ‘shell,’ if it’s like Node or Python, you can do that. You can also use, like, SQL and REST to—so if [unintelligible 00:33:01] have write as much code. I’m actually going to demo this using SQL just because it’s sort of the easiest to show in the UI itself. The rest of these require you to use your command line to actually deploy stuff to Airplane, which is actually the prominent way people use it, but it just takes a little bit longer to kind of demo.

Beyang: Okay, so in other words, you have two options, I could write the script on my own machine and then upload it to the Airplane. But you also have, kind of like, an in-the-GUI way of just writing a quick script, which is what you’re showing now?

Ravi: Right. Right. And so, I’m going to show the GUI way of doing it. But, like, we actually prefer that you write these things locally, but [crosstalk 00:33:33]—

Beyang: Sure. But this is for the demo. It’s like—

Ravi: Yeah, yeah.

Beyang: Yeah, yeah, yeah. Okay, got it.

Ravi: Yeah, so I’ll pick SQL over here, I’ll give it a name. So, I’m going to pick something really simple. So, like, ‘Update a user’s email.’ So, this is basically just going to be a Task that updates a user’s email address. So, maybe it takes in whatever their current email is, and that’s maybe a text field, and then it also takes in the new email, and that’s also a text field.

And then over here, I can specify input validation rules, you know, regexes that this should match or things like that if I wanted to. I can also do much more complicated inputs. These are just strings, but I could do file uploads and date-times and stuff like that. So, I’m just going to hit ‘Continue,’ though. So, I pick a database for this to query against.

So, I’ll pick this demo data database and I just specify the query. I’m going to add a couple SQL parameters, just so that we don’t have, like, a, you know, an injection attack, but I’ll do something like this. So basically, what I’m doing here is this params—like, these double curly braces with this params syntax. This is basically—

Beyang: You’re just substituting a value into the script, right?

Ravi: Right. Yeah, so this params is, like, the global object that represents, you know, the two parameters that we specified earlier. And then [unintelligible 00:34:46] query, so it’s something like ‘update users set email :new_email where email :current_email;’

Beyang: You got syntax highlighting and autocomplete. That’s pretty cool.

Ravi: Yeah. I think it’s just some library that we’re using to do all that, but—

Beyang: Okay, cool.

Ravi: Yeah, so you get some simple introspection here on the database and stuff. But, so yeah. So, once we specified our query, I hit ‘Create Task,’ and that’s all I had to do. So, now I’ve taken maybe what I was previously going into the database myself and running and turning it into a thing that anybody can just fill out an email and run. I’m actually—let me pull up an example email so that I can just show it in action.

Beyang: So, what he just did is he typed the SQL into the box and then he templatized it. And so, now it’s like templated by these input fields ‘email’ and ‘new email’ to update the user’s email. And now you have, like, a kind of a button you can click, and then you fill out the form, and then it runs that script for you.

Ravi: Exactly, yeah. So, I’m going to run this Task we just created in 15, 20 seconds of work, and just specify this current email [email protected], and I’m going to just add a ‘+1’ to Billy’s email over here. I’ll hit ‘Execute Task.’

So, it ran it pretty quickly. It’s a simple one-row SQL query, and it says, one row affected. The output here isn’t super expressive; it’s just a simple SQL query. But if I go back to this ‘List all Users’ Task, which is just a SELECT query against that same database, hit ‘Execute,’ and then look up Billy over here, I’ll see that he now has a ‘+1’ after his email address in the database. So, not super surprising.

We ran a simple SQL SELECT query and it updated the database as expected, but the idea here is that, you know, now I never have to go and do this myself again. As a developer. I can just basically have anybody in my company have access to this Task. And there’s very little room for error there. Like, that SQL query is going to—you know, if they were using something like [unintelligible 00:36:37] or one of the SQL editors, there’s, like, infinite degrees of freedom there where you could accidentally [bring up 00:36:42] query without a WHERE clause or something like that.

But over here, you have just, like, a guarantee that this is going to be executed the way you expect. And you also—it’ll live in your activity log. The other thing here is that, if I edit this Task and I go to Advanced over here, I can get a lot more granular about who has access to this. So, if I hit ‘Explicit Permissions,’ I can say, you know, maybe we only want the engineering team, really, to have administrative access, which means only they can kind of run it—or edit it—but you know, I’m going to say, Josh, my co-founder, he’s only going to be a requester, which means Josh can’t actually run this himself. He has to make a request to someone on the engineering team who has admin access, before it will actually run.

So, I hit ‘Update Task’ what Josh would see is he would see a UI that looks something like this. So, same as the previous UI, ask for a current email and a new email, but it also asks you to give a reason and pick a reviewer. And that reviewer would then get a Slack notification which says, “Hey, Josh, is requesting this ‘Update User Email Address’ Task to get run. Do you approve it or reject it?” And so, like, you can really easily add in these kinds of, like, flows that are really important to be able to run sensitive operations at scale in a larger organization.

And so, like, you know, it’d be fairly—it wouldn’t be difficult, but it’d be time consuming to create a system where in order to run this script, I want to make sure that someone has to make a request and someone within a different user group gets a Slack notification asking them for that request. We basically just bundle just those concepts together in a thing that you can configure with a couple of button clicks.

Beyang: Oh, that’s awesome. So, like, if I want approval, I can get approval, and upon approval, it will automatically run. I don’t have to, like, sign back in and, like, rerun with approval, or—

Ravi: Exactly.

Beyang: Okay.

Ravi: Yeah. Yeah, once Josh hits—or someone in the eng team hits ‘Approve’ in Slack, then it just runs automatically. So, that’s the high-level idea is just to make it as simple as possible to, like, broaden access to scripts and queries and things of that nature, while keeping it as safe as possible. And so that’s, like, the high-level basic concept of the product.

One thing I don’t want to get into right now, just in the interest of time, is we have a feature called Runbooks which allows you to, sort of like, orchestrate these things a little bit. So, let’s say you’ve built several scripts and you want to create something a little bit more complicated. You know, let’s say you have a—I’ll give an example—let’s say you have a delete user workflow where what actually you want to do is first from script that deletes the user from prod, that I’m going to run another script that hits the Intercom API, unsubscribes them, and then hit another script that, like, generates an archive of all their historical data and then finally sends them an email with an archive. I can build three or four different Airplane Tasks for each of those steps and I could stitch them all together into one Runbook where I can execute them in order, pass data between them, have conditional logic, all that kind of stuff, to that flow.

Beyang: So, you’ve built your—Runbooks is the way you compose these primitives that you’ve constructed. It’s almost, like, your, like, your own internal version of Zapier.

Ravi: Yeah, exactly.

Beyang: Awesome. What’s been, like, the… like, what do you think about, like, Airplane v0, like, the first thing that you shipped that you thought, you know, was going to be the product that people wanted, what are the big differences between that and what you have now? Is it largely the same or, like, are there any, like, major, kind of, realizations you had along the way?

Ravi: Yeah. The core of it is the same. I mean, we start with this idea of, like, how can we make it really easy to turn a script into an app, right? That was kind of the high-level idea. So, that core is still there.

Things that we have added not just features that we’ve added over time, but I always say the biggest mental model shift has been, you know, I—when we started Airplane, I would say that the primary thing that we were trying to do was make it possible to take things that can only really be as written scripts, right, like, things that aren’t super easy to model as a REST endpoint, or a simple SQL query, or a CRUD operation, and turn them into things that would be appified. Because he had so many of those Heap had so many of those. Heap is digital company; there were tons of these, like, long-running operations, these multi-stepper operations, sensitive things—

Beyang: Complex things, involved things.

Ravi: Yeah. That’s what we thought would be, like, the core use case of the product. And then it’s still very much what you can do with Airplane, but a lot of what people do with the product is really simple stuff that honestly, you could do in 20 other ways, right? Like, the update answer email address thing I just showed you, we’re not unique in giving you the ability to parameterize a SQL query and let someone run it over and over again. You can use tools, like, Retool to build a simple UI that hits a database and does that thing. You can use tools like [unintelligible 00:41:08] to have saved queries that people can execute over and over again.

And so, I remember, like, people started using the Airplane to do that kind of stuff, and then we added in the dedicated SQL and REST builders, the one I just demoed to you so that you don’t even have to write a script to do simple queries and stuff like that. And I remember asking people, like, “Why would you use Airplane for this? Why not use one of the other 50 other tools out there that are much more mature, much further along?” And they’re like, “Really, it’s just really easy to use Airplane.”

Beyang: [laugh].

Ravi: Like that was the whole idea. Like, the idea was like, you know, if you’re using any of these other tools, you have to configure a lot of stuff, or have to build UIs, or do all kinds of stuff that you don’t really care about. Whereas, like, for Airplane, we’ve surgically asked you to just concentrate on the thing that matters, the only thing that you, as the developer, need to bring to us because we can’t figure it out for you. We don’t know what query needs to get executed. You know that.

But all the rest of the stuff, the UI, the permissions and notifications, all that kind of stuff, we can just make some fairly intelligent assumptions about what that should look like. Like, it’s a webform to execute a function at the end of the day. We don’t ask you to drag-and-drop form fields on the page. We just say, “Hey, this is probably what this should look like.” And everyone’s just, like, “Yep, that’s fine.”

Beyang: That’s brilliant.

Ravi: And so, I think that was the idea was just, like, this super-clean separation of concerns of, like, “Hey, you care about the back-end logic. We’ll worry about everything else.” And that just appealed to people. And, like, the fact that it would take 30 seconds to build an Airplane, and maybe ten minutes to do it in another tool, that difference was actually pretty huge for people. Because the nature of these things, it’s stuff they don’t want to be worrying about, right?

Like, as a developer, you’re like, “I don’t want to do this thing over and over again. I want it off my plate as soon as possible.” And Airplane sort of fulfills that for you. It’s like, “Hey, we’ll get out of your way. And we’ll let you automate this thing. You send the link to your other teammate who needs to run this thing and then you’re done with it.”

Beyang: Especially if it’s like an internal app or tool, like, I don’t really care about the placement of the frickin’, you know, template fields. I just want, like, a form that someone can figure out it doesn’t have to be pretty, although I’m sure it, you know, looks reasonable in Airplane because you make reasonable assumptions. But, like, I don’t need to, like, design that thing. I just want something that someone can, like, type text into and then click a button.

Ravi: Right. Yeah.

Beyang: Okay, interesting. I think this, like, kind of brings up another interesting topic, which is, yeah, you started as a developer tool. Airplane still, I think, describes itself as a development tool, but I hear it increasingly mentioned in conjunction with, like, low-code or no-code tools like Retool. So—and maybe that’s, like, a common theme, too, because, like, you mentioned with Heap, too, that you start developer first—

Ravi: Yes.

Beyang: And you eventually became this, kind of like, low-code analytic solution. So, do you see Airplane kind of evolving into this, like, general purpose, like, low-code app builder, or is the DNA of the product and the company still, like, strictly a developer tool? Or maybe the boundaries are, like, getting blurred here?

Ravi: Yeah. I would say. So, I do think the boundary getting blurred all over the map, but I’d say for Airplane specifically, more so than anything else in this space, whatever this space even is, we think of ourselves as very, very much a developer tool, first and foremost. And to clarify, I mean, like, the people who build stuff in Airplane or developers, the people—the end-users of Airplane Tasks and Runbooks are often non-developers, more often than not. But we do not intend for non-developers to build things in Airplane.

Occasionally it happens, but I’d say at least 97% of everybody building Tasks and Runbooks in Airplane is a software engineer. And so, you mentioned, like, we get lumped in with the low-code, no-code stuff, I think, like—well, I think every piece of software is a low-code tools, in some sense, right, but—because you [couldn’t 00:44:46] code otherwise, but—

Beyang: Sure. [laugh].

Ravi: —aside from being pedantic, I would—

Beyang: That’s what—yeah. [laugh].

Ravi: Say that, like, I think the reason we get lumped in there is because a lot of people see the problem—so the problem fundamentally is that you have a small set of people in a company—maybe it’s the whole entity, maybe it’s even a subset of the entity—who have access to an operation, right? They have access to a thing that only they can do, and more people in the company need access. Sometimes those more people or other engineers, but usually it’s not engineers who need access to that thing. And so, a lot of other companies look at that problem and say, “How do we solve this issue? What we should do is we should build tools for the non-engineers so they can solve the issue themselves.”

And that’s a reasonable impulse, but our thing is, we’re, like, “Hey, a lot of the things that people need access to write against production data.” And, like, no matter how savvy your solutions eng team is, if they’re not part of the core software development workflow within your company, you’re going to be really reticent to give them write access to a production database, even if they’re like—like at Heap, everybody on our solutions eng team was very savvy, and very talented, and could easily have had write access to it. It’s just that they don’t understand, like—this—they don’t—they’re not in the day-to-day of the eng team so they don’t know, you know, exactly what the implications are of doing a—

Beyang: There a lot of pitfalls and [foot guns 00:45:57]. Like, things that you don’t realize… yeah.

Ravi: Right. And so, you want things that are going to touch production data and write against production data to be governed the same way you want the rest of your code governed. You want it to go through version control, you want to go through code review, all the rest of that stuff. And so, I didn’t really demonstrate this in the demo, but, like, everything in Airplane is governable via code. You can write scripts, put them in your codebase, but a YAML that represents a Task definition.

And that’s sort of the way we recommend you use it actually. The UI stuff [crosstalk 00:46:25] is easy to get started onto, but anyone using Airplane at scale should be governing it the way they govern the rest of their codebase. And so, that idea is very core to Airplane, that this is a developer tool because it requires—like, the valuable things about Airplane are of the ability to write against production data. And most companies really are only really going to have their eng team have the ability to do that. So, that’s kind of a hard, sort of, core requirement of it.

With Heap I think it was, we drifted over time because, like, the core end users of analytics ended up being a little bit different than what we thought they were, but I think we’ve seen enough data and we’re far enough along an Airplane where I think we see that there’s a—at least for a lot of companies that the engineering team is the right people to be selling to. There might be other companies out there which are better fits for some other approaches. But yeah.

Beyang: Got it. So, do you ever foresee a world in which, like, a non-engineer would use Airplane to write some piece of code? Say, you know, someone on the sales team wants to write some logic to, I don’t know, analyze some piece of the funnel, like, analyze the conversion rate of a particular set? Maybe that’s more of a Heap [laugh] use case, actually. Like, conceivably someone on sales and marketing or some other function might want to write some code that, you know, pulls some data and—or enacts some action. Is that something that, like, you think might occur in the future? Do you think it’ll strictly be, like, engineering teams are still, like, writing scripts and making apps for other people to run?

Ravi: Yeah. So, I think this is, like, another kind of—possibly, but, like—the answer is, like, possibly, but I think it’ll still be eng teams. And the reason I say that is because—so when you’re describing does happen, but I tend to see situations where non-engineers have, like, write access to company data is usually data that lives in third-party tools. So, there’s a lot of systems—there’s a lot of situations where, like, oh, so when the sales team has access to CRM data and they want to, like, have—you know, every time when the lead comes in, they want to have a Slack notification go out, or something like that. If what you’re doing is you’re stitching together third-party APIs, you can actually give a lot more freedom to people because, like, the downside is not as high, right?

Like, if somebody messes something up there, it’s not that big of a deal at the end of the day to, like, clean up CRM data or something like that. It’s not prod, right? Like, it’s not production data. And so, I think, like, that’s where tools like like Zapier and all that kind of stuff come in. And so theoretically, you could use Airplane to do the same things that those tools do, but they’re much more optimized for that use case, and they have, like, built their 5000 API integrations and all that kind of stuff that we’re just not going to do.

Where we see our sort of core differentiation and core, like, unmet value that were—like, unmet need that we’re solving is really around allowing you to, like, broaden write access to production data, like, core production data, in a way that safe, easy.

Beyang: Got it. Makes sense. And so, you’re focused on, you know, the engineer as your core user.

Ravi: Right.

Beyang: In terms of, like, sweet spot customer or company that will use Airplane, is it, like, any company that has engineers, that runs code in production, or are they’re like particular sectors or, you know, company sizes, where you’re particularly, like, resonant with [unintelligible 00:49:35]?

Ravi: Yeah. I would say in the long-term, yeah, we want every software team that—every software team backing a cloud product to be able to use Airplane. If you’re building on-premise software, the way Airplane works doesn’t make a whole lot of sense. But yeah, if you’re building a cloud product, and that doesn’t necessarily mean a SaaS company, it could mean, like, the Chase Bank mobile app, right? Like, anytime you’re, sort of like, responsible for a piece of cloud software that needs to have these sorts of one-off maintenance requests happening and on-call Runbooks being executed all that kind of stuff I think Airplane could fit.

That being said, like, where we’ve done really well so far in the sort of short lifespan of the company today, it’s mostly small to midsize SaaS companies, FinTech companies, marketplace companies, healthcare companies. Basically companies that are, let’s call it between—like, less than maybe 500 employees, usually. So, they’re small enough where they haven’t necessarily built up a ton of internal tooling yet, they’re small enough where they’re still iterating super fast and the internal tooling needs are evolving really quickly. And so, as a result—and if they’re fast growth then, like, that needs are even more acute. So, you know, if you take—like, you’re some 100-person, SaaS company with a 15-person solutions engineering team, and a 10-person sales team, or whatever, and 20-person eng team, and there’s, like, a massive backlog of product to build, and you have engineers just, like, one-off helping with every customer onboarding, and with, like, answering random tickets and stuff like that, that’s, like, the sweet spot for Airplane, right, because we can just say, like, “Hey, you can get all this off your plate as the eng team, empower your customer-facing teams, and, you know, accelerate your roadmap, potentially.”

Beyang: Cool. What’s kind of next on the roadmap? Anything you’re looking forward to in the upcoming months and year?

Ravi: Yeah. So, there’s quite a few interesting things we’re working on. I mentioned briefly that the way we want people to use Airplane is the way that they—like, as similar to there are typical engineering workflows as possible. So, writing a Python script locally, and testing it out locally, deploying it to Airplane, and then version-controlling it, and testing it, and all that kind of stuff. Like, that’s kind of the way we want people to use Airplane.

Where Airplane is today versus where we want it to be, there’s still a bit of a gap there, so we’re doing a lot of iteration on the developer workflow. And we want to get to the point where, like, matches kind of what you’re used to, from really, like, best-in-class developer tools, like, Versel or something like that, just make it really, really simple and, like, not having to introduce a whole lot of new concepts into how to use the products. But even today, it’s pretty clean and that’s what people love about the product is just the developer experience. So, trying to get it from good to great, really. So, that’s one big area of investment.

Another big thing is, like, we’re really trying to deepen the set of things that are possible with Airplane. So, I very quickly showed you, kind of like, what we call a Task in Airplane, which is, kind of like, a single business function that needs to get executed. And then I mentioned, like, you can do what’s called a Runbook, which you can stitch multiple Tasks together. And so, you can do, like, pretty simple linear flows, of, like, linear composition of, like, five or six things in a row. There’s even some conditional logic you can insert into there, but we’re going to greatly expand the set of things as possible there.

So, for example, we’ll have the concept of loops, where you can say, “Hey, let’s take the output of this SQL query—like, all 100 rows in this output—and then execute this Task 100 times for each row in that output or something like that.” So, you’ll be able to do that. We’ll have, like, parallelization so you can run multiple things at the same. Time, we’ll have, like, the idea of, like, more complex, like, human-in-the-loop logic, so being able to say, “Hey, this is a ten-step process. These first four steps can be executed by anybody, but this fifth step is really sensitive. It can only be done by somebody on the X, Y, Z team.” And so, there could be a handoff concept happening in the middle of it. So, that kind of stuff as well.

Beyang: It sounds like that’s even on the track toward constructing these, like, general-purpose data pipelines of sorts because, like, you could have one thing that emits, like, a bunch of things, and then something else that comes along and consumes the output of that and, like, do you foresee that as that being a potential evolution here?

Ravi: Potentially. And even today, people use Airplane for really simple data pipeline type things. We don’t see ourselves as, like, an Airflow competitor or something of that nature.

Beyang: Okay.

Ravi: So, I think, like, there’s—when you’re doing really sophisticated things, like, a high level of scale, I think it’s better to just use, like, Airflow, or Luigi, or whatever, for that kind of stuff. But, like, there’s a—the thing we see with Airplane is like, a lot of people using Airplane, like, really simple stuff. Like, really simple pipelines that, like, honestly don’t require a lot of the complexity or configurability of something like an Airflow. And so, in those situations, like, yeah, we do intend Airplane to be, like, a simpler replacement for stuff like that.

Beyang: Okay, got it. Got it. Do you have any plans, like, investing more into that development environment—or sorry, not the—you don’t have a development environment, but, like, the editor that you showed off in the GUI? You mentioned, like, the preferred way of using Airplane right now is you write the script in whatever editor environment you have, and then you upload and, like, Airplane is strictly a runtime, but I feel like when you’re doing that demo, it’s almost, like, a short leap to—you already have autocomplete you already have syntax highlighting. You know, another thing that you see with a lot of these new, kind of, cloud-based programming tools is a developer environment of some sort. Like, any plans to do that, or do you think you’ll stick to just, you know, providing the runtime and not really getting into the development side at all?

Ravi: Yeah, so in terms of, like, the development environment, honestly, we’re of two minds on it. I think right now, I think we’re more likely to build, like, a VS Code plugin than we are to, like, build, like, a full-fledged in-browser, IDE or whatever you want to call it. Though, I think, like, it’s kind of—when I say we’re of two minds, like, on one hand, we have this idea of what Airplane—of how you should use Airplane, like, this sort of like, quote-unquote, “Proper,” way to do it, but there is friction with sort of like setting up your local dev environment to be Airplane compatible. And so, the in-browser stuff is, like, the cleanest onboarding flow, right? It’s, like, all in one place, you don’t have to, like, go do a bunch of stuff with your CLI and fiddle with that.

And so, I think, like, probably will do that as well, at some point; it’s just, like, a question of prioritization. And so, like, I think, like, making these, sort of like, local dev experience better and better and better gets you, like is the thing that drives more expansion and retention of Airplane. Like, it’s the thing that makes sure that Airplane works really well at scale in a company and that it’s easy to onboard new developers onto and all that kind of stuff. But it’s not the thing that, like, delivers that magic aha moment as efficiently as possible, which the in-browser stuff does better. So, like, you know, you kind of have to have both, in some sense.

Like, yeah, I mentioned Versel earlier as a tool I admire. When you first sign up for Versel, like, it’s actually all in-browser, like, the way they get you up and running with the products. But then, like, you really have to use a client at some point to… use it, sort of, x scale in a real organization. So, we’ll strike some balance there, I think.

Beyang: Interesting. Interesting. Are there any users, like, asking for features like that, or just, like, other features that, like, don’t quite fit into—because this is, like, a constant tension, I feel with a lot of companies, especially ones that are early. It’s like, you come to the table with, like, some preconception of how your product ought to be used, but then, you know, your early users, especially if you have good ones, they use it in all sorts of creative ways that you don’t anticipate. Are they’re, like, different camps of users right now that you’re trying to satisfy? Or is it more or less, you know, like that, you know… they don’t want the development environment, they just want the kind of simple runtimes or really simple actions and that’s the path forward.

Ravi: Yeah. I mean, people are asking for all the above. I would say, like—and all of it, I think does fit on the path of things that we want to build. I would say, like, the places where people try to push the product where we’re actually kind of not necessarily trying to go there, I alluded to earlier, we’re not trying to be Airflow, right? We’re not trying to get super complicated bespoke data pipelining workflows.

I think, like, it’s—or, like, for another example, we’re not necessarily trying to allow people to build, like, super pixel-perfect internal workflows. Like, you know, for most companies are, like, “Hey, this is some random internal tool I use it to, like, make it quickly and move on.” But for a small subset of companies are, like, “Actually, this internal tool is really important. Like, this internal tool needs to—you know, is getting run 50,000 times a day by a team of a bazillion people and I need to make sure that it’s really, really, like, done in a way that can’t have any deviation or error or anything like that.” And so, to make sure, like, it’s perfect, like, if that’s what you’re trying to do, like, you should probably just write it in pure software or use some open-source framework that’s more extensible or something like that.

Because with Airplane, like, we’re really optimized around speed and simplicity. Like, we’re going for the, for that long tail of stuff in your organization that you don’t want to build into your product, that you don’t want to write, like, code from the ground up for, that you want to spend as little time on as possible. And so that’s, kind of like, the niche. But, like, inevitably, when you’ve started using Airplane, you have 50 Tasks built into it, you’re going to want to push the boundaries of what it’s capable of, and you’re going to want to say, like, “Hey—” like, [Bobby Blass 00:59:03]—like, “Hey, can I, like, invoke an Airplane Task through an API and then have it be sort of like an end-user facing thing so our users can, like, hit a button that [crosstalk 00:59:11] Airplane task.” And I’m like, “You can if you really want to, but that’s not what we’re trying to do.” We’re not supposed to your application back-end, right? Like, we’re for internal stuff, right? And that’s, kind of like, the directions in which people try to push the product that aren’t necessarily where we’re trying to go.

Beyang: Yeah. That’s fascinating because that’s almost, like… this thing was built for things that you didn’t want to put in the product; now people are trying to build parts of their product and on top of—

Ravi: Yeah. And they never start there, right? They start with the stuff that it’s intended for, I mean, that’s why they signed up for it; that’s the marketing message that resonated. But then they’ve put, like, 20 things in there, like, and they’re like, “Well, but maybe I could do this more other thing in here.” Right?

Beyang: And the functionality is already there. Why, you know, like—

Ravi: Exactly. Yeah.

Beyang: Write it—some—yeah. Yeah, I know how that goes. Cool. So, we’re almost at the end of the hour here. Thanks again so much for taking the time. One last question. If folks are listening to this and want to check out Airplane, what should they do?

Ravi: Yeah, so we’re a self-serve product with a free tier, so—pretty generous free tier; we can do quite a bit. So, you can go to airplane.dev—D-E-V—and just sign up for a free account. You can also email me personally, [email protected]—R-A-V-I at airplane.dev.

Beyang: We’ll drop a link in the [show notes 01:00:29].

Ravi: I’m always happy to chat and, you know, go through a demo, answer any questions you have, all that kind of stuff.

Beyang: Cool. Awesome. Well, my guest today has been Ravi Parikh. Ravi, thanks for coming on the show.

Ravi: Likewise, thank you so much for having me on. It’s been a lot of fun.