A good time to invest in Software Build Systems as they undergo transformation

…and why we invested in Toolchain

Written by: Yuval Tamir

Build Systems is a domain undergoing transformation, which Chingona recently entered with the investment in Toolchain, a next-gen build system. So what is the Build space and why did we invest in Toolchain?

What are Build Systems?

Essentially, build systems transform the source code written by software engineers into a finished software artifact that is ready to be shipped or deployed. Some of the steps taken by build systems include dependency resolution, code generation, compilation, running tests, formatting code, enforcing code style, security checks, packaging and more. In simple terms, Build Systems translate what the coder writes into a language the computer understands. For that reason, build systems have been around since there were programming languages. Earlier (and most current) build systems have a major drawback — they can be slow — they perform poorly under many circumstances, especially in large projects. This performance-at-scale problem is especially acute for currently popular languages such as Python, since existing systems were typically designed with C, C++ and/or Java in mind. A new type of build system that is emerging aims to solve these problems.

What’s wrong with most build systems today? (tl’dr — they destroy engineer productivity)

Most build systems perform poorly in large projects because they often have to rebuild the entire codebase, or a very large chunk of it, every time there’s a build. To illustrate the problem, here’s an analogy for non-coders reading this article: Imagine that every time you’re hitting “save” on a Microsoft Word document, you have to wait a few minutes before continuing to make edits, and every time you modify some text, the spellchecker took a few minutes to give you feedback. It would probably cause you to save less often and make you less productive. This is similar to what’s happening with build systems — every time a developer needs to run build steps (translate source code into executable binaries and test that those binaries work), the build system needs to build the entire code with all of its dependencies. Depending on the code, it’s not uncommon for the process to take longer than 45 minutes for a build. And what happens when a 45-minute build is underway? The developer context switches to another task. By the time the build completes, they need to pay a high “mental tax” for “getting back in the zone”. This is exacerbated by the fact that many small defects are often found during the build process, so if a developer makes a tiny change, waits a few minutes, gets negative feedback, fixes, re-runs, etc. this can become very expensive. The ratio between overhead (context switching) and work becomes very bad. This is a source of reduced productivity for developers everywhere. To solve this problem, many companies have built more efficient build systems in-house, and the most prominent of these are Google (who built Bazel AKA Blaze), Twitter (where Pants originated, before being open-sourced), and Facebook (who built Buck).

Artifact-Based Build Systems — Build for speed

Google, Twitter and Facebook developed their internal Build Systems and released them into open source. Internally, these systems solved the problem of speed by offering three new capabilities:

1. Incrementality: Instead of building the entire code and its dependencies every time, Blaze, Pants and Buck only build the incremental changes made by the coder. Everything else “stays the same” from the previous build. This reduces the amount of code that needs to go through the build process, reducing time of build.
2. Parallelism: Instead of having to do the entire build from one machine (in many cases a developer’s desktop), the new generation of build systems enables builds to be divided up and carried out by multiple machines — enabling scaling on the Cloud and reducing time of build.
3. Remote Caching: Remote caching enables teams to “save” their latest builds in a centralized cache so that if one developer made a change to a piece of code that is a dependency for another developer’s code, they won’t have to rebuild the dependency, since it is saved in the cache. The new systems build only what needs to be built, reducing time of build.

The new build systems developed for internal use at a company work great within that company, but can be fairly difficult to integrate outside that company. Just read some of these reactions from developers who have tried to integrate them (“Bazel is pretty magic inside Google. Sounds like it’s too hard to use or install outside of Google”). For that reason, we’ve been seeing the emergence of several new startups (like Toolchain, BuildBuddy, and Engflow) who want to make these new build capabilities accessible to other organizations.

Why are we interested in the Build Space at Chingona Ventures?

Since Google and Facebook outsourced their projects around 2015, organizations have been struggling with integrating them into their software engineering organizations. These hyper-scalers (Google and Facebook) have hyper-scale problems so they built amazing technology to keep their engineers productive. What if small-mid size companies could use similar breakthroughs without employing large dedicated build engineering teams? The emergence of new startups in this space within the past year caught our attention. It is a space with problems just waiting to be solved by making best-in-class build capabilities accessible to the average tech organization. Moreover, as a newly emerging domain, there is no market leader yet, and the market is up for grabs for all of the new entrants who seek to claim it.

Why did we invest in Toolchain?

To assess investments at Chingona Ventures, we like to use our 5Ps framework, which you can read more about in this article (People, Product, Profit, Potential, Portfolio). I’ll walk through the 5Ps for Toolchain to explain why we invested:

• People: Benjy and John developed the earliest version of Pants at Twitter, then open-sourced it and drove adoption at multiple other companies of various sizes, and later decided to build a company around it. They have significant engineering experiences directly in this area of expertise and have been successful in recruiting a team of talented and experienced engineers to work with them. When we invest in developer tools, we like to see significant and very specific subject matter expertise. We need to have a reason to believe that the founder has a unique insight that nobody else has.
• Product: At the time of our investment, the founding team had developed Pants v2, a full redesign of the original system, with strong support for Python, which is exploding in popularity, in part due to its prominence in data science. They designed Pants from the get-go to accommodate the needs of a wide variety of organizations, not just one hyper-scaler. They were also working on BuildSense, a SaaS execution/caching service, as well as improved UI. ​Having a unique product at the stage of development they were at when they were raising their Seed round, and with the amount of traction from early users who were very excited about the product — that’s something that we like to see.
• Profit: When it comes to developer tools, especially in open source, we realize that the path to revenue might be a bit longer, as it takes time to build credibility, adoption and a community around your product. Toolchain had these three factors already so we could see the path to revenue.
• Potential: This entire article speaks about the potential of next-gen Build Systems. We see this as a huge market, which is up for grabs.
• Portfolio: We have had our eyes set on developer tools for a while, and we especially like Tyler Jewell’s (Dell Technology Capital) definition of the landscape as laid out in the Developer-Led Landscape. This is an area we plan to continue investing in, and can’t wait to speak to more founders who are developing these tools.

Final thoughts

We are very excited about our investment in Toolchain, and the direction in which the Build Space is heading. We’d love to make more investments in this and adjacent domains. If you’re a founder looking for seed funding, you know where to find us.