Software Huddle - Faster CI/CD Builds + Building a Developer Tools Company with Kyle Galbraith

Episode Date: July 11, 2024

In this episode, Kyle Galbraith tells us about his company, Depot.dev, which is a way to make Docker builds and GitHub action runners complete much faster with basically no changes to your build step. Depot is growing like crazy and just surpassed *one million* builds per month. We looked at how he found the idea for Depot and some of the technology underlying the service. Kyle also shares a ton of wisdom about building a company and specifically a developer tools company. This includes his experience in YC (including how hard he worked on his YC application) and the importance of having "model companies" that are a few steps ahead of you in the process. We talk about how the funding market has change and how he thinks about hiring, fundraising, and profitability. His advice on company building and the focus on what's important is super helpful to those in a similar position.

I think everybody wants to build like a highly available resilience system that's secure. And so we have this like a knack of looking to those that are ahead of us. So like the engineering teams that we want to try to like model ourselves after. So like the Netflix's, the Amazon's, the Google's. And we read about the technologies that they're using and they're like, oh, like to be that we need to be using those technologies as well. Becoming a founder now, it's like my opinion is almost the exact opposite. Like you need to go use the services and technologies that like get you to the next step because you don't know what the answer, like you don't know the answer to the next question yet. So like just get to the next question

and use the thing that gets you there the fastest. So if that's like running a stateful EC2 instance, that's just running one Docker container, like have at it. Don't go solve problems until you actually have them. What does depots infrastructure look like behind the scenes? Hey, folks, this is Alex. Today we have on Kyle Galbraith, who he's the founder of Depot.dev, which is just a way to make your Docker builds, your GitHub action runners just run significantly

faster, basically with no changes to your application, right? So super fascinating technical stuff there, but I also really loved our conversation just about being a founder and especially about being a founder of a dev tools company. I think he had a lot of interesting stuff to talk about there around marketing.

You know, they went through YC around that experience, around profitability and what you're building and all that sort of stuff. I thought it was super interesting. I've known Kyle for a while and it it's been fun to just watch his trajectory, and it looks like Depot's really taken off. So if you have any comments, suggestions, any of that stuff, feel free to reach out to me or Sean.

If you want people to be on the show, let us know. With that, let's get to the show. Kyle, welcome to the show. Hey, thanks for having me. Absolutely. So you and I crossed paths a while ago now. And really, like, in the serverless space, we're both sort of doing stuff there. And that's how I got to know you.

And then at some point, you sort of switched paths and moved over, like, more to the container side and built this real cool company around, you know, faster container image building and things like that. So maybe tell us about you, tell us about Depot, and what will we talk about today? Yeah, so my name is Kyle Galbraith. I'm from Portland, Oregon. Originally moved to the south of France back in October 2022. Pretty much spent my entire career inside of startups, working as a software engineer.

Eventually became the cloud infrastructure person at numerous companies. Pretty much spent my entire career inside of startups, working as a software engineer, eventually became like the cloud infrastructure person at numerous companies. And Jacob and I first met at a nonprofit called Thorn. I don't remember the dates exactly, but Jacob and I were brought in as effectively product software engineers, working on three different products. Thorne was a little bit of a special nonprofit focused on a very important problem inside of the dark web. And so we're essentially packaging up applications and services and deploying them into government facilities. So we got intimately familiar with what it looks like to run Kubernetes clusters on-prem inside of aircraft installations.

We got intimately familiar with packaging up complex applications and services into Docker containers and just kind of became this de facto platform team at Thorne. Jacob and I eventually both left there together and joined a database startup called Aero Software at the time that was really building, hopefully like a different take on the observability elastic search space. And we were brought in to to build their platform as a service offering. That meant everything, nuts and bolts from the ground up. Lots of Kubernetes, lots of Docker containers, lots of CI CD pipelines. It was really an era about, I want to say a year, year and a half in, that we were essentially packaging up

five or six different Rust microservices that made up the database technology into like one big home chart. And each build of those containers inside of something like GitHub Actions was taking like 40 plus minutes. And so we just had this like, it's kind of like the perfect storm

as a founder or, like, as an engineer trying to become a founder. You're like, this problem sucks. I'm going to go solve this problem for myself. And so we just had this idea of what if we took BuildKit, put it up on CloudVMs and attach DBS volumes to it.

And we were, like, operating off of this observation that Docker layer cache is like tens of gigabytes and even larger nowadays when you start talking about like AI and LLMs and things like that. And just the act of saving and loading that layer cache inside of a managed GitHub actions runner pretty much negated all performance gains of using the cache in general. Like, that's how bad the networks were. And so we built a prototype that was essentially that.

We launched BuildKit instances connected to them at that point of, like, a very rudimentary, I'll call it deep OCLI, is really like a bash script. And we didn't,'t like the hypothesis was by persisting the layer cache dbs volumes we probably make those twice as fast because it's just like instantly available just like how it is on your local machine and then uh that initial prototype didn't make the builds twice as fast and made them five times faster and that was like our first moment of oh wow like this could be something um and really like from

there i would love to say like that was like the strike of imagination of like oh this could become a licey company um and like we'll hire people and like we'll focus on this but like that idea that was even then like that wasn't a thing um and really uh that was i think that was january 2022 i want to say um and so we kind of just like set this goal for ourselves on the nights and weekends, like, all right, by May, let's have like a beta of this like end to end that we could like turn over to people. And so we built that, we launched that in like a beta mode and we were also doing some like contracting stuff in the background,

reached out to like some folks in our network or like hey like do you want to try this thing out like uh this makes your builds faster great if it doesn't like sorry i wasted your time essentially and we took the first like person that tried that they had like 15 minute builds inside of Google Cloud Build. It's like some complex like PHP app inside of a Docker container. And we took their build to less than a minute. Wow. And that was like at this point, to give everybody like context,

at this point, like Depot v uh in that beta mode was purely a slightly optimized version of builds kit and ebs volumes and a cli like at that point we hadn't even introduced like the concept of multi-platform image builds and native image builds and things like that and so like to go from 15 minutes to less than a minute with what we consider like a prototype that was when depot that was like when it grew its first leg so to speak yeah yeah and then so was this mostly a problem like at this point mostly a problem for cicd like maybe you wouldn't even notice it locally because you like your docker cache you know you're showing at least some docker cache locally and then but then when you push it to cicd it's a mess or was it even a problem

