Why we picked Next 16 over Remix for our rebuild (and what immediately broke)

TL;DR — We seriously evaluated Remix. We still picked Next 16. The framework choice mattered less than we expected. The migration mattered more.

BrainFeed is a three-person agency serving AU/US/UK clients across SaaS, Shopify, WordPress, and mobile work. Earlier this year we made an overdue call: kill 14 WordPress installs and consolidate everything onto a single application. That app couldn't be a marketing site alone — it had to host the admin, multi-currency invoicing, the CMS for this blog, and eventually a client portal. One codebase, one deploy, one stack to keep current.

We gave ourselves two weeks to pick the framework. This post is what happened in those two weeks, and what immediately broke once we started shipping.

This article is for:

• Small engineering teams (1–5 people) picking a stack for a real production app
• Founders / CTOs evaluating Next.js vs Remix for a marketing + admin combo
• Anyone planning a WordPress (or other legacy stack) → modern JS rebuild this year

This article is NOT for:

• Teams choosing a framework for a pure-content marketing site (Astro will beat both of these)
• Engineers wanting a feature-by-feature comparison or a Lighthouse benchmark shootout
• Anyone hoping for a "Framework X is dead" hot take

The shortlist

We seriously evaluated two:

• Next 16 — App Router default, Turbopack default, Tailwind v4 alongside it.
• Remix (now React Router v7 framework mode) — same React skill base, different mental model, web-fundamentals philosophy.

Two more got ruled out fast:

• Astro — fantastic for content sites, but we needed real interactive admin with stateful flows. Not a fit for our admin.
• SvelteKit — we admire it from a distance; the team familiarity tax was too high for a 2-week decision window.

What actually mattered to us

These weren't the criteria a framework comparison blog would list. They were the criteria a small agency picking infrastructure under delivery pressure actually cares about. We didn't care whether one framework rendered a benchmark 12ms faster. We cared whether future us would regret the choice six months later.

Here's the scorecard we actually used. Five criteria, weighted by how often they'd hurt us if we got them wrong:

Three of the five tilted to Next, two tied. Nothing tilted to Remix on our weighting. That's not a feature comparison — that's a comparison of what would hurt us. Your weighting would look different; a team of senior backend engineers who already think in HTTP would likely tilt the other way.

Why we wanted them in one app at all

The instinctive alternative — Astro for the marketing site, a separate React app for the admin — would have meant two codebases, two deploys, two design systems to keep aligned, two hosting bills, two observability surfaces, and a real boundary across which sessions and user data had to cross.

For a team of three, every duplicated surface becomes operational overhead. Picking a framework that could host both behind one auth boundary wasn't a preference. It was a constraint.

Why Next 16 won

Three concrete reasons:

Server actions + nested layouts covered ~80% of our admin needs without extra libraries. Forms with progressive enhancement, optimistic UI, server-side validation — patterns that would have meant React Hook Form + a state library + a custom RPC layer in a prior generation already exist in the box. The amount of code we don't have to maintain matters more than the code we get to write.

Vercel's free tier covers the marketing site, and we can leave if we need to. Next 16 is genuinely portable — the lock-in is shallower than the discourse suggests, and self-hosting via the standalone build is well-trodden. Starting on Vercel gave us speed without burning a bridge.

Turbopack default makes dev DX actually fast. We switch contexts hourly between client work and our own codebase. A 200ms HMR vs an 800ms HMR sounds petty until you do it forty times a day.

Why Remix was a real contender

This is the section where most "we picked X over Y" posts get lazy. I want to be honest: Remix made us think hard, and there are things about it that may be architecturally cleaner than Next.

The web-fundamentals mental model. Remix's "use the platform" philosophy — <Form> posting to a route action, loaders that look like the request/response model the web has had since 1995 — is easier to reason about long-term than App Router's server-component/client-component dance. If you hire a senior dev who hasn't touched React in three years, they will be productive in Remix faster.

Nested routing with parallel loaders. Genuinely elegant. The kind of design where you understand it once and don't have to re-learn it across versions.

It feels less framework-y. Less time spent debugging why a thing rendered on the wrong side of the network boundary.

If we were building only a marketing site, Remix might have won. What tipped Next was ecosystem gravity — the SDKs, the auth libraries, the Stripe / Razorpay integrations, the boring third-party connectors all bias toward Next first. For an agency that needs to ship past the framework into the next layer of stack, that gravity matters.

What broke (and why it mattered)

This is the section the article is really about. We had a working app within the first week. We then spent the second week — and parts of the third — hitting things we'd assumed would work.

The rebuild itself moved quickly. The migration edges didn't. These weren't isolated bugs — they were assumptions that stopped being true.

The ecosystem moved faster than our assumptions

Tailwind v4 dropped the JavaScript config file. Theme tokens now live inside CSS via the @theme directive. Every Tailwind tutorial, every Stack Overflow answer, every example repo from 2023 is now misleading by default. Here's what the change actually looks like:

/* app/globals.css — Tailwind v4 */
@import "tailwindcss";

@theme {
  --color-brand-500: oklch(0.62 0.18 264);
  --color-brand-600: oklch(0.55 0.19 264);
  --font-display: "Inter", ui-sans-serif, system-ui;
  --radius-card: 0.875rem;
}

There is no tailwind.config.ts. There is no theme.extend.colors. If you're reading a tutorial that mentions either, it's for v3.

The migration itself was small — maybe an hour of work once we knew what to do. The cost was in discovery time: half a day of head-scratching at why the new config "didn't apply" before realizing the config doesn't exist anymore.

The docs were newer than the community

Next 16 middleware is well-documented. Every Stack Overflow answer about Next.js middleware was written for v13 or v14, and the patterns it shows are now actively misleading. Same for route handlers — the community caught up on App Router slowly, and the snippets you'll find via Google often pre-date stabilization.

