paulserban.eu

Writing Edition

Paul Serban

Writing, snippets & book notes

Vol. 2026

July 31, 2026

Leading Tech Infrastructure Modernization as a Lead Fullstack Engineer: A React and Next.js Playbook

How senior engineers can shape architecture, drive stack modernization, and build lasting technical strategy without a VP title

Introduction

Most conversations about "engineering leadership" assume a title change: you become a manager, an architect, a staff engineer with a mandate. But a large share of real technical leadership happens earlier and more quietly, exercised by lead fullstack engineers who never stop writing code. If you are the person maintaining a React and Next.js codebase, reviewing most of the pull requests, and fielding questions from newer engineers about "how things work here", you are already doing leadership work - the question is whether you are doing it deliberately or by accident.

This distinction matters because infrastructure and architecture decisions compound. A routing convention chosen in year one of a Next.js app dictates how teams structure code in year three. A data-fetching pattern adopted without discussion becomes the default that fifteen engineers copy-paste from. Leadership at this level is not about grand redesigns; it is about recognizing which decisions are load-bearing, and being deliberate about them before they calcify into legacy constraints. This article lays out concrete practices - technical, organizational, and communicative - that a lead fullstack engineer can use to modernize a stack, shape architecture, and build durable technical strategy, using React and Next.js as the running example because of how common that stack has become in production web applications.

The Problem: Technical Debt Without a Mandate

Most lead engineers inherit a system rather than design one from scratch. The React application predates hooks, or predates the Next.js App Router, or mixes three different state management libraries because each was introduced by a different tech lead who has since moved teams. This is not a failure of any one person; it is the natural result of software evolving under deadline pressure without a continuously maintained architectural vision. The problem a lead engineer faces is not "what is the ideal architecture" - that question has a reasonably well-understood answer in most cases - but "how do I move a live system with real users and real deadlines toward that architecture without a mandate to stop feature work".

This is compounded by the fact that a lead fullstack engineer typically does not control headcount, cannot unilaterally block releases, and often does not have "architecture" formally listed in their job description. Influence has to be earned through demonstrated judgment rather than asserted through authority. Engineers who try to force modernization through decree - rewriting large parts of the codebase without buy-in, or introducing a new pattern in isolation - tend to create parallel systems that never fully replace the old one, doubling maintenance burden instead of reducing it. The real skill is sequencing: identifying which pieces of technical debt are actively costing the team velocity or reliability, and which are cosmetic preferences that do not warrant the disruption of a migration.

A second dimension of the problem is drift between the explicit and the tacit architecture. On paper, a team might describe its Next.js application as using server components, colocated data fetching, and a shared design system. In practice, half the routes were written before the migration to the App Router completed, some data fetching still happens in useEffect hooks left over from the Pages Router era, and the design system is inconsistently applied because no one enforces it in CI. Leadership in this context means closing the gap between the architecture-as-described and the architecture-as-lived, and doing so incrementally enough that the system never becomes unshippable mid-migration.

Deep Technical Explanation: What "Architecture" Means in a React/Next.js Context

When people say "shape the architecture" for a React and Next.js application, they usually mean decisions across a handful of concrete axes: rendering strategy, data flow, module boundaries, and build/deploy pipeline. Understanding these axes precisely is what separates a lead engineer who can make defensible calls from one who is just expressing taste.

Rendering strategy in Next.js is the most consequential axis because it is difficult to change later without touching nearly every page. The App Router (introduced in Next.js 13 and stabilized in subsequent releases, as documented at nextjs.org/docs) supports React Server Components by default, meaning components render on the server unless explicitly marked with the "use client" directive. This changes the fundamental question a lead engineer asks when reviewing a new component: not "does this work" but "does this need to run in the browser at all". A data-heavy dashboard component that only reads and displays data has no reason to ship JavaScript to the client; a component with onClick handlers or useState does. Getting this boundary right is the single highest-leverage architectural decision in a modern Next.js codebase, because it directly determines bundle size, time-to-interactive, and how much of the application's logic can be tested and reasoned about without a browser.

Data flow is the second axis. Prior to server components, most React applications converged on client-side data fetching libraries - TanStack Query (formerly React Query) and SWR are the two most widely adopted, both providing caching, revalidation, and request deduplication on top of fetch. With the App Router, a meaningful share of that fetching can move to the server, using fetch with Next.js's extended caching semantics, or ORMs like Prisma queried directly in server components. The architectural decision a lead engineer needs to make explicit is: which data still needs client-side fetching (because it is interactive, user-specific, or needs background revalidation) and which can be resolved server-side. Leaving this ambiguous results in duplicated fetching logic and inconsistent loading states across the application.

