The Stack Argument
The migrate-filemaker skill had a solid tech stack decision matrix. It scored candidates objectively: PostgreSQL vs MySQL vs SQLite, FastAPI vs Express vs Django, React vs Vue vs server-rendered. Pick your language, score the criteria, recommend the highest. Neutral. Thorough. Safe.
The developer wrote two documents that change the framing. Not minor edits. A complete reframing of the Phase 3 recommendation from "here are the options, score them" to "here is the strategically correct default, and here is the evidence for why."
The two documents
The Case for Server-Side MVC is the argument. It opens with scale evidence: Shopify processes 489 million requests per minute on Rails. Instagram scaled to hundreds of millions of users on Django with three engineers, two of whom had no backend experience. Pinterest handles 200 billion pins on Django. GitHub runs on Rails. These are not small applications making do with limited technology. Server-side MVC is a production-grade architecture with no practical ceiling.
The document then walks through the architectural analysis: one codebase versus two, the state synchronization problem that React creates and React Query exists to manage, the useEffect hook as the single most common source of bugs in React applications. Performance gets a counterintuitive treatment: a server-rendered page delivers complete HTML on the first request while React bundles routinely exceed 400 to 800KB gzipped before business logic is added. React Server Components, introduced in React 19, move rendering back to the server — an implicit admission that client-side rendering was the wrong default.
The total cost of ownership comparison is stark: twelve to fifteen decisions before writing the first feature versus two to four. Two codebases to maintain versus one. Two deployment pipelines versus one. State sync libraries versus none. Typical hosting of forty to a hundred dollars per month for frontend plus API versus ten to twenty for a single server.
Web App Stack Comparison is the evidence grid. Eight categories mapped across React/Next.js, Rails, Laravel, and Django: architecture, database and ORM, authentication and authorization, frontend and UI, background jobs and email, file storage and testing, admin and deployment, and decision count. In nearly every cell, React is "you decide" or "must build" while the MVC frameworks are "built-in." Auth is NextAuth/Auth0/Clerk/JWT versus Devise, Breeze, or django.contrib.auth. Background jobs are BullMQ or nothing versus Active Job plus Sidekiq, Laravel Queues, or Celery. Admin panel is build from scratch versus ActiveAdmin, Nova, Filament, or the Django admin. The grid makes the argument visually: every decision you outsource to a future developer is a maintenance bet you lose eventually.
What changed in the skill
The tech stack decision matrix is still there. The scoring framework still works. But the recommendation now carries an opinion backed by evidence. When Phase 3 recommends a stack, the default answer for most FileMaker migrations is an MVC monolith — Rails if you think in Ruby, Laravel if you think in PHP, Django if you think in Python. The framework's native interactivity layer handles dynamic UI: Hotwire for Rails, Livewire plus Alpine.js for Laravel, HTMX plus Alpine.js for Django.
React only surfaces when the discovery phase reveals genuinely complex client-side interaction that Hotwire, Livewire, or HTMX cannot handle — real-time collaborative editing, offline capability requirements, or complex client-side computation. This is rare for internal business applications. FileMaker solutions are forms and tables and reports. The ceiling is never the framework.
Both documents now live in the migrate-filemaker repository as reference material for the Phase 3 recommendation step. The skill references them alongside the decision matrix. The argument is documented. The evidence is cited. The recommendation has teeth.
The full documents are published as standalone reference pages: The Case for Server-Side MVC and Web App Stack Comparison.
Why this matters for the skill
Before this update, the skill could recommend a stack but would not push back if a client said "we want React." The matrix scored React well on complex UI criteria. The recommendation would note the tradeoffs but accept the preference.
Now the skill has a documented position with evidence. If a client says "we want React" for a fifteen-table internal business app, the discovery phase can surface the TCO comparison. The recommendation can reference Shopify's scale on Rails and Instagram's on Django. The argument is not "React is bad" but "React solves a problem you do not have."
The developer's framing is precise about when React is the right choice: highly interactive real-time collaborative interfaces, offline capability requirements, or complex client-side computation. Tom MacWright, who built editors for Mapbox Studio and Observable, identified the sweet spot as moderately interactive interfaces that need immediate feedback. A B2B SaaS product managing records and running reports does not live in that sweet spot.
What the skill does not do
It does not debate frameworks. The recommendation is explicit: choose by language, not by framework. Rails, Laravel, and Django differ in syntax and ecosystem but converge on the same architectural pattern. The language your team already knows is worth more than any framework feature comparison.
It does not predict failure. The documents acknowledge that React applications work at scale. The argument is about time to market and total cost of ownership, not technical viability. A React SPA can serve a B2B SaaS perfectly well. It will cost more to build, more to maintain, and more to host. Whether that tradeoff is worth it depends on whether the application actually needs what React provides.
It does not claim the interactivity gap is fully closed. Hotwire, Livewire, and HTMX handle the interactive patterns that internal business apps need: inline editing, live search, sortable tables, modal dialogs, partial page updates. They do not handle Figma. If an application genuinely needs Figma-level interactivity, React is the correct choice. The skill now knows how to distinguish between those two categories.