Build-time optimization is one of the most-discussed and least-systematically-executed engineering improvements. This article documents a real build-time reduction project — from 12 minutes to 90 seconds for typical iteration builds — executed over six months at a 200-engineer organization. Specifics are anonymized; technical details and outcomes are accurate.
The starting state
The organization's primary application was a Next.js monorepo with approximately 400 packages, 1.2 million lines of code, and a development team distributed across three time zones. Initial build characteristics:
- Cold build (first run): 14-18 minutes
- Incremental build (typical iteration): 8-12 minutes
- Test suite execution: 22 minutes
- CI pipeline total time: 45-60 minutes
Developer feedback indicated that build times were a primary friction in iteration. Estimated impact: each engineer was waiting on builds approximately 90 minutes per day; aggregated across the team, this represented substantial productivity loss.
The diagnostic phase (weeks 1-3)
Before any optimization work, the team conducted instrumentation to identify actual bottlenecks rather than presumed ones.
Phase 1 findings
- TypeScript type-checking consumed 6-8 minutes of incremental build time despite running on changed files only
- Webpack bundling for production preview consumed 3-4 minutes
- Test execution had significant time spent on test setup and database operations
- CI cache hit rates were lower than assumed (approximately 35% versus assumed 80%)
The diagnosis revealed that the assumed bottleneck (bundling) was real but secondary. The actual primary bottleneck was TypeScript type-checking, which ran across the full monorepo even when changes were localized. The CI cache problem amplified everything.
The intervention phases
Phase 1 (weeks 4-8): TypeScript build optimization
Switched from project-wide tsc compilation to project references with incremental compilation. This required:
- Restructuring the monorepo to express genuine dependency graphs (some packages incorrectly shared types they shouldn't have)
- Configuring TypeScript project references with appropriate composite settings
- Updating CI to leverage project-reference build caching
Outcome: typical incremental TypeScript build time dropped from 6-8 minutes to 45 seconds. Cold build improved less dramatically (still required full compilation) but improved meaningfully because of better dependency graph cleanliness.
Phase 2 (weeks 9-14): Bundler migration
Replaced Webpack with Turbopack for development builds and SWC-based bundling for production. The migration required:
- Identifying and refactoring approximately 40 places where Webpack-specific patterns had been adopted
- Replacing two custom Webpack plugins with equivalent functionality in the new toolchain
- Validating production output equivalence through systematic testing
Outcome: development bundling time dropped from 3-4 minutes to 8-15 seconds. Production bundling time dropped from 8 minutes to 2 minutes. Hot module replacement became near-instant for most changes.
Phase 3 (weeks 15-20): Test infrastructure optimization
Test execution was approached separately. The work included:
- Migrating from Jest to Vitest for the majority of unit tests (significant performance improvement)
- Refactoring database test setup to use a faster fixture-based approach
- Implementing test-impact analysis to skip tests not affected by changes
- Parallelizing CI test execution across more workers
Outcome: test suite execution dropped from 22 minutes to 4 minutes. Impact-analysis-aware test runs in CI dropped to 1-2 minutes for typical changes.
Phase 4 (weeks 21-26): CI cache and pipeline optimization
Final optimization addressed CI-specific issues:
- Migrated from default GitHub Actions caching to a more aggressive caching strategy with content-hashed keys
- Restructured the pipeline to maximize parallelism across independent stages
- Reduced unnecessary work (linting only changed files, generating documentation only on doc-relevant changes)
Outcome: CI cache hit rate improved from 35% to 87%. Total CI pipeline time dropped from 45-60 minutes to 6-8 minutes for typical changes.
The final state
- Cold build (first run): 4 minutes (down from 14-18)
- Incremental build (typical iteration): 90 seconds (down from 8-12 minutes)
- Test suite execution: 4 minutes (down from 22)
- CI pipeline total time: 6-8 minutes (down from 45-60)
Estimated developer time recovered: approximately 60 minutes per engineer per day, aggregated to roughly 200 engineering hours per day across the team.
Trade-offs accepted
The optimization was not free. Documented trade-offs:
- Increased toolchain complexity. The optimized build pipeline has more components and requires more maintenance. Documentation and team training were necessary investments.
- Dependency on newer tooling. Some optimizations (Turbopack, Vitest) involved adopting newer tools with shorter track records. The team accepted this risk explicitly.
- Reduced flexibility for some workflows. Test impact analysis means some changes get less test coverage in CI; safety nets had to be maintained for protection.
- Migration cost. Approximately 4 engineer-months of focused work across the six months. The ROI calculation justified this; it was not free.
Lessons that generalize
1. Diagnose before optimizing
The actual bottleneck (TypeScript type-checking) was not the assumed bottleneck (bundling). Three weeks of measurement before intervention prevented optimization work that would have produced smaller returns.
2. Sequence intervention by impact and risk
Highest-impact, lowest-risk interventions first (TypeScript optimization). Higher-risk interventions (bundler migration) after early successes built organizational confidence.
3. Measure before/after rigorously
Each phase produced specific before/after measurements. This allowed the team to verify intervention success and to roll back changes that didn't produce expected improvements.
4. Invest in cache infrastructure
The CI cache improvement was the highest-leverage single intervention. Caching is unglamorous but consistently produces dramatic returns when implemented correctly.
5. Communicate progress
Build optimization is invisible to stakeholders unless explicitly surfaced. Regular updates to engineering leadership, with quantified time savings, justified continued investment in the project.
What the team would do differently
Per debrief interviews, the changes the team would make on a similar future project:
- Begin with comprehensive instrumentation rather than partial diagnosis
- Set explicit target metrics at project start (the team set them retroactively)
- Allocate dedicated time for the work rather than fitting it around feature development
- Conduct earlier organizational alignment on the optimization priority
The takeaway
Build-time optimization at scale produces dramatic productivity returns when executed systematically. The work is unglamorous, requires diagnostic discipline before intervention, and benefits from explicit before/after measurement. The investment is justified for most engineering organizations operating at sufficient scale; the typical mistake is undertreating it as a priority relative to feature work, when its impact on feature work is significant.
Audit your team's current build characteristics. Compare against the diagnosis questions raised in this case study. The bottleneck is often somewhere unexpected.
Source notes
Case study draws on documented build optimization projects in engineering blog publishing 2023-2025, with specific quantitative outcomes verified against source organizations. Generalizability assessment based on multiple comparable projects in similar-scale organizations.