for for local builds it was primarily cicd uh at that point because most people uh when they build a docker image locally they're like okay like the first one sucks because uh i don't have any caching. But then inside of CI, CD, you don't have your existing cache. You have to save and load it over networks. And that comes with a massive set of limitations that vary based on whatever CI provider you're tied to. But for example, with GitHub Actions, you have 10 gigabytes of cache storage which is like not enough when you're talking about a docker layer cache um

and then like you couple on top of that that like uh it's under provisioned hardware under provisioned networks like it just slows everything down yep yep. Yep. And like, was this a pretty, like is almost everyone that's building with Docker and especially on CICD experiencing this problem or does it require like either applications of significant size or complexity to like when you start to see this sort of thing? I would say, I would say 99% of people are experiencing this problem. The 1% are the people that have gone to the great lengths

of optimizing their Dockerfile to explicitly avoid this problem or running their own version, their own idea of Depot internally. So like running a stateful EC2 instance with EBS volumes or name your cloud provider, EC2 is just an example. And so they're already married to that idea so like to give you an example of the one percent i was talking to somebody that was like yeah i have a i have like a 64 core ec2 instance that's just always running around the clock and i like ssh into it and i get clone it and i run a build and then publish my binaries and push my registry from that machine.

And it's like, cool, like I may or may not agree with your process. But like that is a solution. Most people aren't doing that or like they want to get out of the business of doing that. That comes with such a massive amount of overhead and security blast radius that a lot of people don't want to live in that world. Tell me about the security blast radius. What should I be looking out for if I'm doing

that myself? Or what am I not even thinking about? Yeah, I mean, it's just like anytime you're running a VM, you have to keep the ami patch you have to make sure like uh it doesn't have ssh access it doesn't have egress out to malicious things you have to run guard duty over the top of it make sure like nobody's going in there and like adding malicious app registries things like that there's so much

uh it sounds so simple on paper because you're just like oh i'm just going to run an ec2 and since it's going to run my ci everything will be gravy but uh i think what we're learning in the ecosystem at large is ci is probably, if you want to attack something, I attack it at the CI level because that will just propagate out everywhere. Everywhere. Yeah, that's interesting. Okay, so tell me a little bit about architecture,

what you all are doing. I assume you don't just have a 64-core instance sitting there ready to run build so like what's it look like on the depot side um you know when a build gets kicked off yeah so on the depot side i would say we call this our provisioning system i would say we're on v4 of our provisioning system nowadays so this is the fourth iteration of it. Um, as I just really, what we do is we've created our own orchestration system. So when you run Devo builds, uh, inside of the Devo CLI, we're wrapping BuildX as a library. Um, so we're doing all of the handshakes and hold on. What's, what's BuildX? So BuildX is the CLI that

talks to a BuildKit instance. So you have a BuildKit instance running over on a server. BuildX is the communication channel at the CLI level that connects to it, streams a Docker image build over to BuildKit, and then BuildKit executes it from

there. And so Depot Build essentially does that handshake, tells our API like, hey, I need a build kit instance. Also tells our API which platforms you want to build for. So if you want to build just for Intel, we'll launch you an Intel machine. If you want to build just for ARM,

we'll launch you an ARM machine. Or you can do a multi-platform build where you ask for an image that can run on both. And in that scenario, we launch both on Intel and ARM machine. The infrastructure behind that launching of one is where a large chunk of our optimization has come in. So launching an EC2 instance cold, as most people know, not very fast, 30 to 45 seconds in the best case to admit it in other scenarios. And so essentially what we do is we pull machines behind the scenes.

So we have essentially created, I wish Amazon would build this feature with their warming pools functionality, but I digress. We essentially have a stopped pool of machines that we have pre-configured and pre-optimized to boot BuildKit as fast as possible so build comes in we can launch a build kit instance connect to it and start running your image builds within three to five seconds that's bananas like y'all had a great i think it was jacob that had a great blog post on this recently on just like how you you sped up that ec2 boot time and and stuff for you like you're saying three to five seconds it's usually going what what was you know initial if i just if i just say you know create instance or whatever like that on on normal ec2 what's that usually look like for folks usually it looks between 30 and 45 seconds but i think there's there's a lot of great blog posts out there about like the basic things around

like how to optimize that ec2 instance so like check the init config remove all of the like installation of things that you don't actually need inside of the emi um so like we covered all of those bases and i think at that point we got it to i'm gonna say like 12 to 15 seconds um which is like doable but uh one of the like cornerstones to depot that we talk about quite frequently is we want to be the fastest to build anything uh like that is our objective so like if there is seconds to save there we're going to go find how to save those seconds. And so that led us to effectively, when you boot an EC2 instance, an AMI is streamed from what is effectively like S3 and blob storage. And so what we can actually do is if you start an EC2 instance

with an EVS volume, you can force EVS to read the entire EMI so that you essentially propagate the EMI to all of the blocks on the EVS volume. And then you stop it. And so we stop it because we don't want to pay for compute that we're not using. And then when we restart it it it's just everything's freshly loaded right onto the ebs volume and that's how we went from like the 12 to 15 seconds into the sub five seconds yep okay and then so you're talking about storing this like docker cache on an ebs instance so if i create a project in depot are you basically like creating an ebs volume and that's gonna like whenever i spin up a build you're attaching that volume to my to my instance and then storing the results and and and you know

removing it from a an ec2 instance so that's effectively what v0 of depot was um that's not uh the current version of depot so instead of using ebs uh so we use ebs with like github action runners with the depot managed github action runners and that's how we like propagate the github action emi down um but with docker image builds we've switched away from using ebs and we actually use uh seph volumes so our cache architecture is actually a Ceph storage cluster. And the reason for that is because we were able to 12x the throughput because Ceph uses instance storage. So it's effectively like full-blown real NVMe SSDs. So we run that cluster.

But all the rest of what you just described is exactly the same. So we essentially treat Ceph volumes just like you would an EBS volume. Yep. Yep. Okay. Wow, that's super cool. You talked a little bit about your background. Were you always sort of an infrastructure engineer when you joined Thorne? Or did you, as you were assigned to the platform team or started working on that, you just got deeper and deeper in this, but you used to stack or like, I guess, what's your what's your story there?

