Building a "use server/client"-less corporate site with TanStack Start — A realistic alternative to Next.js

"We adopted Next.js App Router, but segregating 'use server' and 'use client' became so convoluted that our team's learning curve tripled expectations"—we hear this sentiment with increasing frequency across client web development projects.

Attracting attention as a practical contender against this directive fatigue is TanStack Start. As of April 2026, it presents a distinct architecture capable of handling RSCs without writing "use server" or "use client," opening a breach in Next.js's sole dominance for corporate sites, B2B portals, and small-to-midsize applications.

In this article, we examine whether TanStack Start warrants adoption in corporate site client projects, migration costs from Next.js, and frameworks for pitching client proposals.

Why directive fatigue occurred

While Next.js App Router is powerful, it requires developers to correctly apply "use server" and "use client" component by component, causing the following problems to emerge as scale grows.

1. Misjudging boundaries: Inadvertently writing useState inside a Server Component breaks production builds
2. Divergence between intent and reality: When declarations drift from actual behavior, pinpointing the starting point for debugging becomes difficult
3. Learning curve: New team members get stuck for weeks trying to determine which directive to write

Corporate sites center primarily on articles, case studies, and forms, an area that should fundamentally be buildable by junior frontend engineers. When RSC directive splitting enters the picture, on-the-ground experience shows that productivity drops by 30% to 50%.

In response to the challenge that it is "too heavy for corporate sites," which we discussed in our Next.js vs. Astro comparison article, alternatives beyond Astro are now emerging.

TanStack Start design philosophy

TanStack Start automatically infers "use server" and "use client" through file placement and function definitions rather than explicit directives.

// routes/about.tsx
// ファイル名・配置から「ルート」であることが推論される
import { createFileRoute } from "@tanstack/start";
import { useCompanyProfile } from "../server/company";

export const Route = createFileRoute("/about")({
  // サーバーで実行されるローダー（use server を書かない）
  loader: async () => await useCompanyProfile(),
  component: About,
});

function About() {
  const { data } = Route.useLoaderData();
  // ここはクライアントでも動く（use client を書かない）
  return <section>{data.mission}</section>;
}

The concept of "determining what belongs on the server based on file and function names" is similar to Astro or Remix, representing a placement over declaration design well-suited for corporate sites.

Adoption criteria for corporate sites

Suitable projects

• Corporate sites with 10 to 50 pages
• Focused on blogs, case studies, customer stories, and recruitment info
• A few forms, with no admin panel or only a small one
• Team React experience consists of 1 intermediate-to-senior engineer + 2 to 3 junior engineers

Unsuitable projects

• SaaS dashboards that fully leverage Server Actions
• Heavy dependencies on specific libraries in the Next.js ecosystem (e.g., next-auth)
• Largely static content sites where SSG suffices (Astro is optimal here)

The distinction between Astro and TanStack Start is clear: as a practical benchmark, use Astro if interactive UI is minimal, and TanStack Start if there is a moderate amount. This complements the domain we detailed in our Astro + microCMS guide.

Estimating migration costs from Next.js

When migrating a medium-sized corporate website (30 pages, 3 forms, blog CMS integration) from Next.js App Router to TanStack Start, the workload is roughly as follows.

As the workload breakdown shows, migration effort varies significantly based on existing Server Actions dependency, CMS integrations, and authentication setup. Unless the migration can be justified by mid- to long-term project ROI (reducing maintenance overhead, boosting development velocity), client stakeholders will not approve the decision. Because migrations require considerable effort, the deciding factor is whether this ROI can be articulated in the client's own terms.

Proposal narrative templates

When proposing a migration, structure the discussion across the following four stages.

1. Articulate current Next.js operational pain points (build times, deployment failure rates, developer turnover)
2. Present the post-migration operational picture (simple file layouts, 30% reduction in build times)
3. Acknowledge risks explicitly (slimmer ecosystem, fewer case studies)
4. Phase the rollout (gradually adopting TanStack Start starting with new pages)

In particular, the phased approach of "introducing it on new pages while replacing existing ones during routine maintenance" is a pattern that minimizes risk and resonates strongly with clients.

Hosting options

In addition to Node environments, TanStack Start runs on Cloudflare Workers, Deno Deploy, and Bun servers. It can be hosted on the same infrastructure we detailed in our edge API design with Hono + Cloudflare Workers.

For enterprises weighing hosting choices, pairing Cloudflare Workers with TanStack Start stands out as a compelling, minimal-cost solution for corporate website operations.

How to define project scope

For projects centered around TanStack Start, rather than jumping into an all-at-once migration, decision-making proceeds much more smoothly when scope is structured in phases as follows.

• Greenfield corporate site construction: Designing from scratch leverages the placement-based design philosophy in its purest form
• Phased migration from Next.js: Transition new pages to TanStack Start first, replacing existing ones during maintenance cycles
• Single-section PoC: Test on a small scale as evaluation material for adoption to gauge team confidence before pitching executive management

A PoC scope in particular keeps both timeline and effort minimal, serving as an effective entry point to lower the cost of building executive consensus.

Summary — "Options other than Next.js" have become a reality

Between 2024 and 2025, there was an atmosphere suggesting Next.js was the only viable way to do RSC. Entering 2026, with the evolution of Astro and TanStack Start handling RSC through placement, client corporate web development has returned to a phase of choosing the paradigm that best fits the organization.

We handle everything from comparative evaluations of TanStack Start, Astro, and Next.js to greenfield corporate site builds and phased migrations from Next.js. The optimal architecture and where to carve out the migration boundary depend on your page structure, existing Next.js assets, and the team's React proficiency. If you want to assess how to resolve App Router directive fatigue or determine which areas to migrate to TanStack Start, share your requirements and we will propose a concrete roadmap. Please feel free to reach out via our contact form to get started.