If Swapping React Meant Rewriting Your App, You Never Had an Architecture

Watch the 40-second version: Q9: Stop Picking Frameworks First in Interviews

There is a moment in every system design interview where a candidate leans in and starts their answer with "well, I'd use Next.js for this." And there is a moment, about three seconds later, where the interviewer quietly downgrades the hire signal. That is not a framework debate. That is a smell test, and you just failed it.

Frameworks are details. Somebody else's details. When you start your architecture from the framework, you are not designing a system. You are decorating one that was already designed for you, by someone who has never met your users. And then one day React deprecates the API half your components are built on, and you discover the truth: you do not have an app with a framework in it. You have a framework with your app trapped inside.

Here is the part nobody tells you. The interviewer is not testing whether you know the framework. They are testing whether you know where it ends. A candidate who can recite five Next.js caching behaviors but cannot say which components are pure presentation is a candidate who writes business logic inside useEffect and calls it architecture. I have inherited those codebases. They all read like the same crime novel.

The fix is boring, which is how you know it works. Think in seams, not stacks.

The Swap Test (steal this for your next review):

1. Could you unit-test your core business logic without mounting a single component?
2. Is your framework code isolated behind thin adapters, or sprinkled across 40 components like seasoning?
3. Do your components contain rules about money and permissions, or only about pixels?

If the honest answer to any of those is no, your framework is load-bearing, and load-bearing frameworks are a migration bill with interest.

A tiny pattern that enforces the seam. Your components should never import a framework-specific API for data work. Wrap it once:

// adapters/http.ts — the ONLY file that knows what fetch wrapper you use
export interface ApiClient {
  get<T>(path: string): Promise<T>;
  post<T>(path: string, body: unknown): Promise<T>;
}

// features/checkout/pricing.ts — pure logic, zero framework, testable in isolation
export function applyDiscount(subtotal: number, coupon: Coupon): number {
  if (!coupon.valid) return subtotal;
  return Math.max(0, subtotal - coupon.amount);
}

pricing.ts can be tested with node. No DOM, no hooks, no framework. The component renders the number, the adapter moves the bytes. Swap the framework tomorrow and you rewrite the adapters, not the app.

So next time someone asks how you would architect something, resist the urge to name the stack first. Name the seams. That is what interviewers are actually scoring, and it is the only answer that survives the next framework.

This is question 9 of 60 in the Frontend System Design Interview Playbook. The full set of answers, with the ones interviewers actually grade, is here: https://bittalk.gumroad.com/l/frontend-interview-playbook