Yeah. So my story is like I actually started in QA. I started as like a QA engineer while I was in college and I was working for like a legal startup at the time back in Portland and kind of just like made this jump into like full stack software engineer. Lots of front end, lots of backend, a lot of.NET. It's funny to look back on those times because I haven't written.NET in probably 10 years. But I was heavily focused on full-stack engineer. But my CTO and mentor at the time was all in on AWS.

He was AWS everything. But my CTO and mentor at the time was all in on AWS. He was AWS everything. Like the poster child for AWS to make money. He wanted everything to be using an AWS service. And so I just got entrenched in this cloud ecosystem. I remember when Serverless first came came out we switched a bunch of our architecture over to lambda when that came out um and so that just like naturally made me interested in infrastructure like i became fascinated with the ability of like stitching together different

aws services um eventually left that job and did like a short center of consulting and that's when i i expanded my reach to outside of aws so went into like gcp primarily a little bit of azure as well um and then really it was at thorn like i didn't even really like touched containers um or kubernetes for that matter, until I joined Thorn. And that was because... And Jacob had a very similar path to mine. But rather than being AWS cloud-focused, it was very containers, Kubernetes, and on-prem data centers. So he had set up all of the initial infrastructure at Thorne, which was heavily Docker containers and Kubernetes.

And I was just like, oh, I've been wanting to learn this. So this is perfect. Learned it on the job. Came to form very strong opinions about Kubernetes from that job. Tell me that. What are your opinions on Kubernetes? I think Kubernetes

is a lot of complexity for most engineering teams. I would even venture to say, Jacob and I have talked a lot about this in hindsight, looking back at our time at Thorne and Era, which is like, we probably weren't the right scale to be using Kubernetes and things like that. Like those problems could have been solved in other ways. And it just introduces so much complexity and cognitive load to an engineering team

that could be better used elsewhere. And I have like done a lot of like thinking of like why do why do we end up in those scenarios i think it's um i think everybody wants to build like a highly available resilient system that's secure and so we have this like knack of looking to those that are ahead of us so like the engineering teams that we want to try to like model ourselves after so like the netflix's the amazon's or the google's and we read about the technologies that they're using and they're like oh like to be that we need to be using those technologies as well and i think becoming a founder now it's like my opinion is almost the exact opposite like you need to go use the services and technologies that like get you to the next

step because you don't know what the answer like you don't know the answer to the next question yet so like just get to the next question and use the thing that gets you there the fastest. So if that's like running a stateful EC2 instance, that's just running one Docker container, like have at it. Don't go solve problems until you actually have them. Yeah. So what does Depot's infrastructure

look like behind the scenes? So behind the scenes so behind the scenes um we run uh our api is actually ran inside of cloud run um our app runs inside of cloud run as well so we just packed it up a docker container throw it in cloud run we use planet scale behind the scenes uh for our database um and then we essentially have, we've talked about the provisioning system, CC2 instances, self-storage cluster. We use a little bit of Cloudflare

for backing our ephemeral registry, primarily because if we were to run a registry over the top of S3, that would get very expensive very quickly because of egress traffic. So we essentially map and store blobs out of Amazon. So we use R2 for that. And what kind of, like, are those Docker, like, is that part of the Docker layer cache? Or, like, what kind of blobs are those

that you're showing are too yeah so that is effectively uh we have a feature called an ephemeral registry where when you run a depot build we can save your built image uh off into a registry that we then delete after 24 hours um and the use case for this is actually like quite interesting is when we first launched depot people would be like okay like i'm going to build my docker image then i'm going to run some integration tests and then over in this other workflow i'm going to build my docker image again and run some other integration tests and so on and so forth. But like the Docker image is the same for that commit, right? So they're just like essentially like building it once and then like starting up the build kit instance, running a five second build that's fully cached just to like pull the image back down.

And so we introduced the idea of the ephemeral registry to essentially just build it once and then save it in our registry. And then in the other workflows, you can just load it back, you just pull it back. And so what we do there is we essentially save it to ECR initially. And then we replicate the layer bobs over to r2 and then delete the image out of ecr so then when the registry when you ask for that image by that build id we know to check like oh like it's not an ecr cool then it's already been replicated over to r2 interesting do you have a set like have you i guess do you have a sense of like what your egress is from cloudflare and how much that would cost in in s3 um it's a few hundred dollars uh now it would be it would be probably double inside of s3 um just because of the egress pricing.

That was... A formal registry predates Depot GitHub Action Runners. So before we ran GitHub Action Runners, people were just running their own GitHub Action Runners. And so that was very painful for us when they did that workflow because every time they're doing that, it's pulling a 50 gigabyte image out of AWS and sending it to their GitHub Action Runner.

And now most people use Depot's GitHub Action Runners with the Docker Image Build product. we actually have like cut out R2 in that step because it's faster. Because the GitHub action runner is already in the same VPC as the ECR registry. So when you do the Depot pull, we just like reach over to ECR and pull it out. And so like that has no egress at that point. And it is blazing fast. Okay. Okay. Okay. So. Okay. So as I understand Depot,

like I sort of chunk it up into three different things. Let me know if I'm wrong on this. There's like remote Docker container builds, which could be me locally doing some stuff. It could be dev containers. If I'm, if I'm doing that sort of development, it could be my cicd system

so there's like docker builds there's also like the github action runner which is not necessarily a docker build and then there's like the the build api is that is that am i understanding that rightly the three sort of areas those would be the three areas the build api is um effectively an api interface over the docker Docker image build product as it sits today. And that's mostly for people that are running builds for other users. Is that correct? Like rather than like, you know, my dev team, it might be like, hey, I'm actually offering some sort of service for folks. Exactly. It's effectively the platform use case. So a Docker image build is one of the scariest builds that you can do because it requires a root on the system. Everything inside of a Docker world requires root. This is like one of the large advantages to something like Podman. That's one of the reasons why that was a project that gained so much ground. And so effectively, we have a bunch of platform