We learned to read node_modules/next/dist/docs/ directly before writing anything new — the official docs ship with the package you've installed, which means they're correct for your version. Search results, by contrast, lag stable releases by months and surface a quietly-deprecated v14 answer next to a half-right v16 one. On a major-version-old-by-six-months stack, that's not a "mainstream framework" experience; it's an edge case discipline you have to build deliberately.

The defaults changed under our feet

fetch() is no longer cached by default in Next 16. In v14, the same call would have been opportunistically cached by the framework. We had a couple of places where we'd internalized the v14 behavior and were depending on caching that no longer existed:

// v14: implicitly cached by the framework
const data = await fetch(API_URL).then((r) => r.json());

// v16: hits the network every render unless you opt in
const data = await fetch(API_URL, {
  cache: "force-cache",
  next: { revalidate: 60 },
}).then((r) => r.json());

The new default is the correct default — caching by accident is a footgun in the other direction. But every internalized assumption from the v14 era is suddenly wrong, and the symptom isn't an error — it's "this dashboard is suddenly hitting the database on every render." The fix was easy once we noticed. Noticing took two days.

Everything became async

params, headers(), cookies(), searchParams — all async in Next 16:

// v14: synchronous
export default function Page({ params }: { params: { slug: string } }) {
  return <Article slug={params.slug} />;
}

// v16: async, and the function must be async too
export default async function Page({
  params,
}: {
  params: Promise<{ slug: string }>;
}) {
  const { slug } = await params;
  return <Article slug={slug} />;
}

This is the kind of migration change that quietly spreads across every route, every layout, every middleware boundary touching cookies or headers. The TypeScript errors are loud — but if you migrate gradually, every PR has a fresh batch of them. We solved it by doing all the async migrations in one concentrated afternoon rather than letting them dribble across feature work.

Tooling maturity still matters more than benchmarks

Turbopack is fast. Turbopack also silently assumed webpack behavior in some of our dependencies and surfaced as cryptic build errors in production but not locally. We spent the better part of an afternoon narrowing down which library was the culprit.

The boring infrastructure bug cost the most time

The most expensive bug of the whole rebuild had nothing to do with Next.

Drizzle-kit's migration journal — the file that tracks which migrations have been applied — stopped advancing past 0002 in our setup. New migrations would run db:migrate and report success. They weren't applying. The journal silently said everything was up to date.

The first time production expected a column that wasn't there was the moment we stopped trusting the migration journal. We now apply SQL files directly via a small wrapper script that reads each file and runs it, bypassing drizzle-kit's journal entirely. The wrapper is 40 lines. The bug took a full day to diagnose because everything looked like it was working.

I'll write this up properly in next week's post on the Drizzle runner — but the meta-lesson is the one worth surfacing here: the framework choice rarely costs you a day. The unglamorous tooling underneath it does.

What surprisingly didn't matter

While all that operational complexity was unfolding, some of the things framework discourse obsesses over barely mattered at all:

• Lighthouse scores. Both frameworks ship fast pages when configured competently. Neither shipped slow pages when we didn't configure them well.
• Benchmark wars. The "X is 30% faster than Y in this contrived render scenario" content didn't predict a single real performance outcome we saw.
• "Framework X is dead" discourse. Twitter has been declaring frameworks dead for a decade. None of them are.
• Theoretical routing elegance. Both routing systems are fine. You stop noticing within a week.

If we'd made this decision based on what dominates engineering Twitter, we'd have made the same pick — but for the wrong reasons.

What we'd do differently

One thing: we'd spend the first day of the decision window writing an actual checklist of operational criteria — the scorecard above, basically — rather than spending it reading comparison content. We arrived at the right criteria eventually, but later than we should have. Reading other people's takes is fine; it just isn't the work.

When you should pick differently

The scorecard above tilted to Next 16 for us. The same scorecard, with different weights, tilts elsewhere:

• Pure content site, blog, marketing-only → Astro will out-ship both of these for that specific job. Don't pick a JS framework when you don't need a JS app.
• Team prefers a web-fundamentals mental model over React conventions → Remix, genuinely. The "use the platform" philosophy is easier to defend long-term than the App Router model, and if your team's mental model already lives there, fighting it costs more than the ecosystem gains.
• You need server-streamed everything across complex nested routes → either works, but lean toward Next for the surrounding tooling.
• You're already running a Rails / Phoenix / Django backend and just need a thin frontend → don't pick either of these as your framework. You'll be writing a thin client; pick accordingly.

If you're picking Remix because it's the cooler-sounding answer in your engineering Slack, you're picking for the wrong reasons. If you're picking Next because everyone else does, same problem in the opposite direction. The scorecard exists so the decision isn't vibes.

The thesis

Six months later, the thing I want a younger version of myself to read is this: the framework choice mattered less than the migration plan.

We could have made this work on Remix. We could have made it work on Next 14. We couldn't have made it work without a migration plan that accounted for the fact that the ecosystem around the framework moves faster than the framework itself. Tailwind v4. Caching defaults. Tooling assumptions. Drizzle's silent failure.

Consolidating 14 WordPress installs was never really a framework problem. It was an operational complexity problem wearing a framework costume. If you're a small team rebuilding off whatever lived-too-long stack you're currently on, spend your decision energy on the migration, not the framework. The framework will be fine.

If you'd like a partner on the migration itself, that's the kind of work we do at BrainFeed: web design + development for SMB SaaS and commerce teams.

Next in this series: how Drizzle's migration journal silently stopped applying changes, and the 40-line runner we wrote to bypass it. After that: the year-long story of killing 14 WordPress sites and consolidating to one Next app.