A green build is not a working app
The costliest migration failures pass the build and ship broken. A $2,500 audit finds where yours could, then a fixed-scope sprint fixes it, every fix behind a check proven to fail first.
Book a call (20 minutes)- 19.87sto4.77s-76.0%
- 7104msto359ms-94.9%
- 1578to689-56.3%
Migrating a legacy Webpack or CRA setup is where things quietly break.
Green builds that ship a blank page.
Security findings nobody wants to touch.
Thousands of dependencies, mostly unexplained.
Slow cold builds and dev server restarts.
The proof: a live migration on a public repository
We migrated the frontend of apache/answer, an Apache Software Foundation project, from Create React App to Vite; an adversarial review found three silent failures behind a green build. The Vite cutover is merged upstream and ships in the v2.0.3-RC1 pre-release: https://github.com/apache/answer/releases/tag/v2.0.3-RC1. Coding agents did the mechanical work and every change was reviewed by hand. Full method and findings: https://redfirst.dev/writing/three-silent-failures.
| Metric | Before | After | Change |
|---|---|---|---|
| Cold production build | 19.87s | 4.77s | -76.0% |
| Dev server time-to-ready | 7104ms | 359ms | -94.9% |
| HMR latency (edit to re-render) | 421ms | 139ms | -67.0% |
| Bundle size, total gzip (sourcemaps excluded) | 1652.24KB | 1474.34KB | -10.8% |
| Dependency count, total | 1578 | 689 | -56.3% |
| Audit findings (critical/high/moderate/low) | 4/78/63/13 | 1/50/38/6 | down across all four |
Measured on the original single-PR branch before the upstream split; HMR latency is carried forward from an earlier commit.
Two of these numbers are worse on purpose. We restored the production type check the first migration pass dropped, and put back the icon fonts it silently left out, then published the slower, heavier numbers. We would rather ship honest numbers than flattering, broken ones.
Start with the audit
The Modernization Audit is $2,500, capped at 8 hours, delivered inside 3 calendar days. It shows where your frontend could pass the build and still break.
100% of the audit fee credits against a sprint booked within 30 days.
Book the auditBooking starts with a 20-minute call to check stack fit.
Deliverables
- diagnosis
- baseline metrics
- risk map
- prioritized roadmap
- sprint estimate
After the audit: pick one door. Ten days. Fixed scope.
Webpack/CRA to Vite migration
React architecture rescue
Agent-ready repository setup
Founding engagement: $7,500. Standard engagement value: $12,500.
- 50% upfront.
- Scope cap of 24 to 30 hours.
- 10 working days.
As a founding client you provide repository access, one named person from day 0, rights to an anonymized case study, and a testimonial if satisfied. Founding pricing is capped to the first two engagements booked; every engagement after that runs at the standard $12,500.
The 10-day sprint
Kickoff: access, CI baseline, metric capture
Audit and risk map. Plan review call, scope locked.
Execution: agent fleet in worktrees
Tests and CI green
Benchmarks and docs
PR walkthrough call
Report, 90-day roadmap, retro call
Pull requests land daily from day 3. No big-bang merge at the end.
Measured before and after, every sprint
What we measure
cold build, warm build, dev server time-to-ready, HMR latency, bundle size, CI wall time, dependencies and audit findings, test suite time and pass rate.
The proof table shows five of the eight; warm build equals cold within noise, and the repository had no tests or CI.
What we report
human review hours, what the agents did, and every mistake caught before it reached you, the agents' own included.
You see the mistakes, not just the wins.
After the sprint
Ask about the ongoing modernization retainer once your sprint report is in hand.
About
Xan Torres. I'm a senior frontend and product engineer with 15+ years of frontend work, mostly React and TypeScript. I move frontends from CRA and Webpack to Vite, using coding agents through RepoKernel and its review gate, and I review every change myself. I'm based in Cyprus and work remotely.
FAQ
What happens if the work exceeds the scope cap?
The 24 to 30 hour cap is set at the day 1 to 2 plan review call; anything larger becomes a separately scoped follow-on, never a silent overrun.
How are agents used, and who checks their work?
Agents do the mechanical work. Every change is human-reviewed, and every fix lands behind a check proven to fail first.
What access do you need?
Repository read and write access, CI visibility, and one named contact.
What happens if you are unavailable mid-sprint?
Nothing sits only on my machine: you see pull requests in your repository from day 3 and keep every merged change if the sprint halts.
Is my stack a fit?
Best fit is React and TypeScript on Webpack or CRA, at a company running 5 to 50 engineers. Not sure? Start with the audit.