use cases where people need to build, they need to take their user's code, which is untrusted, right? Like they don't know what's in it. And they need to build a Docker image with that code inside of it. And then they want to turn around and run it inside of Kubernetes or wherever they're running their code. So they can't trust it, essentially. And so with Devo, they just essentially call us via an API. They're like, I want to build.

Here's the build context and the Docker file. We run it on our secure isolated infrastructure on the return them an image so like they don't have to build any of that security hardening in-house like that's already set up with depot yeah can you give me a sense of i guess that maybe just like breakdown of like how much falls into um you know people were actually running depot bake or depot build, something like that, people using GitHub Actions, and then people that are submitting as part of a build API?

How does that sort of break down on your side? Yeah, I would say when it comes to depot build and bake, so like the Docker image build product, that's easily 80% of Depot nowadays. There's some like overlap in there where people use Depot GitHub Action Runners and the Docker Image Build product. But in total, I would say probably 30, 35% use Depot GitHub Action Runners. And then there's like this 20, 25% area

of people using Depot as a build API. Yeah. What are you seeing in the in the ci city market right now like is is github actions like just continue like taking up a giant share of that or like what what do you see in there i think from the depot side like that's definitely what we see github actions is kind of like eating the ci provider lunch uh in a lot of ways. There's other players out there, so Buildkite being one that's gaining a lot of traction inside of the enterprise space because of its self-hosted capabilities.

Then there's, I would say, I see a lot of people trying to get off of CircleCI. I'm not entirely clear as to why, aside from they feel it's too expensive. And a lot of them trying to switch off of CircleCI and to get out of Actions. So those are the top three. And then you just have this long tail

of all of the other ones from... There's still Travis and Jenkins and... Even more... the other ones from there's still travis and jenkins and uh even like more some of them are like you don't realize they even existed uh and so it's like i thought i knew the the space of ci providers and then it's like every three months it's like oh i've never heard of this one yeah yeah do you build integrations for like those long tail ones or you do mostly people just like you know hooking themselves we focus on like the integrations that people ask for so like GitHub actions they definitely ask for a lot of integrations there it was very important for us when we first started depot to make and it's still very important to us nowadays is to make depot like as stupidly easy to try so uh i think like when we first launched depot we were like make your builds five times faster and change a single line of code

and like we try to take that same philosophy and apply it to everything so for example like we have our own depot build push action which is like, we have our own Depot build push action, which is like you literally just swap Docker build push action in your workflow for Depot build. So you change one word and it just works. So we spend a lot of time on the main ones. We're working on a CircleCI orb because that's been a request.

I would say where people usually ask for integrations is OIDC. So we support OIDC token exchanges with any of the CI providers that support that, which is a really... I highly recommend that if you're not using that today and so a CI provider, go use it. Access tokens inside of your CI secrets aren't that great. I think everybody wishes that like CircleCI would have introduced those, introduced that idea before CircleCI had the incident.

But it's something that like I'm starting to ask like more providers. So like any providers that we use, I'm starting to ask like more providers so like any providers that we use i'm starting to ask like hey like you should add this because i don't really want to put this static token inside of my ci yeah interesting okay um you also have depot managed which and i understand it's um i talked to sam lambert from planet scale and he had this idea of like cloud prem right where it's like the cloud, but running some stuff, running it in your own accounts. You have some management around that.

Is that how Depot Managed works? Yep. Depot Managed is effectively the data plane that lives inside of your own AWS account. So you create a sub-account inside of your AWS organization. We have a Terraform module that you run that provisions the depot data plane inside of that account so that like we can deploy to it but like you control the account you control what access uh that count can touch into your other

accounts um and it draws this like nice boundary for people that have that like security and compliance um concern where they need to effectively have full control of their source code um even at a layer cache level right like they don't want anything to leave their domain um and so that model works really well for them. It is heavily inspired by plant scale, actually. We originally were doing like, okay, like Terraform module inside of your main AWS account. And that always felt brittle because it's like anytime we needed to change something, because, well starting today we're a five person team but like up until like last friday we're a three person team so like we move fast on things um and so it always felt like weird like pinging like an infrastructure

person at a company and being like hey can you like bump your module? And so this sub-account grant permission to the sub-account is a nice model where we can still deploy into it. We can offer support services over the top of it. But the customer still has total control of what access they grant that account. Yep, yep. Do you have pretty full access to that sub-account then to go in and build ground?

I would have to go look at, I would have to go look at the permissions. We keep it pretty scoped down into what the data plane actually needs to touch. And we actually use the, there's the IM policy trick where you can essentially like filter by tag. So you can say like, I only want to be able to touch resources

that have this specific tag. And so we use that trick throughout the Terraform module to essentially say like, we have EC2 describe instances, we have EC2 launch instances, things like that. But it's like totally restricted to the VPCs, EC2 instances, the EBS volumes, things like that, that like we have explicitly tagged tagged with that specific connection ID.

So we really scope it down into only the things that we need to touch. Yep. Yep. Do you think this sort of Cloud-prem model, do you think that's going to last for 20 years? Or are we in this transitionary period where some people know some people are cautious they want to touch everything on prem or as they move to the cloud they want a little more control so or do you think like hey that's gonna be something that fintech and banks and all those sorts of things are going to want forever yeah it's a really good question my current opinion is like i think it's going to be a thing that lasts forever. Um, because I think it's a good middle ground between the two extremes.

So like the one extreme is like you use a task, like use Devo out of the box. Like we have the control plane, your data plane resides here. You lean on the fact that like we have SOC 2 compliance, uh, you lean on like our security hardening. Um, but then there's like the other extreme of like, we can't use the cloud. It must be in our data center. And I think like that's, that's where, frankly, like, I think that's where

Kubernetes and things like that, like really shine is like that technology is literally like lift and put anywhere. But it's like a nightmare developer experience, right? It's a nightmare developer experience. It's a nightmare support experience. And so this cloud prem model, uh, essentially like pushes back on both extremes and says like, okay, like let's meet in the middle, um, let's have, uh, effectively like you can work for the AWS or gcp or whoever to like

