Kyle Galbraith from Depot: how they hit $1M+ ARR with three people
Depot cofounder Kyle Galbraith explains how three people crossed $1 million ARR, why an “open knowledge” company can out-teach its competitors, and how making one build dramatically faster in ten minutes creates its own land-and-expand motion.
Kyle Galbraith is the cofounder of Depot, a platform that accelerates Docker image builds and GitHub Actions workflows.
Depot passed $1 million in annual recurring revenue with Kyle, cofounder Jacob and one founding engineer. Kyle breaks down the ruthless prioritization, founder-led distribution, precise performance proof and low-friction pricing behind that unusually lean growth.
The Q&A below is experimental — extracted from the episode transcript with AI. If you spot a mistake, let us know at jack@scalingdevtools.com.
How did three people take Depot past $1 million ARR?
The team stayed almost entirely engineering-led and built for problems we understood as platform and DevOps engineers. Remaining tiny forced ruthless prioritization and kept everyone pulling in the same direction, though the workload eventually became unsustainable at roughly 80 hours a week. Hiring followed the customer load: more engineers and an account executive expanded capacity after the business had proved what it needed.
How did a distributed founding team cover customers?
Jacob in London and I in southern France handled Europe and earlier time zones, then passed the baton to our engineer in North America. As the team grew, that pattern became a proper support rotation instead of requiring everyone to be available. Geographic distribution created coverage before we had enough people to design a conventional organization around it.
What is difficult about handing off founder-led work?
Founders hold years of context behind every decision and customer, so writing a document cannot transfer it all. The person taking ownership effectively has to behave like another cofounder for the first six months—present in the calls and decisions where missing context becomes visible. That shared work reminds us to explain what we otherwise assume, while our own focus changes with the company and market.
How do you market to developers?
Educate them. We explain the underlying problem, how we built a solution and what happens technically behind the scenes. Depot is not open source, but it operates as an open-knowledge company: competitors can copy an implementation if they wish because the people repeatedly solving new customer problems are the durable advantage. Useful technical material earns credibility even from readers who never buy.
How did technical content translate into growth?
Multiple pieces compounded through word of mouth and occasional Hacker News appearances. Engineers now cite Depot articles in unrelated GitHub issues because the posts explain techniques such as remote caching in enough detail to help without requiring the product. That makes the company a source people trust. The leader in a crowded category is often the team still solving problems while others chase its visible features.
Why are Depot’s most persuasive testimonials so specific?
They are organic reports from engineers holding the before-and-after evidence: an exact build time, workflow and acceleration. DevTools already generate the proof, so a generic compliment throws away the strongest material. People share those numbers because recovering real time feels remarkable. The same precision makes another engineer able to imagine the result in their own pipeline.
What is the value beyond a shorter build time?
Container builds can be 20–60 times faster, runners 3–10 times faster and caching around 10 times faster, but the deeper cost is context switching. An engineer does not sit idle for an hour; they move to another difficult task and may spend 15–45 minutes changing mental state in each direction. Faster feedback protects concentration, productivity and happiness, not merely machine minutes.
How does the product create a land-and-expand motion?
An engineer starts a trial, changes one command or runner label and should see a dramatic improvement within five to ten minutes. Once that happens, the product largely sells itself and the engineer has enough buying power to bring it to a team. The first experience does not ask them to understand a strategic productivity model; it gives them direct proof in the system they already own.
Why move toward usage-based pricing?
Fixed tiers made engineers think about a plan before the result and charged during periods when the product delivered no value. Usage pricing removes that friction: pay for accelerated minutes and stored cache when they are used. Spend caps protect individuals, and unusual growth triggers a conversation about expected volume and an annual agreement. Pricing should feel natural to us as engineers, not merely convenient to us as founders.
What single lesson would you give founders?
Build what people want and keep returning to that test after product-market fit. Talk to users about the pain and how it feels, create a small solution in a week, then ask whether it helps. Customers will continue supplying the roadmap if you listen. The dangerous detour begins when a team builds something because it assumes it should, rather than because a real user asked for the problem to disappear.