Killing Micro Frontends How Radical Simplification 10x'd Our Frontend Velocity - Nicolas Beaussart

Technological problem diagnosed (why the team wanted to change)

• Micro frontends / distributed frontend caused coordination cost: teams were “independent” until a feature spanned many repos.
• CI and releases were too slow and risky:
  • Example at PayFit:
    • CI ~45 minutes (often flaky)
    • Shipping 2–5 days
    • PR-to-production ~1 week
  • Deploys happened only ~twice/week due to fear and coordination overhead.
• Worst-of-both-worlds architecture:
  • Monolith-like coupling + micro-frontend-like coordination
  • A “distributed battle of mud” that caused dread and slow delivery.

Initial situation at PayFit (what was actually in place)

• Multiple micro-frontend implementations in the same frontend, including:
  • NPM-published packages
  • iframe-based approaches
• Highly fragmented build setup:
  • 32 GitHub repos to build one frontend app
  • Legacy monorepo attempts existed, including failures due to mandate
  • 6 different bundlers inside the legacy monorepo
• Tooling as the root issue:
  • “Lack of trust and platformization.”
  • Earlier monorepo was imposed; ownership became unclear and developer experience suffered, so teams abandoned it.

“Radical simplification” strategy (tech + organizational trust)

Core bet: remove variation, unify tooling, automate delivery, and make adoption prove-based (not mandate-based).

1) Standardize the repo/platform foundation

• Consolidate into a single monorepo and unify tooling.
• Move everything to Vite:
  • Enforce a single configurable baseline so config drift doesn’t happen
  • Prevent regression of third-party dependency versions (progressive unification)
• Third-party dependency unification:
  • Teams were stuck on old versions (e.g., React 16, old Redux)
  • They found 100+ third-party libraries and multiple major versions loaded in the same app
  • Enforced version correctness to avoid “import order” ambiguity in local dev

2) Improve developer experience (DX) and platform usability

• Hot reload back in the unified monorepo (faster local feedback; less full rebuild pain).
• Treat platform work as product work:
  • Documentation + searchable internal docs
  • Used Starlight (Astro) to scope search to the frontend docs (not whole enterprise)
• Use Nx to provide:
  • Task inference (correct build/lint/test targets out of the box)
  • Dependency graph to understand the repo
  • Conformance checks to prevent tooling/version regressions
  • Generators so new libs/stories start from the “golden path”

CI performance wins (proof points)

• Evaluate Nx Cloud for:
  • Distributed caching
  • Task parallelization
  • Affected-task execution (run only what matters)
• Reported impact (key metrics):
  • Saved ~5 years of compute in CI in the prior year (2,001 days, 48,000 hours)
  • CI time dropped from ~45 minutes to ~7 minutes
  • Worst-case P95 for full repo: ~20 minutes (~894 tasks)

Flaky test visibility

• Nx Cloud surfaced:
  • Flaky test rate
  • wasted hours
  • which tests fail
• Result:
  • Used stats to push teams to fix high-impact flakiness

Replace manual coordination with measurable automation (“cargo-cult” removal)

Problem: manual release queue + human ceremony

• Releases were gated by a Google Doc queue:
  • PR readiness → queue entry → manual branch updates → manual approvals for dev, staging, production
  • Lead time: ~3 hours avg (best case ~55 minutes)

Solution: GitHub merge queue via Mergify

• Measured and replaced the gate:
  • Keep safety via signals (rollback, overrides, failure behavior)
  • Remove ceremony that didn’t justify itself
• New flow:
  • Add a label to PR → Mergify merges automatically after queueing
  • Deploy dev + staging in parallel
  • Use synthetic tests on staging before prod
• Reported impact:
  • PR merge/release loop: ~20–25 minutes (down from ~3 hours)

Parallel queues feature

• Mergify created draft merge PRs that combine concurrent PRs so they can be merged together when safe.
• Outcome:
  • Humans no longer managed queue order
  • CI runtime still mattered, but throughput improved and worst-case stayed bounded

Code review process: reduce rubber-stamping

• They measured review load was wasteful:
  • In a sample: ~1 in 4 PRs required ≥2 teams
  • Resulted in review fatigue and larger, harder PRs
• Changed model:
  • Default notify (you’ll see changes that touch your code) but not required to approve
  • Default approval: only one engineering approval
  • Optional second approval if needed
  • For “critical files,” require stricter review
  • For incidents, PRs with urgent labels can bypass normal review rules
• Goal:
  • Keep safety signals, reduce coordination overhead (not “fewer reviews” blindly)

Frontend architecture simplification: routing overhaul

Legacy routing pain

• ~286 routes with tangled routers nested across components/libs
• Unsafe usage of location state (refresh could break pages)
• Multiple router setups, including “server routers” for panels vs main router concepts
• Routing drift over ~5 years; React Router v5 era

Migration choice: TanStack Router

Reasons:

• Pure SPA (no need for server-side rendering / RSC)
• End-to-end type safety for routes, params, search, and links
• Better long-term DX and search param patterns
• TanStack ecosystem alignment (query/form/table/etc.)

Cleanup before migration

• Flatten routing into fewer files; remove sub-routers in leaf components
• Stop relying on location.state (even enforced via TypeScript type patching)
• Remove model-specific router setups; single router source of truth

Strangler-fig migration (facade + incremental switching)

• Big rewrite didn’t work, so used a facade:
  • Put TanStack Router behind a catch-all route while legacy app handled most routing
  • Migrate top-level routes one-by-one while coexistence continued

Key technical workaround: keep React Router APIs working during transition

• Running TanStack Router + React Router broke URL sync assumptions.
• Built a router facade using TanStack Router plus a custom useRouter/history integration so React Router hooks effectively map to TanStack Router:
  • useLocation
  • useNavigate
  • links
• Migration loop:
  • Build routes in TanStack Router (type-safe)
  • Replace React Router usage page-by-page
  • Remove facade when finished

Bug-finding benefits

• Finding > 20 query param bugs, including:
  • mismatched read/write params
  • incorrect link query params
• Also found:
  • dead links
  • conflicting search params types
  • hidden race conditions in navigation handling
• Conclusion:
  • the router swap exposed correctness issues, not just refactor effort

Business/engineering results they report

• Deploy frequency increased massively:
  • ~225 deploys → ~4,040 deploys
• Frontend delivery time:
  • CI ~45 min → ~7 min
  • Release loop ~20–25 min
• Productivity: claims up to 10x, corrected to 17x
• Performance:
  • -92 MB JavaScript bundle size
  • ~5 seconds faster load time
• Team sizing:
  • Achieved “all of this” with ~2.5 engineers (plus collaboration)
  • Repo scale later described as:
    • ~94–95 monthly contributors
    • ~22 teams
    • 126 libraries

Transferable lessons they emphasize

• Never mandate; prove: monorepo failed when imposed, succeeded when teams saw value first.
• Fix the house before inviting guests: platform health, docs, tooling before migration.
• Measure “cargo cult” ceremony:
  • rollbacks/overrides/signal vs waste
  • keep safety; delete the rest
• Migrate clusters, not repos/boxes:
  • repo boundaries ≠ change boundaries
  • dependency graph shows what actually moves together
• Trust was the hardest problem, solved by making the platform visible and credible.

Main speakers / sources (as stated)

• Nicolas Beaussart (appears in title; referred to in subtitles as Nicolas Barrachin / Nicolas Beaussart)
  • Speaker identity given: Nicolas Barrachin, Senior Staff Engineer at PayFit
• Mentioned/related:
  • Tanner (will talk about TanStack Router tomorrow)
  • Dominic (talking about Knip tomorrow)