uh vpc peer to your on-prem and then we use this like central account to have your sas services that can then be highly restricted to talk to certain things inside of your on-prem data center yeah yeah yeah i think the way that aws has made sort of account proliferation within an organization easier has really helped with some of that stuff because like you have just like a much cleaner boundary than just having like one massive account you have to lock down all this iam and all kinds of stuff whereas like in that account boundary is really nice um we're helping restrict that stuff so all. So I want to switch gears a little bit and just talk about like building and marketing and developer tools. I think a lot of folks are

interested in that. And I want to start off with some stats that I saw you publish. These are May stats. So a couple of months old, I'm sure it's grown since then, but you know, 720 builds, 1.8 million build minutes, which would have been, you know, six or 8 million if they weren't using Depot. And you're doing that with three people now now five people i guess like what have you learned about developer marketing or any like hard things you learn advice you'd give people that are building a developer tool and like how to reach people yeah it's a really good question um i think uh june was our best month with Depot. So we did a million builds in a month in June, which was like a mind blowing like experience because for context, like when we first launched Depot,

I think it took, let's say like 18 months to get our first million builds. And now we're doing a million builds a month as of june i mean and that's like that's like 35 up from may too so that's a pretty big uh pretty growth right there too yeah and that's like uh we're now a team of five the two new folks they just started literally yesterday and so like we we've gotten all the way to like doing a million builds a month as a three-person team and so i think like lessons learned like along the way well i think i i'm still constantly learning lessons is that's probably like the first lesson is uh there's no right answer um and there's no wrong answer so just like go try it um and i think i think i've like i i want to say like i've always had that

like uh i've always had like oh i have this idea i'm gonna go try this idea as quickly as possible um but then i got into yc and realized that like i could 10x that like i could 10x that feeling and that sentiment um because a lot of like our yc experience was hey jacob and i have this marketing idea um and we were just like waffle on it like we're just like i don't know like is this the right thing and our yc partners were really good i would say like in general what they're really good at was like smack you like upside your head and be like uh that's like there's a zero percent chance that like that decision is going to kill the company so like you're wasting effort and energy like overthinking it like just go try the thing and see if it works and so i think what like i try to take that into marketing now of like essentially uh

speak my mind and say like what i really think um building a tool like this and like be very transparent and open about like what it is like to be a founder and building a tool. Um, I think, uh, one of the first things that like I learned was like, figure out who you want to like model yourself after, like both at a company level and a founder level. And where I think a follow-up lesson to that

is people also go wrong with that idea. You tell somebody, okay, you're going to build a developer tool company. Who do you want to be like? And people will be like, oh, I want to be like AWS. And it's like, cool, but AWS is doing how many billions of dollars in revenue?

It's good to have that thought exercise and be like, how did AWS get to where it is when they were our size? But I found it more useful when it comes to marketing and being a founder of essentially who's a company in front of me, essentially. Like they're not an AWS yet, but they're 20 steps ahead of me. And like,

how are they approaching it? Because it feels closer to where I am today. Um, and it's much easier to like practice concrete things. Yep. Who is that for you? Uh, I would say like for me,

there's, there's really like three companies so uh postdoc is probably the biggest one um they have found like this perfect balance between talking about their product but staying relentlessly focused on who their user is um and trying as much as possible to get out of their way. So I think like we're always trying to like borrow ideas from them, both from like a marketing standpoint, but also like building a company standpoint. Both the founders at post-hug are always very active,

always open to sharing like what they know um fly io uh is another one i think kurt and the team over there like they've changed the game of what it means to like build a technical marketing yeah motion yeah um they write such high quality content and like it shows like you can tell that it took three months to write this piece of content and they also like don't hide like they don't hide their magic sauce right um they're very open about what they're building and why they're building it i think we try to take that same approach with Depot. And sometimes as a first-time founder, that's not always easy. But I think that's one advantage that I have is I have Jacob in my corner as well.

And he acts like he has a nice counterbalance to that. That's not going to be the thing that tanks the company. And then the third one is, somebody should do a poll on this. I bet Superbase comes up with you, asks this question every single time. And the reason for that is actually quite interesting. Superbase has created a recipe

that literally every developer tool founder would love to replicate. And all of us are trying to replicate the idea of a launch week. And all of us are not coming anywhere close to what Superbase can do. But both the founders at Superbase are also very open. It's very Fly.io-like where they share how that idea came to be. And folks have never read that blog post. it's powered on super bases blog but essentially like the idea of a launch week was born out of super base coming out of yc and they're like oh there's like focusing on this thing for three months and then doing a big splashy thing is like actually a really productive way to

work yeah um and that's effectively how launch weeks were born at super base and so they're just like carrying their yc batch into the future yeah yeah interesting are those all three yc companies i know postdoc and super base are is fly also yc yep fly is also a yc company um and so like i uh i think like applying into yc for us uh i don I think like applying into YC for us, I don't think like this is a story that's really ever been told, but applying into YC for us was pretty much on a whim. We were like, I don't know, maybe we'll get in. Maybe we won't. And like this was before all of the AI hype.

This was before all of the Silicon Valley bank stuff. And the tipping point for us was we had built Depot. We actually had a call with Kurt at Fly to be like, hey, look at this thing that we built. Because the context there is Fly has also learned a lot of the painful lessons around building containers for their platform. And they have a whole bunch of tech that's tried to optimize that.

And his advice was like, this is really cool. You should apply to YC. And so I was like, oh, a YC founder said we should apply to YC. I think we should go apply to YC. One of the other bits of advice I'll give specifically around applying to ycs uh i think jacob and i spent eight hours a day for a solid week uh going over our yc application i think i i answered every question on a yc application probably 20 to 25 times um and I think that's why we got in. Um, like we were very succinct, very clear in every question, like very clear where we want to go.

So then when we had an interview, like it was still as stressful as all get out. It was like the most stressful 10 minutes of my life. But, um, I felt like super prepared. Like I was ready to answer everything. Like they couldn't throw a curveball at me that i wasn't ready to answer um and since that experience i think as a yc founder you always want to like pass it on so like you always want to oh like this would be a great yc company and so i've probably reviewed like a hundred different yc applications uh for like past batches since ours. And I know within like

the first five minutes of reading your YC application, if you've like, if you've poured blood, sweat and tears into it, um, or if you're just like, eh, I don't know, maybe I want to do this. Yep. Yep. Interesting. Are those, does YC reach out to like previous founders and say, Hey, will you help read applications? Or are those people reaching out to you saying, Hey, would you look at my application before I submit it? It's people reaching out to you and they're like, Hey, would you look at my YC application before I submit it?