Module boundaries are the third axis and the one most directly tied to team scaling. As a codebase grows past a handful of contributors, the absence of enforced boundaries between features leads to circular dependencies and components that reach across domain boundaries to grab state they should not know about. Patterns like feature-based folder structures, combined with lint rules (ESLint's import/no-restricted-paths or similar) that physically prevent cross-feature imports, turn architectural intent into something the build enforces rather than something documented in a wiki page nobody reads.

Implementation: Practical Patterns for Driving Modernization

Turning architectural judgment into actual change requires patterns that reduce risk. The strangler fig pattern - gradually replacing pieces of a legacy system while the old system continues to run, popularized by Martin Fowler - maps directly onto Next.js migrations. Rather than rewriting a Pages Router application into the App Router in one branch, a lead engineer can run both routers side by side, since Next.js explicitly supports incremental adoption of the App Router alongside an existing pages/ directory. New routes get built in app/; old routes are migrated only when they need to change anyway, tying migration cost to work that is happening regardless.

A second practical pattern is establishing a "paved road": a small number of sanctioned ways to do common tasks, backed by generators or templates, so that engineers do not have to make architectural decisions from scratch on every feature. Below is a simplified example of a typed data-fetching hook that standardizes how the team calls internal APIs, reducing the surface area for inconsistent error handling or cache configuration.

// lib/api/useApiQuery.ts
import { useQuery, UseQueryOptions } from '@tanstack/react-query';

interface ApiError {
  code: string;
  message: string;
}

async function fetchJson<T>(url: string, init?: RequestInit): Promise<T> {
  const res = await fetch(url, {
    ...init,
    headers: { 'Content-Type': 'application/json', ...init?.headers },
  });

  if (!res.ok) {
    const body = (await res.json().catch(() => null)) as ApiError | null;
    throw new Error(body?.message ?? `Request failed with status ${res.status}`);
  }

  return res.json() as Promise<T>;
}

export function useApiQuery<T>(
  key: readonly unknown[],
  path: string,
  options?: Omit<UseQueryOptions<T, Error>, 'queryKey' | 'queryFn'>
) {
  return useQuery<T, Error>({
    queryKey: key,
    queryFn: () => fetchJson<T>(path),
    staleTime: 30_000,
    retry: 1,
    ...options,
  });
}

This is deliberately unglamorous. Its value is not in any clever technique but in the fact that every engineer on the team now has one obvious place to look when they need to call an API from a client component, with error handling and cache defaults already decided. Multiply this by a handful of similar conventions - one way to define a form with validation (commonly via React Hook Form and Zod together), one way to structure a server action, one way to write a feature module - and the codebase becomes legible to new contributors without a lengthy onboarding document.

A third pattern is instrumenting the migration itself. Before removing a legacy pattern, a lead engineer should be able to answer "how much of the codebase still uses this" with a number, not a guess. A simple script run in CI can track this over time:

import re
import subprocess
from pathlib import Path

LEGACY_PATTERN = re.compile(r"getServerSideProps|getStaticProps")

def count_legacy_usages(root: str = "pages") -> dict[str, int]:
    counts: dict[str, int] = {}
    for path in Path(root).rglob("*.tsx"):
        text = path.read_text(encoding="utf-8")
        matches = LEGACY_PATTERN.findall(text)
        if matches:
            counts[str(path)] = len(matches)
    return counts

if __name__ == "__main__":
    usages = count_legacy_usages()
    total = sum(usages.values())
    print(f"Legacy data-fetching usages remaining: {total} across {len(usages)} files")
    # Fail CI if the count increases beyond a tracked baseline, forcing
    # new code onto the App Router pattern instead of the legacy one.

Tracking this number publicly - in a dashboard, a recurring Slack post, a section of a README - turns an abstract "we should migrate" into a visible, shrinking metric that gives the rest of the team a sense of progress and gives you, as the lead engineer, a concrete artifact to point to in planning conversations.

Trade-offs and Pitfalls

No architectural decision is free, and part of technical leadership is being honest about what a given choice costs, not just what it buys. Server components reduce client bundle size and can simplify data fetching, but they also introduce a genuinely new mental model: engineers used to thinking of "a React app" as a single runtime environment now have to reason about server and client boundaries explicitly, and mistakes here are not always caught by TypeScript - passing a non-serializable prop (a function, a class instance) from a server component to a client component fails at runtime, and the error messages, while improved over time, can still be confusing to engineers new to the pattern.

There is also a real risk of over-rotating on "modernization" as an end in itself. Rewriting working code to match the latest recommended pattern has a cost measured in engineering hours and regression risk, and that cost needs to be weighed against the actual pain the current code is causing. A team migrating a stable, low-traffic internal tool to the App Router purely to stay current is spending capital that could go toward user-facing improvements. The more defensible triggers for migration are concrete: a measurable performance problem, a recurring class of bugs traceable to the old pattern, or a feature that is meaningfully harder to build under the legacy architecture than it would be under the new one.

A further pitfall is treating architectural decisions as purely technical when they are also organizational. Introducing a strict module-boundary lint rule is a technical change, but if it is rolled out without warning, it will break in-flight branches and generate frustration that has nothing to do with the rule's merit. Migrations that fail politically often succeed technically; the code compiles and works, but the team resents how it was introduced, which erodes the lead engineer's ability to drive the next change. Sequencing communication alongside code - RFCs, deprecation timelines, office hours for questions - is not optional overhead; it is the mechanism by which a technically correct decision becomes an organizationally accepted one.

Finally, there is a subtler trade-off around centralization. Standardizing "one way to do things" reduces cognitive load and inconsistency, but it can also become a bottleneck if every new pattern has to route through one person for approval. A lead engineer aiming for long-term architectural health should be trying to make themselves progressively less necessary for routine decisions, by documenting the reasoning behind conventions clearly enough that others can extend them without asking.

Best Practices for Driving Strategy Without Formal Authority

The most effective lead engineers treat architecture decisions the way senior engineers treat production incidents: with a written record. A lightweight RFC (Request for Comments) process - a short document describing the problem, the options considered, the recommendation, and the trade-offs - does more to build durable influence than any amount of verbal advocacy. It creates a paper trail that new team members can read to understand why the system looks the way it does, and it forces the author to articulate trade-offs precisely rather than relying on intuition that is hard to challenge or defend. Google, Spotify, and many other engineering organizations have published variations of this practice publicly, and the format does not need to be heavyweight to be effective; a one-page document that clearly states the problem and the chosen path is often more useful than an exhaustive one that nobody finishes reading.

Second, invest in making the "right" way to do something also the easy way. If the sanctioned pattern requires more boilerplate than the ad hoc alternative, engineers under deadline pressure will reach for the ad hoc alternative regardless of what the documentation says. This is why the paved-road pattern described earlier matters more than documentation alone: a well-designed shared hook, generator script, or lint rule enforces the architecture continuously, without requiring a human reviewer to catch every deviation in code review.

Third, treat code review as the primary lever for architectural influence, since it is the one venue where a lead engineer without formal authority still has direct, regular contact with nearly every change entering the system. Reviews that consistently ask the same handful of questions - does this belong in a server or client component, does this duplicate an existing pattern, does this cross a module boundary it shouldn't - teach the team the architecture through repetition far more effectively than a one-time onboarding document.

Fourth, measure what you are trying to improve. Core Web Vitals (Largest Contentful Paint, Interaction to Next Paint, Cumulative Layout Shift), tracked via tools like Lighthouse or Next.js's built-in analytics, give an objective, external benchmark for whether a rendering-strategy change actually improved anything, rather than relying on the intuition that server components are "obviously better". Framing modernization work in terms of these metrics, rather than in terms of technical elegance, also makes it far easier to justify the work to non-engineering stakeholders.

Fifth, build in intentional redundancy of architectural knowledge. If you are the only person who understands why a particular pattern was chosen, the system's health is coupled to your continued presence on the team, which is both a personal risk and an organizational one. Rotating ownership of architectural documentation, pairing on RFCs, and explicitly mentoring other senior engineers into the decision-making process are what allow a modernization effort to survive a lead engineer moving to a different team or company.

Key Takeaways

Conclusion

Technical leadership at the lead fullstack engineer level is less about grand vision statements and more about a series of well-reasoned, well-communicated, incrementally shippable decisions. The engineers who successfully modernize a React and Next.js stack over the long term are rarely the ones who push for a single sweeping rewrite; they are the ones who correctly identify which architectural decisions are load-bearing, sequence changes so the system stays shippable throughout, and build enough written record and shared tooling that the improved architecture survives their own departure from the team. Authority in this role is earned continuously, through the quality of code review feedback, the clarity of RFCs, and the visible, measurable improvement of the systems under your care - not granted by a title. The stack will keep changing; React and Next.js themselves will look different in five years than they do today. What compounds is not any specific technical choice but the habit of making those choices deliberately, explaining them clearly, and leaving the system easier for the next engineer to reason about than you found it.

References