Case Study3 min read588 words

Case study: rebuilding a 4-year-old React app in 2 weeks

How I rebuilt a 4-year-old React app stuck on React 16 + class components in 2 weeks — the strategy that avoided a 'big bang' rewrite, the things we kept, and the regression that almost shipped.

Client had a React 16 app from 2022. Class components. Redux with thunks. Webpack 4. No tests. Worked, but every change took 3x what it should and onboarding new devs took weeks. They wanted a "rebuild," budget for 2 months.

We did it in 2 weeks. Here is how.

The first decision: what is actually broken

Most clients say "rebuild" when they mean "I'm frustrated with the dev experience." We did an honest audit on day 1:

  • Backend API: fine. Don't touch.
  • Auth, payments, integrations: fine. Don't touch.
  • Routing: outdated but working. Replace later, not now.
  • State management: Redux + thunks. Painful but not actively broken. Migrate one slice at a time.
  • Component library: home-grown, inconsistent. The real problem.
  • Build pipeline: Webpack 4, 90s cold builds, no HMR. The other real problem.

So the rebuild was actually: replace the component library, replace the build pipeline. Everything else stayed.

Week 1: Vite + Tailwind + shadcn

Day 1-2: Set up a parallel Vite dev environment. The old Webpack one stayed running for production. We could now develop in 200ms HMR while still shipping from the old pipeline.

Day 3-5: Picked shadcn-style components as the new system. Wrote 8 base components (Button, Input, Card, Dialog, etc.) that matched the brand. Documented their API in a single Notion page.

Day 6-7: Migrated 3 critical screens from the old component library to the new one. Goal: prove the pattern works end-to-end. It did.

Week 2: the long tail

Day 8-10: Mass migration of remaining screens. Two devs, parallel branches, one screen per dev per day. Old class components stayed; only the UI was swapped.

Day 11-12: Replaced the build pipeline entirely. Webpack → Vite for production. Lost two days to a CSS import order issue that only manifested in production builds.

Day 13: Smoke testing. Found a regression where a date picker was rendering with the user's local timezone instead of UTC. Almost shipped it. Caught by a manual test in week 2 of QA.

Day 14: Deploy and monitor.

What we did NOT rebuild

  • Redux store (kept entirely)
  • API client (kept entirely)
  • Authentication flow (kept entirely)
  • Database layer (untouched, server-side)
  • Routing structure (kept; planned replacement for Q2)

Roughly 60% of the codebase was unchanged. The 40% we touched was the 40% the dev team was complaining about.

What I learned

1. Big-bang rewrites fail because they couple every risk into one release. Doing the build pipeline + components together was risky enough; including state management would have killed the timeline.

2. The "old, ugly, but working" parts are often fine. Class components feel dated; they also work. Don't migrate purely for aesthetics.

3. Parallel dev environments are the secret weapon. Being able to ship from the old pipeline while developing in the new one removed the schedule pressure.

4. The QA week is what catches the timezone bug. Don't ship a rewrite without a real testing window, even if everything seems fine.

The numbers

  • 2 weeks build (2 devs)
  • 4 days QA (1 dev + the client)
  • ~$28k total cost
  • Cold build time: 90s → 1s
  • HMR: didn't work → instant
  • Developer satisfaction (their words): "I want to come to work again"

The client originally budgeted 2 months and $80k for a "full rebuild." Saving them 6 weeks and $50k while delivering the actual win they wanted is the most underrated thing freelance developers can offer over agencies.

Frequently asked

Common questions

Should I rebuild or refactor an old React app?
Refactor if the structure is sound and the business logic is well-tested. Rebuild if the framework version is 3+ behind, the test coverage is minimal, and the design system is unfixable. Most apps that 'need a rebuild' actually need a refactor.
Work with me

Need this built rather than read about?

I'm a solo developer who scopes, designs, builds and deploys the whole thing. Send a few sentences about your project and you'll get an honest read on scope, timeline and price — usually the same working day.

Written by
Oxymore

Oxymore is a one-person studio shipping MVPs, landing pages, React apps and Telegram bots for founders who would rather move than meet.

Last updated