Snowflake had the people, the knowledge and the machinery. Its developers were already using Bazel, the build system associated with Google-scale engineering, and remote execution. Yet keeping that machinery running could occupy five specialists. The awkward question was whether people hired to improve developer productivity should spend so much time tending the equipment.
Snowflake signed with EngFlow in July 2025 and moved most of its remote-build workloads by October. EngFlow’s case study reports nearly 50% lower AWS infrastructure costs and four of five engineers redirected from upkeep. The attraction was a quieter working day: a critical system that demanded less attention.
- Share the work. Run build actions across a cluster instead of exhausting one computer.
- Remember the answer. Reuse cached results across developers and CI.
- Count the upkeep. Include engineering time when comparing managed infrastructure with your own.
The engineers who built the escape route
EngFlow began in 2020 with two founders whose experience fitted together unusually well. Ulf Adams, now CTO, led Bazel development and open-sourcing at Google. Helen Altshuler, now CEO, led enterprise customer onboarding to Bazel and co-created BazelCon. One understood the engine; the other understood what happened when somebody tried to drive it.
That matters because a build system is an agreement about how software fits together. Source files, compilers, dependencies and tests must arrive in the right order. A faster computer can shorten the work. It cannot automatically untangle the agreement. EngFlow sells the infrastructure and expertise needed to make that arrangement run efficiently.
Andreessen Horowitz backed a $3.7 million seed round announced in 2021. A year later came an $18 million Series A with Tiger Global, a16z and firstminute capital. The disclosed rounds total $21.7 million. Its customers include browser makers, data platforms and automotive companies: businesses where assembling software is a substantial recurring task.
The machinery between edit and answer
Imagine a browser build as a dinner party with thousands of dishes. Making every dish on one stove creates an obvious queue. Remote execution supplies more kitchens. The scheduler distributes ready actions to workers; workers execute them and store their outputs. Dependencies still matter. A dish that needs another dish cannot simply jump ahead.
Caching adds a more economical trick: avoid cooking the same thing twice. When the inputs and action match a stored result, a developer can reuse work done by a colleague or CI. Remote persistent workers reduce repeated compiler startup overhead. Autoscaling adds capacity when demand rises and powers machines down when it falls.
Brave’s published result puts the proposition in human units: Chromium build execution dropped from two hours to 15 minutes. Its shared cluster also reduced reliance on expensive developer machines. Viasat reports a different workload falling from 24 hours to one. These are reported customer outcomes; neither is a promise about your repository.
“We no longer need expensive but underutilized developer machines.”
Mihai Plesa · DevOps Manager, Brave
EngFlow’s Build and Test UI makes failures and timing visible in a browser. The free, open-source Bazel Invocation Analyzer suggests improvements from build profiles. CI Runners integrate with GitHub Actions and Buildkite, keeping Bazel instances and caches warm. Each addresses a different interval in the wait between an edit and an answer.
The bill has two columns
EngFlow offers managed and self-managed deployments, including cloud and on-premises options. Its public Free tier serves Bazel on one Linux machine, up to 32 cores. Enterprise is custom quoted. An honest comparison must add the service fee, compute, storage and migration work, then consider the engineering time required to operate the alternative.
BuildBuddy also sells managed remote execution and caching. Open-source Buildbarn lets teams operate their own. EngFlow’s case rests on its Bazel experience, support for multiple build systems, dedicated customer infrastructure and willingness to take on operations. The price question is inseparable from which responsibilities your team wants to keep.
Its March 2025 acquisition of tipi.build broadened that argument. CMake RE brings remote execution and caching to CMake users, while HermeticFetchContent addresses reproducible dependencies. A C++ team can pursue build acceleration without first signing up for an entirely different build system.
Three billion actions, and one missing flag
In August 2026, EngFlow reported processing 3.5 billion actions a week, about fourteen times its volume fourteen months earlier. Actions are units of build work, not customers or complete builds. The company says AI-heavy customer hackathons exposed gaps in scaling and observability. More code was producing more pressure on the checking machinery.
One public investigation offers a less polished view of the business. A customer’s Buck2 jobs were intermittently hanging. EngFlow examined network captures and found requests missing the HTTP/2 signal that says sending is complete. The trail led to a Rust library bug and an upstream fix. Buying infrastructure also buys somebody to follow that trail.
Measure the wait before buying the cure
Start with a representative build profile. Separate startup, execution, cache misses and transfer time. Test a small remote-compatible target before extending the rollout. EngFlow’s September 2026 any2bazel tool can assist migration, but generated build descriptions still need validation. Explicit dependencies and suitable remote toolchains remain requirements.
If the work is small, mostly sequential or rarely reusable, distribution may add more overhead than it removes. Iterable’s migration account adds another useful caution: changing build systems and CI together complicated the final stretch. Measure a change you can explain. The useful prize is a team that spends more of its day making decisions about software.