Because it's effectively the first screen test, right? So. Yeah. And when you, when you read it, do you like, do you tell people advice and do they like the people that haven't spent the time on it do they put the time in or are they just like yeah whatever i would say uh the people that don't put the time in they usually bail out and like they don't take the advice the people that put the time in i try to provide like very constructive like hey

you shouldn't focus on this point. You should focus on your market. You should focus on what makes you unique as a founder. What's really fascinating reviewing YC applications is how frequently founders think that YC wants to hear that you're going to hire people. And YC's advice is actually the polar opposite. And it's like well documented everywhere. Like if you follow Michael Siebel on Twitter, like hiring is the thing that will kill your startup.

If you hire too soon, like you will kill your startup uh if you hire too soon like you will kill your startup um and so many yc applications that are reviewer like oh like we want the 500k or whatever because we want to hire three people i can go to market and sales and marketing and it's like i think i i've like reached a point in like reviewing some of those applications where I just usually add a comment and it's like, you're the founder, this will literally be your job for the foreseeable future. And you don't need to hire people. What's a good answer for what you'd use the 500K for?

Really, you should speak to how you would use the 500k for uh really it's um you should speak to like how you'll use it to find product market fit um or how you'll use it to talk to your customers um so like there's a very famous story about the airbnb founders um this is like i'm paraphrasing the story because the story's documented elsewhere but they essentially like used the money they got to fly from san francisco to new york every week to go work with like their initial set of hosts to like go take photos to go set up the apartments that they were gonna go list on airbnb um and, that's what the money was for. And like, uh, they were living off of like literal ramen, right. And that's where like ramen profitability was born because they needed

to like buy the ramen the next week. Yeah. Yep. That's amazing. So do you, do you think YC meaningfully changed the trajectory of Depot? Oh yeah, definitely. Um, uh um i think if you're a developer tool yc is definitely the thing to consider um and for us like what it didn't like drastically change the product direction like i would say of our yc batch we were one out of maybe 12 companies in our batch that didn't pivot like we went in working on depot as it is today and we came out working on depot as it is today a lot of folks pivot and they start working on other things which comes with its own set of problems but for us it was uh effectively like a great way to get connected with an entire network and community that's like when you talk when a bunch of yc founders get in the same room it's like you you may have never met each other but like

you know the problems that they're going through it's like oh like you're at this stage yeah that that stage sucks like here's what i did um but you'll also have like yc founders that were ahead of you right so like post hog and the fly ios and they're like oh yeah i remember that stage that stage was fun this stage sucks um and so it's just like you have this like a group to lean on to share experience with um and it's also like a great marketing channel. Like that's, um, I don't think people publicly talk about that very often, but when you're a YC founder and a YC backed company, like that carries, that carries weight. Um, because it's a lot like an Ivy league, like getting accepted into an ivy league school in fact like

it's harder to get into yc than an ivy league school uh based on the numbers from the last batch like it was something outrageous like 25 000 plus applications in our batch and they accepted like less than 300 or something so it's like it, it's an acceptance rate. That's really low. Yep. Um, what about fundraising? Like I know you, you raised 1.8 million seed, I believe, like in your ideal world, are you like, Hey, you know, in two years we'll write, raise another round and grow. Or are you like, Hey, 1.8, that's one. I want that to be the last money we ever raise. Or how do you think about fundraising? Yeah, I think I take the YC approach to fundraising, which is raise to 1.8 and go find profitability.

And then you control your own destiny, essentially. So if you can find profitability, you get to decide what you do next. I think fundraising, which not everybody thinks that way. Right. So like, I think Altman was recently quoted of like, I don't care if I burn like $1 billion a year or $5 billion a year. Like, I don't care. I'm building AGI.

Like we're going to change the world. So like, that's a different, like different different problem domain different way of thinking about it um for me it's like my goal is to find profitability and that allows me to control my destiny yep yep how close are you to profitability uh i would say we're we're looking somewhere between next year um and i think like that's uh that's like incredible for the size of team that we are. That's not easy to do, which that's where it allows you to control your destiny. So I think doing things as a small team has advantages. We get to control our burn, keep costs low we get to stay close to

the customer but like definitely comes with a set of disadvantages uh where as a founder i think when we were building depot github action runners the three of us were probably working like 80 hours a week um like around the clock effectively uh which was cool like we built an entire like in a third product in like two and a half weeks but uh i'd rather not like do that again um that was disruptive to my personal life and so there's like when you control your destiny you essentially get to control your burden so you can be, okay, we made however much more money this quarter. That's enough money to hire a person to do this particular task or job. And I think that's the other thing.

That's why coming back to the YC application and I'm going to go hire people, you have no idea who you need to hire yet um i didn't know who we needed to hire uh like we made our first hire right as we came out of yc we hired another uh principal engineer somebody that we've worked with for many years because like we knew we needed somebody to go build even more technically complex, uh, architectures and solutions to different types of problems. And so like we can literally give him a problem and he will go figure it out. Um,

so like that one was very easy, but from that was when we came out of YC. So it was like a year and a half ago now. I didn't know who else we needed to hire until two and a half months ago. Because effectively, what you're doing initially as a DevTool founder is you're like, all right, I'm wearing these 12 hats. Which one of these hats is taking up 95% of my time that is now at a stage where it's at a level of critical that I need to give this to somebody else. Because otherwise, the business is going to suffer because I can't spend my time on the other 11 things I'm supposed to be doing. And so you really have to build a business for 18 months to 2 years

to really get an understanding of, I need this person and this person. And I think that makes hiring a lot easier too. Because you're like, oh, I need this person to do this specific set of tasks or projects. Whereas the 2020, 2021 boom of VC funding was like, we have so much money. I'm just going to hire these people that I think I need in the future. And then you're in this world of you're burning money and trying to find work for these people that you didn't actually need to hire. Yeah, yeah.

