Iterable cuts P90 build time from 42 minutes to 17 minutes with EngFlow¶
By migrating its Scala backend from sbt to Bazel with EngFlow and VirtusLab, Iterable created a faster, more reliable build foundation for AI-era engineering velocity.
42 → 17 minutes
P90 build time
~3 minutes
Common build time for smaller changes
~97%
Integration-test pass rate on master, up from the 70s
Iterable is an AI customer engagement platform trusted by global brands to create personalized experiences across every channel. Behind the platform is a distributed engineering organization building and operating a large, complex software estate.
For Iterable’s Developer Platform team, the mission is straightforward: help developers release software faster, with greater reliability and safety.
But the company’s legacy build environment was making that increasingly difficult.
Iterable’s Scala backend repo had grown to roughly 400 sbt projects. As the codebase expanded, the team faced a structural problem: the changes required to improve modularity were making the build system slower. Adding another sbt subproject could add noticeable startup overhead. Eventually, the team reached the point where decomposing the codebase further became counterproductive.
“The build startup time was too slow,” said Philip Clark, Engineering Manager for Developer Platform at Iterable. “The build time in general had gone up, and it was really no longer a manageable system.”
When incremental optimization is no longer enough¶
The consequences were visible throughout the development workflow.
Starting sbt alone could take one or two minutes. A local compile-and-test cycle could consume roughly 20 minutes. In CI, developers frequently waited 40 minutes or longer for builds, followed by additional test time. Flaky tests often forced engineers to rerun jobs until they received a clean result.
That changed how developers worked. Instead of maintaining a tight feedback loop, they waited, switched contexts, or deferred validation to CI. Incident remediation became slower because producing a trusted build could take too long. The platform team spent too much time managing friction rather than improving the developer experience.
Efficiency was also part of the equation.
As build times and test volume continued to increase, the team saw a clear opportunity to run CI more efficiently. But optimizing the existing environment would not solve the underlying problem.
Iterable decided to modernize at the foundation: migrate its Scala backend from sbt to Bazel, move to GitHub Actions, and make remote caching and remote execution core elements of the architecture.
“Remote caching and execution were critical to our strategy from day one,” Clark said. “Having both in CI and for local developer access has been a really important part of how we are approaching this.”
Choosing EngFlow instead of building internally¶
Iterable considered operating remote build infrastructure itself.
Clark briefly investigated standing up an internal BuildBarn environment. He quickly concluded that running a production-grade remote execution platform would divert the Developer Platform team away from higher-value work.
“Even large engineering teams can benefit from having a hosted solution with experts steering and building that out,” Clark said.
Iterable selected EngFlow for its combination of remote execution, remote caching, performance, observability, operational support, and deep Bazel expertise.
With EngFlow, Iterable gained more than raw infrastructure. It gained an operating model for build and test: a dependable platform that could scale with demand without forcing the internal team to design, debug, and operate the remote build substrate itself.
As Alex Newman, Senior Software Engineer on Iterable’s Developer Platform team, put it: “EngFlow has been by far the least mentally taxing part of our complete CI and testing refactor. After the initial setup, it just works.”
EngFlow and VirtusLab: dividing the migration work effectively¶
Migrating a mature Scala backend from sbt to Bazel is not a simple tool swap. It requires architecture decisions, sequencing, implementation discipline, and a detailed understanding of how the codebase behaves in practice.
EngFlow and VirtusLab worked alongside Iterable to make the migration tractable.
EngFlow’s professional-services team helped orchestrate the migration. It worked with Iterable on the high-level architecture, migration strategy, remote execution environment, and design decisions required to establish the right foundation.
VirtusLab provided substantial hands-on implementation support. Drawing on its Bazel and Scala expertise, the VirtusLab team performed much of the detailed migration work: translating build logic, creating build files, and moving the codebase toward the new Bazel model.
The division of labor mattered. EngFlow brought the platform and operating expertise. VirtusLab added experienced implementation capacity. Iterable’s internal team supplied the application knowledge and handled the last-mile work required to safely retire the legacy environment.
The team also used AI-assisted tools, including Claude, to accelerate parts of the proof of concept and repetitive migration work. AI helped engineers analyze large dependency files, generate portions of the build configuration, and work through technical details more efficiently. Human expertise remained essential: the difficult work was not merely producing build files, but making sound architectural decisions and validating the result against a complex production codebase.
Material performance gains¶
The new environment has already produced substantial improvements.
Iterable’s P90 build time fell from approximately 42 minutes to 17 minutes, a reduction of roughly 60%. Typical build times are now around 14 to 15 minutes, with some completing in as little as five minutes. For smaller changes that do not touch the largest monolith project, three-minute builds are common.
The team also improved reliability. Unit tests now have an approximately 99.7% pass rate. Integration-test pass rates on master have reached roughly 97%, up from rates that had sometimes fallen into the 70s.
Just as important, the build infrastructure itself has become less intrusive. Remote execution and caching work reliably enough that developers and platform engineers can focus on the codebase rather than the build cluster.
“Without EngFlow, we would still be trying to optimize seconds off an hour-long build,” Clark said.
The final stages of a broader modernization¶
The migration is nearing completion, but the work has also exposed a valuable lesson: moving to a more precise build system surfaces technical debt that less rigorous systems allow teams to ignore.
Bazel revealed implicit dependencies, runtime-version issues, integration-test assumptions, and patterns embedded in the legacy environment. Iterable’s team has worked through those issues methodically while temporarily maintaining both build systems.
At the time of writing, Iterable is completing the final stages of the transition: retiring the legacy integration-test path, migrating images from the old sbt build system to Bazel, and safely rolling out the new environment.
The experience has reinforced an important migration principle. Change one major system at a time whenever possible. Iterable simultaneously moved from sbt to Bazel and from CircleCI toward GitHub Actions. Both changes were strategically justified, but the overlap increased the complexity of the last mile.
Build management at AI scale¶
The timing of the modernization matters.
As Iterable’s engineers adopted AI coding tools, development throughput increased sharply. The team estimates that commits to master have increased roughly fourfold, while pull-request volume has approximately doubled over a period of months. AI tools are not only increasing the number of changes; they are also increasing the size and ambition of the work engineers attempt.
That makes validation infrastructure more important, not less.
Agents can generate code quickly. But every change still has to be built, tested, reviewed, and shipped safely. When code generation accelerates, slow or unreliable build systems become an immediate constraint on engineering velocity.
Iterable is already seeing the benefits of a build platform designed for that environment. Agents can invoke Bazel builds and tests without requiring developers to think through the underlying workflow. Remote execution provides a scalable environment for validating changes without forcing the platform team to recreate local build environments for every agent.
“It is one of the core engines of engineering,” Clark said. “If you can’t build and test your code, then you really can’t do anything. EngFlow allows you to do that faster than anyone else.”
For Iterable, the result is larger than a faster build. The company is creating the operating foundation for a new development model: one in which developers and agents can move faster while build and test remain reliable, observable, and under control.