Turbopack's Memory Eviction Just Made Your Build-Optimization Consulting Obsolete
On July 12, Vercel released Next.js 16.3 with Turbopack updates: memory eviction (frees compiler memory during long dev sessions), persistent build cache (cache survives restarts), Rust React Compiler support, and faster TypeScript transforms.
The "slow build" problem (the thing that was worth a $5K–$15K consulting engagement two years ago) is officially shipping as a platform default.
If you have a consulting retainer labeled "build performance," you need to audit your pipeline this week.
The build performance TAM, then vs. now
In 2024–2025, optimizing a Next.js or Webpack build was a real problem you could charge for.
A typical mid-size shop (50–200 engineers) with a Webpack build would have:
- Initial build: 8–12 minutes
- Dev rebuild: 45 seconds to 2 minutes (depending on file changed)
- Developers typing into their IDE and waiting for the rebuild to finish before they can test
- Memory bloat: if dev servers ran for 8+ hours, they'd hit 4–8GB of heap and slow to a crawl
- Cache misses: CI builds didn't persist cache between runs, so a fresh pull always meant a full rebuild
The consultant's engagement: audit the build, identify the bottlenecks (usually: too many loaders, bad cache config, unoptimized webpack plugins), tune the webpack config, implement persistent caching (using something like cache.type = 'filesystem'), train the team on cache invalidation, and leave behind a process for monitoring build times.
Cost: $20K–$40K for the project. Value: a dev rebuild dropping from 90 seconds to 30 seconds, across 50 developers, every day, for six months = a lot of saved developer time.
That was defensible. It was specific. It was hard to do wrong.
What Turbopack shipping changes
Turbopack, built by the Vercel team, was designed from the ground up to solve the exact problem the consultant was solving: memory pressure, cache coherence, rebuild speed, and development experience.
In Next.js 16.3, it's no longer a beta feature you opt into. It's the default for new apps. And it ships with:
- Memory eviction: the compiler releases memory during idle periods. Dev servers don't balloon from 300MB to 4GB over eight hours.
- Persistent cache: the build cache is written to disk (
node_modules/.next/cacheby default). If you restart your dev server, the cache is still warm. No cache miss tax on each restart. - Rust-based transforms: the React Compiler and TypeScript transforms run in Rust, not JavaScript. ~2–5x faster for large codebases.
For a developer, this means:
- First rebuild after starting the dev server: ~10–20 seconds (used to be 60+)
- Subsequent rebuilds: ~5–15 seconds (used to be 30–60)
- No mystery slowdowns from memory pressure
- No "wait, why is my rebuild slow today?" debugging
The engagement that used to be $20K to solve is now "ship Next.js 16.3."
Why this matters for your consulting practice
If you have a retainer that includes "optimize the Next.js build" or "audit webpack configuration," you need to run the numbers this week.
Pull up your Jira or retainer list. For each client in the Next.js space:
Are they on Next.js <16? If yes: upgrade path. "We'll handle your migration to 16.3 and validate the new build performance" is a legitimate project (1–2 weeks, $5K–$10K).
Are they on Next.js 16.3 and complaining about builds? Unlikely. Turbopack solves 80% of build complaints. If they're still complaining, the problem is something else (bad code, unoptimized dependencies, bad CI caching). That's a different engagement.
Are they on Next.js 16.3 and happy? Then this isn't a revenue-bearing engagement anymore. Your retainer is at risk.
The honest read: if your retainer is $5K/month for "keep the builds fast," and Turbopack ships that for free, the customer is going to notice. They might not fire you immediately (inertia is real), but the renewal conversation is going to be awkward.
The positioning shift
There are three honest responses:
Response 1: Migrate and move on. Help the customer upgrade to Next.js 16.3, run the benchmarks showing the build time improvement, document it, and convert the retainer to something else: "ongoing performance monitoring," "infrastructure cost optimization," "CI/CD deployment speed." Find the next problem that exists after the build finishes.
Response 2: Deepen your specificity. Instead of "build performance," own "build performance and test speed," or "build performance and cache coherence across your monorepo," or "build performance and atomic deployments." Turbopack solved the generic problem. Your value is now the vertical-specific or use-case-specific solution.
Response 3: Sell the upgrade project. Make the migration to 16.3 itself a project. You audit the codebase, identify deprecations, test the new Turbopack build, validate the cache strategy, and hand over a deployment plan. That's a 2–4 week project at $10K–$20K. After the project, there's no retainer.
I'd recommend a mix of 1 and 2. Pick your customers strategically. For the ones where the retainer is under $3K/month, do the upgrade project and move to a different engagement. For the ones where the retainer is $5K+ and the work is deep (e.g., "we also manage your CI costs and deployment speed"), upgrade them and fold the Turbopack optimization into a broader performance package.
The honest take
This is TAM compression, not TAM destruction. The "generic build optimization" market just shrank. But the markets it compressed into ("I need my CI to be fast," "I need my deploys to be atomic," "I need my monorepo cache strategy to be coherent") are still real and still growing.
Turbopack winning doesn't mean build optimization is a commodity. It means generic build optimization is a commodity. You have to own a narrower, deeper piece.
The other honest piece: this is how software works. Platforms eat problems that used to be consultant work. WordPress ate the "I'll build you a website" business. AWS ate the "I'll manage your servers" business. Docker ate a bunch of the "I'll deploy your app" business. Turbopack is eating the "I'll optimize your build" business.
The response isn't to fight it. It's to recognize it, reposition faster than your competitors do, and own the next layer.
What I'd actually do
This week:
Audit your retainers. List every engagement that has "build" or "performance" or "CI/CD speed" in the description. For each, assess: "Does Turbopack 16.3 solve the core problem?" If yes, mark it for action.
Run a test upgrade. Spin up a Next.js 16.3 project with one of your client's codebases. Document the build times before and after. If they drop by >30%, you have evidence that the upgrade is valuable enough to warrant a project.
Segment your customers.
- Tier 1 (retainer >$5K/month, core to their business): Upgrade project + transition to a deeper engagement (CI cost optimization, deployment speed, monorepo strategy). Goal: same or higher revenue, deeper stickiness.
- Tier 2 (retainer $2K–$5K/month): Upgrade project, then sunsetting. The upgrade is the final engagement. Help them to Next.js 16.3 and document everything so they can maintain it.
- Tier 3 (retainer <$2K/month): Keep as-is until renewal. Then decide: upgrade and sunset, or hand off.
For new customers: Don't pitch "build optimization." Pitch "CI/CD cost reduction" or "deployment speed" or "monorepo strategy." The generic build optimization door just closed.
Author
Lukas
@lukcombinator