And for you, so I saw that y'all hired a developer advocate recently i believe that's one of the first and and that makes sense because i look at i look at your like blog role or your blog page and it's like you have a post every like three or four days which is like pretty amazing pace i imagine like took up a lot of time for you. What's the other role that you hired? Yeah, so we hired another software engineer that's more focused on like the full stack application side of things. So he focuses on the application side. The principal software engineer that we hired over a year ago, he focuses largely on like the build architecture and the build pipeline side of things. And what are the things that we can optimize there or add into the future.

Then Kyle, because he has a great name, that's why I was like, this is a no-brainer. He's coming in as effectively our senior developer advocate. Because as I was just explaining like you were just talking about the the blog index thanks for checking that out thank you for seeing my work there's a lot there I'm impressed yeah you know you know it's like to like have to go write content over and over and over again but um like as I was just explaining like that was starting to take up like 90 95 of my time and there's like a level of quality that i find so important uh in that that it was like either i'm gonna have to like start trimming back on the quality or i'm not gonna be able to go do

the other 11 things and so bringing somebody like kyle in to like work on that is that doesn't even have to be like his full-time job right like because right now it's not my full-time job right like i'm doing 11 other things and so it'll be able to like focus on that put quality into it and then also go try other things out in the wild yeah yeah one last question on like profitability business stuff like you're making a developer tool and specifically a developer tool where you have like infrastructure costs right it's not like a cli or something like you have some serious infrastructure costs like how much how closely do you keep an eye on that how much of your

sort of monthly burn is infrastructure as compared to you know salaries and other things like that? Yeah, it's a really good question. So I watch infrastructure costs weekly, period. It's always something to be watching because you always need to know, when you're building something, people can do arbitrary builds inside of your environment. People can do arbitrary malicious things as well. And so Crypto crypto minders is a great example we have systems to like detect that and shut them down early but there's always people

doing weird things so by watching your costs weekly you can be like oh like why on thursday did this shoot up to 3x what we were spending usually and so it like provides this like check-in point of like going back in time and being like what was the usage like what were people doing and then steering and adjusting from there um in terms of like infrastructure costs compared to like other expenses I'd say it's like the second or third largest expense um which isn't that surprising honestly um like we're in the business of infrastructure we're not running our own hardware we think that comes with like its own set of disadvantages um and there's always optimizations that you can do i think as we're growing as a company and as we're growing as a tool,

what we're learning is like, there's a lot of optimizations that we can do at an infrastructure level. There's also a ton of optimizations that we can do at a software level. And those are just like some of the things that we're really excited to start building because it allows us to effectively like get into the software optimization side of things, which we're kind of already doing with BuildKit today. We're not running just vanilla BuildKit anymore. We've heavily optimized that to our use case.

But as you continue to work in this space, and you start to think about build acceleration as a general problem, instead of just what I will call build compute or build clouds. That's just heavily focused on moving the build off of a developer's laptop. And I think there's still this whole suite of optimizations where code could still be running on a developer's laptop, and it builds near instantly

if we just look at the software from a different angle yeah wow that's super interesting um just a couple more like it's like work life stuff like you mentioned sort of those 80 hour weeks getting github actions going so first of all you mentioned you moved to France. Are your other two, I guess now five of you, is anybody else in France or are they in the U.S. or where are they? No, I'm the only one that's in France. Jacob lives in London. Jacob's lived in London for five or six years now. Jacob's from Texas originally.

I'm from Portland originally. Jacob kind of gave me the expat bug. Yeah. When I first started working with Jacob, he was living in Texas, I think six months later is when he moved to London. Then pretty much the entire time we've worked together,

he's lived in London. When we first started Devo, I don't think people realized this, but for the first year that we were building Depot, so through that beta phase, through that general availability phase, there was a nine-hour time difference between the two of us. So Jacob was in London. I was in Portland.

Jacob did a lot of working until like 4 or 5 o'clock in the morning, his time. So I'm in France. Jacob's in London. I have another folk uh in minnesota um philadelphia and then back in san francisco as well um so we've we've started like filling out the team going west uh for the obvious reason of like time zone um so yeah yep yep um i know like you have a young kid and you mentioned like those just to work like how all-consuming this can be like how how do you think about even like looking back a couple years ago are you like hey i'm so glad i'm doing depot

even though it's like crazy busy like would you recommend a yc startup for folks like how would you recommend people think about that uh i think it's it's really like down to your own personal situation so uh when i first met my wife back in college uh i think like within the first three months like she knew just based on like how i was working as a software engineer always working in startups and how i was always like building side projects like she knew that like someday like someday i was gonna go like build a company like um and it's helpful that like she knew that by observing because i definitely never like explicitly said that uh but i've always known like this is what i wanted to go do so like i've known this from the first software engineering job that i had because i was like i don't know

i was like the sixth or seventh employee at that company and then it got acquired at 150 or 160 people so like i got to see like all of the different like growing pains from six to 150 and then there's so many growing pains after that that i just like got addicted to that culture and like wearing those multiple hats so for me it was like this is what i'm going to do uh and i've always just been looking for like where's my opportunity to go do that. I think for me, I thought, I thought I was going to have to go like the solo founder route.

Honestly, like I always found it hard to like go find that like branded person. I was like just as hungry to go do something. But then I joined Thorn and I met jacob and jacob and i spent a week in dallas like locked in a like police convention conference like material that has like no interest to us but we're just like they're supporting the non-profit and we just like hung out for a week and talked about our lives and talked about like our tech backgrounds talked about like where we want to go and like i pretty much left that and i was like yeah like if i'm gonna start a company like jake but i'm going to

find something wow and pretty much from that point like we were just like i think we worked on like six or seven different ideas that we thought we could like turn into companies before we landed on Depot. Um, and then we landed on Depot and I was like, Oh, like this is the one. Um, and that was kind of like how it went. I think when it comes to going down this path, it's definitely hard being a first timetime dad and a first-time founder at the same time um because it sounds weird to say but it feels like i have two kids that i have to like

feed yeah i have depot like the startup and then i have my son um but as my son's gotten older, it's like really fun and exciting to like talk to him about my work. It's fun and exciting to like have discord calls with Jacob and like, he knows who Jacob is. Like he knows Jacob's like a co-founder to Depot. We have like swag stickers of like Mike Corgi and these are like all over his uh his scooter that he takes to school every morning here in france and so it's like it's hard it definitely comes with challenges i think having an excellent partner and my wife like helps with a lot of like the

