We have a split between Rails pages, a monolithic React UI, and a smear of React microfrontends. We want to consolidate on a single pattern. Which should we adopt? 10 year old product, team of 30 engineers.

Sonar Pro

Vote: React Monolith

I maintain my vote for **React Monolith (B)**. The Round 1 arguments from others reinforce this: all but one (Grok 4.1 Fast) chose B, citing MFE overhead and Rails limitations for 30 engineers[1][2][3]. No new arguments shifted me. **Grok's Rails (A) pitch fails scrutiny:** Rails minimizes disruption but ignores why React was adopted—likely for SPA interactivity in a 10yo product. Hotwire helps, but forcing React back into Rails bridges risks UX constraints and hiring issues in a React-dominant ecosystem[1]. Search results show monoliths reverting from MFEs due to coordination hell, not Rails wins[1]. **MFEs (C) unfit for 30 devs:** Sources confirm MFEs suit 100+ engineer orgs with autonomy needs; here, they amplify 'smear' chaos (analytics, deps, deploys)[1][2][3][5]. Perf risks, version skew, and bundle bloat outweigh gains—teams revert to monoliths[1][4]. **B wins on evidence & migration:** Existing React monolith + expertise makes B lowest-risk consolidation. Incremental Rails-to-React migration via API, absorb MFEs. Unified DX, fast builds (code-split), scalable to growth[1][3]. Monolith simplicity trumps MFE complexity at this scale[1][6].

Grok 4.1 Fast (changed mind)

Vote: React Monolith

Initially voted A for minimal disruption and Rails' full-stack simplicity, but the unanimous B arguments convinced me: the existing monolithic React UI and MFE 'smear' indicate substantial React investment already made—rewriting it to Rails would be costlier than migrating Rails pages into React. For 30 engineers, B unifies frontend without MFE overhead (dupe deps, integration hell) or Rails' UX limitations (client-state pains). Modern monolith scales via modules/lazy-loading; hiring favors React expertise. Claude Opus 4.6's migration path sealed it: absorb MFEs, incrementally port Rails—lowest risk to single pattern. Rails forces abandoning React momentum; C worsens chaos. B maximizes velocity/consistency.

GPT-5.4

Vote: React Monolith

I’m keeping my vote on B: React Monolith. The other B arguments reinforced the same core point: this is primarily a complexity-management decision, not a purity decision. For a 30-engineer team, microfrontends are disproportionate overhead, and your current “smear” is already evidence of that. They optimize for high autonomy across many teams, but impose costs in dependency governance, routing, shared UX, testing, and runtime integration. The Rails argument is the only real alternative, but it still doesn’t beat B here. Its strongest point is migration risk and leveraging the existing legacy investment. That matters. But standardizing on Rails as the product-wide frontend pattern likely means either constraining richer client-side experiences or rebuilding toward modern interactivity through Rails-side hybrids anyway, which risks reintroducing the same inconsistency under a different label. Claude’s point was especially strong: a well-structured monolith preserves an escape hatch. It is much easier to extract bounded frontend domains later from a disciplined React monolith than to clean up a fragmented microfrontend landscape now. That makes B the best long-term default while keeping future options open. So the practical answer remains: one React app, strong internal module boundaries, shared design system, shared routing/state conventions, and incremental migration of Rails pages and existing microfrontends into that single surface.

Gemini 3.1 Pro

Vote: React Monolith

I am standing firm on Option B (React Monolith), which the vast majority of us agree is the optimal path. Grok 4.1 Fast makes a fair point about the simplicity of Rails and the potential of Hotwire/Turbo. However, consolidating entirely onto Rails would require rewriting the existing React Monolith and the microfrontends back into server-rendered templates or Hotwire bridges. This is swimming against the tide of the team's existing skill sets and the industry standard for rich client-side interactivity. It also severely limits the frontend UX capabilities compared to a dedicated React app. Option C (Microfrontends) remains a poor choice. As Kimi K2.5 and Claude Opus 4.6 highlighted, microfrontends are an organizational scaling solution for massive teams, not a technical silver bullet. For 30 engineers, the deployment orchestration, version skew, and tooling overhead will grind feature development to a halt. A React Monolith (Option B) hits the exact sweet spot. It provides a unified developer experience, straightforward dependency management, and a single build pipeline, while allowing the team to cleanly separate the frontend architecture from the backend. The team can progressively migrate the legacy Rails pages and easily absorb the scattered microfrontends back into a unified, modular React application. This is the most pragmatic, lowest-risk path to consistency and high velocity.

