Imagine you live in a world where no part of the build has to repeat unless the changes actually impacted it. A world in which all builds happened with automatic parallelism. A world in which you could reproduce very reliably any part of the build on your laptop. Fairy tales, right? Well, that’s what we built, and to everyone’s surprise, nobody wanted it. It’s like flying cars – they sound amazing, but in practice, things are more difficult than they might seem.

Back in April 2020, we at Earthly set out on this quest to improve CI/CD tooling. We dared to ask questions like “What if the CI could run on your laptop?” And “what would the fastest CI system on the planet look like?” With these questions in mind, we came to a pretty strange, but pretty interesting answer… the build system and the CI need to be the same. And it needs to be distributed.

Now we all know dreaming big is easy. Execution is where things get hard.

What Does Success Look Like?

In a startup, you don’t have the luxury of building a mature product with all the possible bells and whistles before shipping it to your customers. Mature products take many years and many engineers to build out.

And yet, you are going up against the incumbents – companies that have hundreds of millions in funding, (maybe even IPO’d), they have hundreds of engineers, they have a 10-year head start, and a ton of reputation. How can you even compete?

Well, you know what they say… “Competition is for losers”. The answer is that you don’t. At least not on the same level. You’ll never be more mature, or have more features, or more integrations. Instead, you can be 10x better in one, very specific way. And you’ll appeal to the few teams where the very specific problem you’re solving is so painful that they’re willing to make compromises on everything else.

You’re not going after the whole market in the beginning. You’re just going after just enough enthusiasts, mavens, early adopters – whatever you want to call them – for whom the solution that you built on a shoestring budget is dramatically better in their specific situation than any incumbent. So much better, that they’re willing to pay the cost of adoption, and they’re willing to suffer through the bugs and the missing bells and whistles.

Then, once you have captured that segment, you invest more, extend to a wider audience, get more feedback, then again invest more, extend again, and so on. It’s important to understand this dynamic in order to gauge what success looks like at the earliest stages.

So if your MVP is not getting enough validation, you can’t just slap more features on it, because, again, features are not what will make you successful. Incumbents win feature contests.

Successful products will show validation at a small scale, despite all their limitations, bugs, and general annoyances. If you can’t find a small group of people passionate enough about your product in its experimental stage, you’re going to have a hard time capturing an audience even with a feature-rich product. It’s a recipe for building something nobody wants.

What early-stage validation looks like is a small group of people who have a lot of passion for what you do. Nobody has heard about your stuff, but your users are passionately shouting from the rooftops about it. You walk into their office and everyone has stickers with your company on their laptops, and everyone wants to talk to you.

The Master Plan for Earthly CI

To build out the vision of Earthly CI, we devised a master plan. We knew that we didn’t want to go on a crazy complex implementation for 3 years only to emerge from a cave with a product that would not fit the needs of the real world. So we split up the end-vision into several independent products that we would validate along the way.

Thus, instead of building Earthly CI from day 0, we first built the syntax, and the general experience around running builds on-demand. The key value we delivered was build consistency: there is a level of guarantee that the build will execute the same, regardless of the environment it runs in. The syntax of this build tool is the same as the CI down the road, but it only ran locally initially and in other CIs. We called this first milestone Earthly.

Then we built remote runners that can be invoked from anywhere – again your laptop or any CI. These remote runners bring you all the key benefits of Earthly CI but without being a CI. The key value is build speed. And I’m talking 2-20X faster CI pipelines, thanks to the caching and parallelism. We called this second milestone Earthly Satellites.

And finally, the third milestone, Earthly CI – the platform that brings everything together, the CI that is ridiculously fast and can run anywhere. This is the full CI that is meant to compete with all the other big CIs like GitHub Actions, CircleCI, Jenkins and so on.

What was particularly appealing about this plan was that Earthly, the build system, targets one problem: build consistency, while the final version, Earthly CI, targets another problem: build speed. This meant that Earthly, which is free, would not cannibalize in any way the monetization of Earthly CI. We wouldn’t be giving away too much for free – as Jenkins did – and instead, it would serve as a sustainable and scalable business model. It made sense to use the build system as a way to then create bottom-up adoption for Earthly CI – and the fact that we were building it first allowed us to build traction that one day will magically just convert over to Earthly CI users.

Little did we know that this difference in value proposition – consistency vs. speed – actually became a problem down the road…

Milestone 1: Earthly

Earthly was the lowest-stakes validation. I just built the first version on my own, threw it up on GitHub, and then launched it on Reddit and HackerNews. Zero funding (apart from my wife’s patience), so close to zero risk. If it takes off, I go raise money. If it doesn’t I’ll try something else.

We now know that Earthly is used widely across thousands of repositories, by companies big and small, like VMware, Adobe, Namely, Roche, ExpressVPN, Bluecore, and many others. But the early signs were that people were using Earthly even when it was a one-person unfunded project riddled with bugs and limitations. That’s validation.

Milestone 2: Earthly Satellites

After fixing the obvious issues in Earthly, and widened support to appeal to more types of organizations, we were now building momentum. And with enough capital, we were able to now work on the next milestone: Earthly Satellites.

The interesting thing about Satellites was that we were getting the validation even before we built them. Earthly being open-source, you could already run your own Earthly remote runner (since we use Buildkit underneath, it was essentially a remote Buildkit), connect Earthly to it, and get similar benefits to Satellites even before this was a commercial offering. And so people did this on their own,