logistical challenges but then like having jacob as my partner inside of depot like he understands that like i have a toddler to take care of and i can't work till five o'clock in the morning so he like shoulders the load uh when that's needed yeah man that's cool cool i'd love this um man i hate to cut this off but we gotta i gotta end with some quick fire questions and i'll let you let you get out of here so quick fire questions if you could master one skill you don't have right now what would it be uh delegation i think like delegation is so important as a founder and uh it's still like something that i'm learning every single day yeah yeah is it just like you want to do it yourself and do it your specific way

i think it's just like i struggle to like ask people for help or like i struggle to like give people problems where i don't know the answer because it's like that feels rude and mean like hey like this problem it's here i think we need to fix it it sucks and i have no idea how to fix it. So it feels harsh to do that to people. But I think what I'm learning is that's leadership, essentially. You're hiring these people to go do these things. So just turn them loose on it. You've brought them in with the skill set that they have

like they're more than capable of going and solving those problems that you don't know the solution to yeah yeah what wastes the most time in your day oh that's a good question all the spam emails that you get as a yc founder probably uh there's so many spam emails that you get as a YC founder, probably. There's so many spam emails that you get. Everybody wants to pitch you everything that they're doing. I think the other thing is just with hundreds of customers that we have nowadays as a small team, support can take up so much of your day.

And it's usually not even product bug support. It's educational support. And that can take up... It takes up so much of your day, but in a good way, because you stay so close to the user and the problems that they're facing, and it sparks so many ideas. But that definitely like takes up a chunk of time.

I remember that from, from being at serverless and like, seriously, it takes up so much time, but it's like, honestly the best way to just like stay so close to the ground and understand like what people are actually dealing with, what they're doing and what they wish could happen.

But yeah, you're right. It does take a lot of time uh if you can invest in one company that's not the company you work for has to be a private company what would it be oh that's a good one oh there's so many um well okay so like the greedy side of me is like if i could wind a clock back and go invest into open ai like i'd go do that um but like nobody knew that was like i didn't see that coming um i think post hog is the one that jumps off the page to me because i just love their product. Outside of helping customer support and deleting spam emails, I spend 90% of my day inside of PostDog just monitoring Teebo as a product and a business.

That would probably be definitely near the top. I was wondering if it was going to be one of those three companies you mentioned. Which tool or technology could you not live without? Hmm. That's a good one. Well, Docker, uh,

even, uh, even if I have strong opinions about Docker, the technology, like Depot as a business where they exist today. Um, it's really fun to have Solomon as an angel investor inside of Depot. And here's some of like the early stories of Docker

and then also just like observe the things that they're building at Dagger nowadays um so Docker would be the obvious one but uh aside from the like joking answer I think uh GitHub Copilot has become like fundamental to like my development process nowadays uh it's hard to like look back even three years ago and be like how did i like do this because it's just so good it's so good at like just nailing the this is where i'm heading with this. And yeah, sure, sometimes it's wrong, but I don't ever intend to turn an AI chatbot loose on an entire code base and just go deploy what it's doing. I'm still a software engineer at heart, but it makes me so much more productive.

It's what really opened my eyes to this idea. If we can make developers ridiculously productive inside of the ide if we can make builds ridiculously fast inside of ci and local like we're approaching this world of like near instant like build and development cycles that we'll be able to build like businesses five years from now that used to take 15 years to build and we'll build them in like six months yeah yeah do you i mean i love copilot too do you kick out to like either chat gpt or clod or anything like that ever are you mostly a copilot i'm mostly like i mostly stay inside of copilot uh if I'm looking to write some bespoke algorithm

for scheduling things, I'll usually start with Copilot's chat feature. But that's me. I know a lot of folks on the Depot team, they'll go and ask ChatGPT. Particularly when you're building Depot, you need to understand like the linux kernel at like a super low level for some of the optimizations that we want to do and you'll

get this error back that's like super cryptic and you're like i have no idea what this means and so like usually people like default to like googling it and now what i'm starting to see like in the depot team is like people default to like asking chat gpt or any of the other ai chatbots and they're usually like they're like 90 correct and so like it gives you enough of a lead of like oh it's talking about this thing and then you essentially know like the specific thing to go google right of like oh i need to optimize uh i need to use this type of parameter inside of sef to get this performance xyz yep yeah yeah i find that too like some if you don't know an area well enough it's better to like rather than google first which might have a hit that's like in the direction but might not it's better to like yeah

go to chat gbt and then it's like better point you in the direction of what you mean exactly on that that same note five years from now will people be writing with sorry will there be more people writing code or less oh that's a good one uh i'm gonna say more um i'm gonna go like contrary to the AI is going to replace software engineers. I think AI is going to produce more software engineers and more bad code that needs to be fixed. I don't think it's going to kill jobs. I think it's going to kill jobs i think it's going to create jobs um particularly like in both the tech spaces and creative spaces like i think uh there's this like video floating around of ai is going to like destroy artists and i think uh anybody that like i talk to whether they're tech focused or not tech focus

it's actually making like a real human-made art even more valuable which i think is awesome like i think um i think there's a use case for like ar generated art and things like that but uh i think we also like need to pay great artists good money for their work because the arts is really like that's the culture of the world like tech is not the culture of the world um and so i'm very like i think ai is going to create more jobs and not go and take everybody's job we're not going to have a like terminator situation yeah yeah yeah for sure um well kyle thanks for coming on like it's great to catch up with you and i learned a ton about just like a company building and how to think about some of that stuff so i appreciate you sharing all that stuff uh people want to find

out more about you or depot where should they go yeah so you can check out depot it's uh depot.dev i'm sure we'll drop a link you can follow me on twitter she's kyle galbraith it's my handle on twitter then you can follow me on twitter or on linkedin um you can follow me on linkedin i post a lot of like long form content i'm starting to share more of my like expat story uh because i've spent so much time talking about depot and building a dev tool yeah like there's a whole expat story to me that nobody's ever even heard. Cool. I like that.

So I'll be letting that out. I'll look out for that. But yeah, thanks for coming on. I appreciate it. This was awesome. I love what Depot is doing and best of luck to you all going forward. Awesome.

Thank you. Yeah.