Claude Opus 4.6

Vote: React Monolith

I'm maintaining my vote for React Monolith. The deliberation overwhelmingly confirms this is the right call — 5 out of 6 models independently arrived at the same conclusion, which is notable. **Grok's Rails argument doesn't hold up.** The claim that Rails with Hotwire/Turbo 'delivers interactivity without JS sprawl' understates the gap. If the team already has substantial React investment — components, libraries, expertise — migrating *back* to Rails means throwing away that work and relearning patterns. Hotwire is impressive for what it does, but it doesn't match React's component model for complex, stateful UIs. The team moved to React for reasons; those reasons haven't disappeared. And the hiring argument matters: frontend engineers overwhelmingly expect to work with React/TypeScript, not Stimulus controllers. **The consensus case is strong and consistent.** Every pro-B argument converges on the same points: 30 engineers is too small for microfrontend overhead, Rails constrains modern UX expectations, and a React monolith provides the simplest migration path (keep Rails as the API layer, progressively move views into a single React app). The migration is incremental rather than big-bang — you can route old Rails pages to the React shell one by one. **The practical path forward is clear:** Absorb the microfrontend fragments back into one React application, establish clear module boundaries within it (feature folders, shared design system, unified routing and state management), and convert remaining Rails views incrementally. One build, one deploy, one set of conventions. This is the consolidation pattern that actually reduces complexity for a team of this size.

Kimi K2.5

Vote: React Monolith

Despite Grok's appeal to Rails simplicity, returning to server-rendered pages would squander the team's existing React investment and expertise. After ten years, the product likely has complex client-side requirements that Hotwire/Turbo struggle to match compared to a mature React ecosystem. Reverting also forces a costly rewrite of the working monolithic React UI you already have. Microfrontends (C) remain premature for 30 engineers. The 'smear' of MFEs is precisely the problem—consolidating into more microfrontends amplifies the operational chaos rather than solving it. You don't have the organizational scale (100+ engineers) to justify the deployment complexity, version skew risks, and shared dependency nightmares. The React Monolith (B) is the only pragmatic consolidation target. You already possess one; absorb the scattered MFEs back into it and incrementally migrate legacy Rails views. This yields a single build pipeline, unified state management, and one design system without the coordination overhead of distributed architectures. At 30 engineers, a well-modularized monolith with code-splitting provides optimal velocity and maintainability.

Final Summary

The AI Roundtable overwhelmingly backed the React Monolith as the pragmatic middle ground for a team of 30, avoiding both the 'orchestration hell' of microfrontends and the perceived regression of returning to pure Rails. While Grok 4.1 Fast initially held out for a Rails-only approach to minimize disruption, it eventually joined the consensus after Claude Opus 4.6 and others argued that the team’s existing React investment made a monolith the most logical and modern consolidation target.

All 6 models agreed on "React Monolith" after discussion

Strongest Arguments

• Rails: Consolidating on Rails minimizes disruption to a stable 10-year-old codebase and leverages full-stack simplicity through modern tools like Hotwire/Turbo.
• React Monolith: A React Monolith eliminates the 'coordination hell' of microfrontends and the UX limitations of server-rendered pages, providing a single build pipeline that is manageable for 30 engineers.

Key Turning Points

• Claude Opus 4.6 highlighted that a well-structured monolith preserves an 'escape hatch' to extract microfrontends later if the team grows to 100+, but that implementing them now is premature.
• Grok 4.1 Fast abandoned its support for Option A after realizing the 'momentum' of the existing React work made a return to Rails more expensive than consolidation.