We essentially scaled Depot to over a million in ARR as three people. Things got hectic.
Hi, everyone. You're listening to Scaling Dev Tools. I'm joined today by Kyle from Depot. We talk about life as a founder.
Don't spend, like, three years building a flipping SaaS prototype. Like, it's the dumbest thing you can do. Go build something in a week and then go ask them. Does this solve your problem? The best thing you can do as a founder is get to cash flow breakeven as fast as possible. When you do that, you control your destiny now. You control, like, what's the thing that you wanna do next. There's groups of founders out there that fundraise money, and they're effectively, like, serial fundraisers.
And we talk a lot about pricing and really, really understanding your ICP.
Don't market to developers. Educate developers. Share what you know. Developers appreciate transparency and visibility visibility over everything.
Enjoy the episode. How many people are you at the moment?
Yeah. So Tipos is a team of eight people. Oh, cool.
All engineers or?
Mostly all engineering. We have an account executive that we hired back last summer. But, yeah, the majority of folks is engineering. Depot was actually three people up until July of last year. So it was me, Jacob, and our founding engineer, Chris. And we essentially scaled Depot to just a bit over a million in ARR
Oh, wow.
As three people.
That's great.
And then, yeah, like, things got hectic and crazy. That was a lot of customers to manage with just three peoples. Mhmm. It was approaching levels of, like, we can't all work eighty hours a week every week Yeah.
Without any, like, anyone getting sick or anything.
And stay sane. So we effectively hired more engineering folks, which has been great. I think I like to say I'm the dumbest person that's working on Depot. Of all the people that are building Depot behind the scenes, like, I'm definitely the dumbest one.
Well, that's good. I mean I mean, that means Means
we're doing the right thing. I think the the folks that are behind the scenes, they do an awesome job of executing on different ideas and generating new ideas to try. I think one of the things that's super important as you're building really any startup, but, like, especially a developer tool startup, is you have to stay nimble. Like, you have to be able to move fast, which is ironic because we focus on building faster. So Yeah.
It's kind of, like, ingrained in our DNA. But you can fall victim so quickly to, oh, I just raised a bunch of money. I'm gonna go hire thirty, forty, 50 people, and now, like, you're screwed. Like, you're gonna spend all of your time hiring, all of your time training those people, and not, like, building product and solving problems. And so I think for us, we try to do everything as, like, a super lean and mean team, And it has downsides.
Like, it's a lot of work, but it has a lot of upsides. I think, particularly, I was talking to somebody yesterday. One of the upsides is you have to ruthlessly prioritize, like, ruthlessly prioritize. And so you only work on the most important things, because you only have so many resources to work on it. But, yeah, it's it's a fun way of doing things. It's stressful and tiring, but it always feels like we're always pulling in the same direction, which I think is the most important thing.
Yeah. And how how do you work when there's so kind of few of you, especially even if you go back to, like, when it was
just three of you, like Yeah.
How was it how was it running?
So I think Jacob lives here in London. I live in the South Of France. I'm not everybody else is back in The US. Well, I guess US and Canada. And so when it was just the three of us, it was effectively Jacob and I handling anything like Europe and time zones before us, and then effectively passing off the baton to West Coast and US.
That's still true today, but it's just now we can have, like, a more proper, like, support rotation so that not everybody is on support. We essentially can have, like, okay, like, the sun moves across the globe, there's somebody that's covering these customers over here, and then there's somebody covering The US customers back in The US.
Yeah. And then who's, like, were you were you handling all the kind of, like, growth stuff Mhmm. Yourself?
Yep. Handling all of the growth stuff. So pretty much founder led everything. And that's still that's a little less true today. Like, we have an account executive now, so he spends a lot of his time focusing on outbound sales motions and things like that and handling a lot of the internal, like, legal negotiation for, like, inbound sales and things like that, which is, like, a major help.
But even today, like, there's a lot of founder led things. So, like, founder led marketing, so it's largely Jacob and I. Well, largely me. Jacob does not like being the face of the company so much. He likes being behind the scenes, but when there's an opportunity, he definitely, like, steps up to the plate and does it too. But, yeah, you we lean very heavily into, like, what can we accomplish as founders. And I think we've gotten to where we are today based on that.
Yeah.
I think we're starting to see, like, the problems with that, like, pain points. One of the one of the challenges when you go founder led everything is eventually you have to pass it off to somebody Mhmm. Because it becomes as you go through the as kinda you move through the founder journey, there's, like, what's the thing I should be focusing on and doing? And that changes over time. Like, as the company progresses, as your ICP progresses, maybe you move up market, maybe you have different sales motions, whatever the case might be, your focus changes.
And so one of the problems with, like, founder led things is effectively, like, we hold all of the context. Mhmm. Yep. We know how it got to this point and we hold all of the context. And I think the thing that we're learning at Depot is how do we pass off that context now. Because it sounds simple to be like, oh, like, write it all down. Right? Document it. The reality is is, like, Depot's three years old now. There's three years worth of context Yeah.
Built into every decision, every customer. And so you kinda have to I think the thing that we're leaning into at the moment is whoever we're passing this context off to essentially becomes, like, the third cofounder Yep. For the first six months. Yeah. Like, they're in part of everything, because that's Jacob and I's reminder of, like, oh, this person doesn't have this context.
And so then we give the context and, like, explicitly having them in those calls or whatever it might be reminds us of, oh, like, we need to pass off this context.
Mhmm. Yeah. Scaling DevTools is sponsored by WorkOS. If things start going well, some of your customers are gonna start asking for enterprise features. Things like audit trails, SSO, SCIM provisioning, role based access control.
These things are hard to build, and you could get stuck spending all your time doing that instead of actually making a great dev tool. That's why WorkOS exists. They help you with all of those enterprise features, and they're trusted by OpenAI, Vercel, and Perplexity. And if you use them for user management, you get your first million, yes, million, monthly active users for free. I honestly don't know any dev tools that have a million monthly active users apart from GitHub, maybe.
So that'll get you pretty far.
We use WorkOS to effectively add all of the SSO and SCIM to Depot. It's single handedly, like, one of the best developer experiences I've ever seen for what is, like, a super painful problem if you were to go and try to roll that yourself. So for us, we can effectively offer SSO and SCIM, and it's, like, two clicks of a button, and we don't ever have to think about it. It's, like, one of the best features, that we can add to Depot. It's super affordable, which effectively allows us to, like, break the SSO tax, joke and essentially say, like, you can have SSO and SCIM as, like, an add on onto your monthly plan.
Like, it's no problem. So it really allows smaller startups to essentially offer, like, that enterprise feature, without a huge engineering investment behind it. Like, it's literally you can just use a tool behind the scenes, and our life is exponentially easier.
And then kind of, like, going back to, like, you mentioned that you got to 1,000,000 error without with just having the three of you. Mhmm. What were the biggest things that you did to to kind of be able to do that?
Yeah. Well, it's interesting. Like, when you're thinking about developer tools and particularly, like, building a business around developer tools, developers are probably one of the hardest groups of people Yep. To build a business around. It's and it's not because they don't have problems.
They very much have problems that they want solutions to. But they're not stupid. Like, they they are incredibly brilliant people. And so I think for us, how we manage to scale it deeper to a million ARR is just the three of us is, we built the things that resonated with us as engineers. We built the solutions to the problems that we faced Mhmm.
As, like, platform and DevOps engineers. I mean, that was, like, the origin of Depot. And so then everything that we write, everything that we put out into the world is, like, meant to message to us as engineers, not to us as a CEO and a CTO or whatever. Right? Or some magical Fortune five hundred VP of whatever.
It was, like, to speak directly to engineers, and it's like, hey. Like, your builds suck. Yep. You probably hate dealing with this. Like, let's change one line of code and make your builds faster.
So I think to get to where Depot was last July, it was effectively leaning heavily into, like, what would resonate with us, what's the content that we can put out into the world that's helpful to, like, don't market to developers, educate developers, share what you know. Even to this day, like, everything that we build, it usually follows, like, a pretty pretty predictable pattern is, like, we come up with an idea usually based on a customer asking for something.
And this is for a feature
or It's for a feature or a new product, whatever it might be. Yeah. So a customer asks for something. Sometimes it can be five, six, ten customers asking for similar things and we, like, digest that down into, like, what's the common thread here. And then we go and, like, build that thing based on that understanding of, like, what is the problem that they want a solution to and what do they feel in that problem.
Yeah. And a lot of times, like, we can put up we can put the engineer hat back on and be like, oh, yeah. Like, I can see how this could be a problem. And so then we build the features to that, and then we release it, and we get those customers onboarded onto that. But then we always circle back and we write about, like, here's why we built this thing.
Here's how we built this thing. So while Debo's not, like, an open source company in a lot of ways, Deebo is, like, an open knowledge company. So we effectively, like, anything that we build, we share how we built it and what we're doing behind the scenes. And some people, like, open their eyes at that of, like, I get this question a lot of, why are you, like, worried that your competitors could go build that? Yeah.
And the simple truth is is, like, if they wanna go build that, like, have at it. Like, that's not going to be the thing that makes or breaks the business. Right? What makes depot depot is the people building depot. Yeah. Not necessarily the features that we ship out into the world and how we built them.
Yeah. It's it feels like people want everyone wants to buy from the company that's actually, like, figuring the things out. Yep. Not the company that's copying how the other guys figured it out Yeah. In a sense. And it's like creating that.
Yep. I think that's 100% true. I've never heard it's like said so concretely, but there is this idea of like, when you look at especially the developer tool space, you can look at one particular segment of a developer tool space, and there's probably five, six, maybe 10 companies building in that space. Mhmm. And they're all, like, solving some very similar problems, and they all have some amount of traction in customers.
But eventually, like, one pulls away from the rest. Yeah. And I think it's because of that, where it's like one is actually focused on, like, solving the problems Mhmm. And the others are just trying to, like, chase the business and the market by chasing what the other company is building.
Yeah. Yeah. That's really cool. So you were able to just, like, that you felt like that what what would it look like? Would people would read your content and then reach out to you directly or it was like, how how was how was it going from like, we wrote this piece of content to, you know, we're getting a lot of revenue growth?
Yep. So I think it's effectively, like, putting out multiple pieces of content. So if I was to, like, think back to the early days of Depot, it's, like, putting out multiple pieces of content, focusing on the problems that need to be solved, presenting the solutions in, like, a deeply technical perspective so that engineers are like, oh, this is what's happening behind the scenes. Although, eventually, like, that content makes its way by word-of-mouth throughout the community. Sometimes, like, way back when we were first starting, we ended up on Hacker News.
Actually, like, ironically, I don't think I've ever shared this fact. We ended up on Hacker News, like, the same week we're being interviewed to get into YC.
Oh, really?
Yeah. Okay. Cool. And so that was a hectic week. I also moved to the South Of France, like, that weekend. So I was like, I was managing all of that on, like, the floor of my totally empty house back in Portland.
The wrong way. Felt like Yeah.
Back then, it was like, oh, wow. Like, we're on Hacker News. Like, this is a big deal. Yep. Nowadays, I think, like, we're on Hacker News maybe once or twice a quarter.
Nice.
And it's, like, it's still a big deal. It's, like Yeah. But it's not, it's not the, like, shock
Yeah.
Yeah. That it was back then. But back back to the point, it's, like, putting out content that's technically interesting that effectively would be helpful to anybody, whether you're using Depot or not using Depot. Mhmm. And so I even today, I see Depot content referenced in different GitHub issues.
Like, we rolled out Depot cache a couple months ago, where effectively we bring all of the remote caching capabilities of depot to things like Bazel and Gradle and TurboRepo. And most recently, Go one dot two four introduced remote caching. So we had to go remote cache too. And we wrote, like, a big long blog post of, like, here's how we did it. And, like, I randomly stumbled into, like, some GitHub issues.
I think it was, like, in the Grafana repos or something like that. And, like, they were, like, referencing the blog posts of just talking, like, here's how we could do it. Like, they're not looking not necessarily looking to use Depot, but they're, like, using Depot as, like, oh, like, look at what this company did. Like, look at the this technically interesting thing. And I think scaling Depot to where it is today, that's effectively the bread and butter of Depot is, like, sharing our knowledge, sharing our experience, sharing how we built things.
So that deeply resonates with engineers whether they choose to use depot or not. I think it builds, like, a lot of credibility for us. Yeah.
Actually, I wanted to, I think you guys have the coolest testimonial section I've seen. I think it's, like, the best. Cause I I I heard Adam Frankel talking a lot about, like, testimonials and how to do them right. Mhmm. And he he talks about, like, you don't wanna just say like, this changed my life or like something like very generic that sounds like just like meaningless.
Want Mhmm. You want what he says is you want people to to read it and say, I'll have what they had. And I think you guys do like such an incredible job of that. I don't know if it's like something. So let me find a good one.
Okay. I build three React apps and seven Golang binaries. Golang tests on every single commit, all in about thirty seconds total thanks to some very precise Docker context management, Docker run cache mounts, and incredible caches provided by depot.dev, all in a single depot bake command. And someone else said, I am blown away by depot dev. It's making the breath runtimes pipeline finally usable.
Docker build becomes deeper build in GitHub actions and fast cross platform builds, e g ARAM. Everything is cached aggressively, 10 to 20 times faster build, and they've got, like, actual, like, screenshot of their exact build times. And then there's so many other people talking specifically building it on depot dev, four minutes forty two seconds. Sorry. Building a container on a laptop, ninety minutes forty seconds.
Slow makes me wanna cry. Building on depot dev, four minutes forty two seconds. Speedy makes me smile. It's like, they're really good. People should just go check it out because it's like, I think, really good inspiration for how to do testimonials. Mhmm. And it seems like you do, like, a really good job of, like, explaining what specifically people get.
Yeah. What's interesting about all those testimonials though is, like, they're all organic. Like, we don't ask for any of those things. We probably should, but, like, we don't ask for any of those things. Like, people just share share their results and share, like, what they're building.
And I think that's tying it back to this idea of, like, speaking directly to engineers and, like, helping them solve their problems, helping them get back time, like, literal time in their lives that they're not sitting there and watching the modern day equivalent of paint dry. Yeah. Essentially, like, inspires people to go write those types of things. And I think because with developer tools, like, the proof is in the pudding. Yeah.
So, like, you're sitting on all of the metrics anyways. So, like, tell me exactly how much faster. Yeah. And so I think, like, folks that share testimonials about depot, like, they, put on that engineering hat, and they're effectively like, okay. Like, here's what my build time was before. Here's what my build time is after depot.
Yeah. Yeah. And with build times, it's like, there's the timing. There's like, okay. You go from here to here. Like, do you when you talk about messaging, do you talk about, like, it's the time you save, or is it like what you get from the time that you save?
At the moment, we talk purely about the time that you save. So we effectively take the angle of, like, here's what your build times are today, and here's what your build times could be after you use depot. So with our container build product, like, your builds can be anywhere between twenty and sixty times faster depending on, like, what your container builds are doing. With our GitHub action runners, like, we build tech inside inside of the actual runner so that those are anywhere between three and ten times faster. We have a whole, like, remote caching architecture that backs all of the products, that accelerates GitHub Actions caching by 10 x.
And so it's all about, like, here's the time you can save. Yeah. What we're starting to think more about is what's interesting about build times is build times are a pinch point in multiple environments. So build times can be a pinch point in your local environment, so running like a local Yeah. Build.
And then build times are a pinch point in your CI environment. And that's true with developers and CI. It's going to be true with AI agents in the future. Like Yeah. The build is the pinch point in everything.
And so we're what we're starting to think more about is, like, what is the actual, like, dollars associated to that time saved, which isn't it gets into, like, fuzzy math because you have to get into, like, heuristics of, oh, okay. Like, what's the developer salary? Blah blah blah blah blah. But I think one of the most interesting things of doing that is it's common knowledge that engineers don't just sit around and wait for a build. Yeah.
Right? If a build's going to take an hour, they're going to context switch to something else. Yes. But what is the cost of that context switching is what's really interesting. And so, like, as I started to think about this and we started to, like, run the numbers, you get to an insane amount of wasted, like, developer productivity from context switching because context switching isn't free, especially if you're working on something that's truly deeply technical Definitely.
Like, in the stack. Context switching out of that to go then build something else, it's probably gonna take maybe fifteen, thirty, maybe even forty five minutes to, like, context switch to that other thing. As well as, like, there's a real, like, cost penalty associated to context switching that I think we're starting to, like, think more about in terms of, like, okay, Depot makes your build this much faster. You save this much time, but, like, what do you save in, like, developer productivity, developer happiness? Like, there's a lot of, like, add on effects that happen when you make a build exponentially faster that I think we're just now starting to, like, scratch the surface.
Mhmm. Yeah. Because I guess, like, the people that you're getting initially are probably, like, the early adopters probably, like, they've they can make the leap of themselves. Like Mhmm. I know this is important because I waste time and stuff. And I guess is it, like Yep. As you start to expand it, you have to explain to people, like?
We don't really have to explain to people. What's interesting about Depot I get this question a lot is, like, is it a lot of individual engineers that sign up for Depot? And the short answer is no. Effectively, the motion of Depot is you get a engineer to sign up for Depot on a free trial. We aim to, like, make their builds exponentially faster within the first five to ten minutes of using Depot.
So, like, you should be able to literally change one line of code and your build should get faster. Whether it's, like, whether it's swap Docker build for depot build Yeah. From the original product or swap your runs on label for depot runs on label and get up actions, like, build should be exponentially faster within the first five to ten minutes. And what's really interesting about that is when we accomplish that, for all intents and purposes, like, the product kind of sells itself, from that point forward. And then it's that engineer that then effectively has enough buying power to bring that to their team.
And then Depot's motion is effectively like a land and expand from there.
So they say to their manager?
Yep. I say to their manager
my build. Yep. 10 times.
Or Yep. And then, effectively, like, that spreads Depot throughout the company. Usually, the flow for Depot is the company will adopt one product first, and then they'll start adding on the other products usually over the next three to six months as they start to see, like, oh, okay. Like, Depot can accelerate this. Like, can Depot also accelerate that and that and that?
And it's really when we get to the things where they're looking for the acceleration of something and we don't support it, like, that's that's effectively our product roadmap from that point.
Interesting. Yeah. That's super, super cool. One of the things that we were talking about before this was about, profitability and, I guess, why it's important.
Yep. I have, like I have all kinds of feelings about fundraising and venture capital and YC, but I think the best thing you can do as a founder is get to cash flow breakeven as fast as possible. And the reason for that is because when you do that, you control your destiny now. You control, like, what's the thing that you wanna do next. I've worked in companies.
I've seen a lot of other founders get trapped in, like, the fundraising bandwagon of, like, always fundraising. Yeah. Which, I guess, in, like, some ways is great for your ego, but long term, like, business sustainability, I don't think it's the right thing. Like
And you mean sorry. You mean ego because Yeah. That's a post, like, TechCrunch articles and stuff.
Yep. There's a there's, like, there's groups of founders, definitely not all founders, but there's groups of founders out there that fundraise money, and they're effectively, like, serial fundraisers. Like, they like the press. They like the I don't know why they like it, but they they like the, like, speed dating concept of fundraising. And so, like, they just keep burning money.
They don't get to cash flow breakeven, which means they just have to fundraise more money. So they're, like, they're not focusing on the right things inside of the business. Whereas, I believe, getting a profitability is the right thing to focus on as a business. Maybe not if you're just getting started. Right, don't focus on that.
Like, if you don't have product market fit, like, don't focus on profitability yet. Get to product market fit because you're going to burn a lot of money figuring out, like, what that product market fit is. Once you find that, then, like, start figuring out, like, how do you get to profitability from there. And so I think as we think about it for depot, we're always looking at, like, okay, what's the strategic things that we wanna do next in the future? And how does that how does that play with our idea for a cash flow breakeven?
And as long as we have, like, a strategic roadmap in mind of, like, we're gonna burn this much money to accomplish this strategic goal, that's fine. Like, if you know that you're burning that money to get to this goal and that's gonna push you further from cash flow breakeven, that's okay. But doing that over and over and over and over again, eventually, you're going to run your business into the ground.
At some point, you do have to think we need to make decisions that Yeah.
Move us towards. Yep. I think, my favorite, like, most recent example of this is I know PlanetScale, like, made waves when they got rid of their, like, free tier and all of that. Right? Which is understandable for the community, but was a really sound business decision.
They looked at their business and said, this thing that we're offering is, like, pushing us further and further from cash flow breakeven and is not a strategic thing that we want to do in the future. Right? And so they killed off the thing that was pushing them away from cash flow breakeven and realigned themselves of, this is where we want to go in the future, And they're pointing the boat now in the direction of, like, cash flow breakeven. Right? Actually, I think PlanetScale is profitable now.
I think I heard that, like, on a podcast recently. And so they caused waves in the community, but they did the right thing for the business. And especially, I think this is true with any developer tool, but definitely true with databases, is, like, companies are not going to switch to your database if you might not exist five years from now. Right? And so for them, pointing the boat in the direction of cash flow breakeven is not only, like, the right strategic decision, it's also the right, like, long term business decision for their ICP.
Like, they're showing their ICP and, like, no. Like, we care about being a sustainable business so that we can be your database for the next twenty years.
Mhmm. Yeah. Actually, I think it because I hadn't, like, I hadn't known much about PlanetScale when I saw that Mhmm. Announcement, and it was very like, it kind of also told me, like, a bit more about, like, what they do and who they care about. And it was, like, yeah, we care about, like Yeah. People that have are operating at, like, the biggest scale in the world and stuff. And, like
Yeah.
It was it was cool.
Being an engineer and then becoming a founder is, like, now I can see both sides of the world. Yeah. And so I think back to, like, if I wasn't a founder and then I was just back in a platform team and I saw the PlanScale announcement, like, I would be upset too, like the rest of the community was. But I think now being a founder, what I've learned is every business has an ICP. Yep.
Every business has a strategic vision that they want to get to. And the reality is is, like, not every developer under the sun is going to fit into that ICP. Yep. In fact, they shouldn't, And not every company is going to agree with your strategic vision. Right? Yeah. So, like, you don't need to sell to every company in the world. You just need to sell to the companies that would benefit from your solution that are facing the problems that you're solving.
Mhmm.
And I think it's can be challenging for folks that are, like, outside of that world
Yeah.
To, like, fully understand what it looks like to run a business from the inside. But that's what you're always thinking about as a founder is, like, is this company in our ICP? Like, should we, like, consider what they're saying? Should we not consider what they're saying? And it really takes, like, time and scar tissue
Yeah.
Of, like, that decision and thought process to figure out, like, okay, I can ignore this one, do this one. Or that one, do this other one. But it also evolves over time. Right? Like, as you scale and grow the company, that decision making process is also going to grow and evolve over time.
Yeah. I I guess the obvious question here is, do you have do you guys have a free plan?
We don't have a free plan. We essentially have an individual developer plan. It's $20 a month. That includes, like, a bucket of usage that comes with it, and then we don't allow you to, like, burst over on that individual developer plan. The reason for that particular aspect of it is you can get a lot of, like, not great ICPs that are not individual developers that then sign up for that plan, when they should be paying for more of the feature set of Depot.
That would that's, like, the inspiration behind that plan. Wait. So We're actually in the process of moving back to a full, like, usage based model. Okay.
Yeah. And sorry. Sorry. Can you explain that part again? The
Yeah. You can end up with effectively, what we'll call startups Yep. Signing up for an individual developer plan Yep. And
sharing an account.
And then sharing an account. Yeah. Okay. And so what we do is we limit the number of build minutes that they can do on the platform. Because if you're truly an individual developer, like, the number of build minutes we give on that lower plan is going to be more than enough Yeah.
For what you're doing. And if we do have an individual developer that hits that limit, and they send us an email, we essentially add a bypass for them, and we allow them to, like, burst over. Okay. But we put, like, tighter controls around that. But we're kinda, like, doing away with all of that and moving back to a usage based model
Okay.
At the moment.
Why is that?
It's a good question. I talked a little bit before building Zepo so that it resonates with us as engineers. Mhmm. But I think as time has gone on, we've built a pricing model that works well for us as founders, but doesn't necessarily resonate with us as engineers. And so when I think about how I want to use developer tools, I want as little friction as humanly possible.
I essentially want to be able to sign up for the tool, get going in five minutes, and then see results. And at the moment, with our current, like, tiered pricing, where it's $20 or $200 a month, depending on which plan you choose, it's forcing engineers to have to, like, think about the price and the costs. Whereas I want them to be focused on, like, how do I make my builds faster? Mhmm. And one of the best ways to accomplish that is to not charge people if they're not using the product.
Right? So if they sign up and they have a one month lag because they're addressing some big security thing or whatever it might be, some compliance thing, and they're not using Depot, like, they're not getting value from Depot, so why should they pay for it? Mhmm. So for us, moving back to usage based pricing is, like, removing the friction. Yeah.
It's like, you can just sign up, use Depot, you'll pay per minute for the build acceleration products or you'll pay for the storage for the cash products. And it'll be purely usage based. Mhmm.
Is that like a trade off on, like, the psychology of, like, oh, what if I sign off and then I I do way too many build minutes and I get a huge bill or something.
I think we also guard against that in that we have automated systems that detect, like, okay, you're doing way more usage than you usually do, we reach out to you. It's like, is this expected? Like, is this going to continue? Because then, like, if it is going to continue, like, let's get you on an annual contract and let's figure out, like, a pricing model that makes sense for this volume. And then individual developers, like, we put in all all of the features to effectively essentially, you can set caps and limits so that if you don't want to spend more than $20 a month, cool.
Like It's just gonna stop. It's just gonna stop running builds. Yeah.
Oh, that's great. Yeah. And I guess it it really fares in with like, everything you're describing is like, you're talking about developers. They care about this problem, work at a company. Yep. It's like mission critical. They've got money.
Yep. I think the other thing about, like, a build acceleration platform is we're in the middle of, like, the most important part of the software development life cycle. Right? This is the, like Releasing. Yeah.
This is, like, you're in the middle of the release process. And so that's where I think reliability is, like, critically important. Yeah. It's something that we spent a lot of time thinking about to the point where I was talking to a customer recently, and they're like, I don't even go to GitHub status page anymore because your, like, depot status page is gonna tell me if GitHub's broken before GitHub's gonna tell me if GitHub's broken.
So you Yeah.
And it's because, like, we see everything, right? Yeah. Like, with the GitHub action runners is what I'm talking about. And so sometimes when it comes to reliability, there isn't things that we can fix. Like, I can't fix GitHub.
Yeah. Believe me, I wish I could, I can't fix What I can do is, like, present the information that we're seeing from, like, our system. So we see this a lot with, like, people, when you think about, like a GitHub Actions job, there's the concept of queue time. Is effectively, like, you commit your code that signals something to GitHub actions to, like, now go run a set of workflows and so on and so forth. And queue time can vary wildly across GitHub, And it can be the most annoying thing to deal with as an engineer because you're just like, where why is my job not running?
Like, where the hell is it? And so we essentially monitor the the full, like, system. So when somebody commits their code, like, we know when we receive the webhook, meaning, like, GitHub's acknowledging the job. We know when we bring up the runner. We know when we start the, like, runner process.
We know when GitHub passes the job down to that runner process, and we, like, surface all of that. We surface all of that inside of Depot. So it's like, okay, like, why did that job take thirty seconds to start? And you can go look at it at, like, a fine grained level of, like, this three to five seconds, this is what Depot's responsible for. It's, like, bringing a runner online as quickly as possible.
And then all of the rest is, like, the job moving through GitHub's plumbing, more or less. And we're working on some, like, new stuff that goes around GitHub's plumbing, which is actually really cool. I can't quite talk about that one yet, but we're effectively, like, you can imagine queue time for depot in the near future dropping to zero.
Really?
Yeah. Okay. So effectively, like, we will connect directly to the system and the moment the commit happens, like, we will know about the job and can start running it. That's awesome. Yeah. And so it's like, there's all kinds of weird intricacies as you think about, like, build performance, but I think the common thread is surface, like, what you see and what you know, even if you can't take action on it yet. Developers appreciate transparency and visibility over everything.
That's yeah. That makes that makes a lot of sense. Just it reminds me of so we're recording this and yesterday was like the Spain Portugal Oh, yesterday. And I think Guillermo from Vercel was like telling people that the electricity was out, like, whether it still hasn't come back online because you could just see like all the traffic in the region and stuff. Like Yep.
It's, like, may maybe not quite the example, but, like, if you share that sort of stuff, it gives you kind of credibility and Yep. Shows that you really know you are looking at these things.
You know you know what's going on. Yeah. I think the most frustrating thing for engineers is when they're using a tool or system and they can clearly see that it's broken Yeah. And they're not getting the information of, like, why it's broken. Yeah. Either, like, an incident hasn't been opened, which is extra annoying, or the incident is just, like, hey, we're looking at this. And it's, like, yeah, but, like, what is it? Like, what can I do to go around it? So on and so forth. Yeah. Yep.
Okay. Final question that I just wanted to ask you before we wrap up. Do you have any advice for founders if you had, like, one lesson?
It's gonna sound super cliche, but, you really should build something that people want. Like, I know that's, like, that's like saying water is wet coming from a YC founder. But as Deepa has grown and scaled, I always come back to that now. I feel like probably the first twelve or eighteen months, we, like, caught ourselves, like, wandering off of that path where you're like, well, what if we built this thing or that thing? And you would, like, start going down that path, and then you would, like, look back and you're like, why are we building this thing?
And when you, like, ask the whatever it is, is it the three whys or the five whys or whatever, we were getting to the point where we were, like, dissecting it and it's like, oh, we're building this thing because we thought we should build this thing. And that's a super slippery slope to be on because as you find product market fit, especially in the developer tool space, your customers are going to ask for things. Mhmm. So listen to what your customers are asking for and go build those things. Those are the things that they want.
And so build something that people want and don't ever, like, lose sight of that. So, like, from the very beginning, from you don't have product market fit, go talk to people. Go talk to your potential users or what you think are your potential users. Like, what is the pain they feel in their day to day job? Yeah.
Like, what are those pain points, and how do they make them feel? Right? And then go build solutions to those pain points as quickly as possible. Don't spend, like, three years building a flipping SaaS prototype. Like, this is the dumbest thing you can do.
Go build something in a week, and then go ask them, like, does this solve your problem? Because they're going to tell you, like, if you talk to them and you build trust with them, and then that only, like, you just rinse and repeat as you progress. Even when you find product market fit, I think for us, our entire road map is just what people are asking for. And I think you can do that with any business. I think you can do that in in in any industry.
It's just, like, listen to what your users are facing, listen to the problems they have, and go build solutions to them because that's the stuff that they want.
Amazing. Amazing. Well, thanks, Carl.
Thank you.
And thanks everyone for listening.