What is the difference between App Router and Pages Router in Next.js?

App Router (introduced in Next.js 13, the default since Next.js 14) uses a file-system hierarchy under the `app/` directory, supports React Server Components by default, and co-locates layouts, loading states, and error boundaries at the route level. Pages Router uses the older `pages/` directory, treats every file as a Client Component, and relies on `getServerSideProps`/`getStaticProps` for data fetching. Templates built for Pages Router do not automatically benefit from Server Component streaming, parallel data fetching, or nested layouts.

Can a Next.js template use both App Router and Pages Router?

Yes — Next.js supports running both directories simultaneously in a migration scenario. However, quality templates in 2026 should be fully committed to one or the other. A template that mixes both directories is usually a Pages Router project with a few App Router routes bolted on, which means you lose the architectural consistency that makes App Router valuable.

How do I check if a Next.js template uses Server Components correctly?

Open the component files and look for `'use client'` directives. In a well-structured App Router template, only components that use browser APIs, event handlers, or React hooks carry this directive. If every component file starts with `'use client'`, the template is effectively a Pages Router app wearing App Router clothes — you get none of the performance benefits of Server Components.

What price should I expect for a good Next.js App Router SaaS template?

Standalone App Router dashboard templates run $39–$89. Complete SaaS starters with auth (Clerk or NextAuth v5), Stripe billing, and a database layer run $99–$199. Under $79 for a full SaaS starter usually means the Stripe integration is incomplete or the template hasn't been updated for Next.js 15's caching changes.

Best Next.js App Router Templates to Buy in 2026

Why App Router Changes Everything

When Next.js 13 introduced the App Router, it wasn't an incremental improvement — it was a different architecture. By Next.js 15, App Router is the only first-class path. Pages Router still works, but it receives no new features and the ecosystem has shifted.

The difference matters when buying templates because App Router templates built correctly are genuinely faster and more maintainable than their Pages Router equivalents. But App Router templates built incorrectly — the ones that put 'use client' on every file to avoid learning Server Components — give you all the complexity with none of the benefit.

This guide explains what App Router correctness actually looks like, and what to check before paying for a template.

What App Router Templates Do Differently

Server Components by Default

In the App Router, every component is a Server Component unless explicitly marked otherwise with 'use client'. Server Components:

Run only on the server — they can read from databases, call APIs, and access secrets without exposing them to the browser

Render to static HTML and stream to the client — no hydration cost

Reduce JavaScript bundle size because server-only code never ships to the browser

A template that uses Server Components correctly will have 'use client' on a small minority of files — interactive components like forms, dropdowns, date pickers, and anything using React hooks (useState, useEffect, useContext). Everything else is a Server Component.

Red flag: If you see 'use client' at the top of every component file, the developer moved from Pages Router to App Router by adding that directive everywhere. You get App Router file structure with Pages Router semantics.

Co-Located Data Fetching

In Pages Router, data fetching lives in getServerSideProps or getStaticProps — functions that must run before the page renders and must fetch all data the page needs, even if different components need different data at different times.

App Router eliminates this. Each Server Component fetches only its own data:

typescript

// app/dashboard/page.tsx — Server Component
export default async function DashboardPage() {
  const stats = await getUsageStats(); // fetched at the component level
  return <StatsGrid stats={stats} />;
}

// app/dashboard/recent-activity.tsx — also a Server Component
export default async function RecentActivity() {
  const events = await getRecentEvents(); // independent fetch
  return <ActivityFeed events={events} />;
}

These fetches can run in parallel via React's Suspense, and Next.js deduplicates identical requests automatically within a render. A quality App Router template uses this pattern rather than a single fetch-everything-then-render approach.

Nested Layouts

App Router layouts are composable. A layout.tsx file wraps every page in its directory — and layouts can be nested:

app/
  layout.tsx          ← root layout (html, body, global providers)
  (marketing)/
    layout.tsx        ← marketing layout (header, footer)
    page.tsx          ← home page
    pricing/page.tsx  ← pricing page
  (app)/
    layout.tsx        ← app layout (sidebar, nav, auth check)
    dashboard/page.tsx
    settings/page.tsx

This structure means the marketing layout and the app layout are completely separate — the sidebar doesn't render on the marketing site, and the marketing header doesn't appear in the dashboard. Changing one doesn't affect the other.

A quality template uses route groups (the parentheses syntax) to separate marketing from the authenticated app without requiring different entry points.

Loading and Error States at the Route Level

App Router introduces loading.tsx and error.tsx files that automatically wrap the page in Suspense or an error boundary:

app/(app)/dashboard/
  page.tsx          ← the actual dashboard
  loading.tsx       ← shows while page data is fetching
  error.tsx         ← catches errors, shows recovery UI

This is one of the most buyer-visible differences. A quality template has loading.tsx files that show skeleton UI during data fetching — so the page renders immediately with a skeleton and data streams in, rather than showing a blank white screen until everything is ready.

What to check: Navigate to the dashboard in the template's live demo on a throttled network (Chrome DevTools → Network → Slow 3G). Does a skeleton appear immediately, or is the screen blank during load?

The Template Categories Worth Buying

App Router SaaS Starters

The highest-value purchase for indie developers. A complete App Router SaaS starter includes:

Authentication using Clerk (the fastest to integrate) or NextAuth.js v5 (auth.js), not the outdated NextAuth v4

Stripe billing — not just Checkout, but webhooks to update subscription state in the database, the customer portal for self-service subscription management, and subscription gating on protected routes

Database with Drizzle ORM or Prisma, set up for PostgreSQL on Neon or Supabase

Email via Resend with transactional templates already built

Route protection using Next.js middleware — the middleware.ts file should check session before the page renders, not inside the page component

What distinguishes a quality App Router SaaS starter from a Pages Router port:

The route protection is in middleware.ts, not in useEffect inside a Client Component. Data for the dashboard fetches in Server Components, not useEffect after mount. The Stripe webhook handler is a Next.js Route Handler (app/api/webhooks/stripe/route.ts), not a pages/api/ file.

Price range: $99–$199. Budget options under $79 usually haven't been updated for Next.js 15's caching changes (more on this below).

App Router Admin Dashboards

Pure UI, no backend. The right choice when you already have your own API or data layer. Look for:

A real data table — not an HTML table with CSS, but a headless table library (@tanstack/react-table) with sorting, filtering, pagination, and row actions

Charts using Recharts or Tremor with the actual chart as a Client Component ('use client') and data passed as props from a Server Component parent

Sidebar navigation that collapses properly on mobile, with active state derived from usePathname() in a Client Component wrapper — not hardcoded

Form components built on React Hook Form with Zod validation

Price range: $39–$89.

App Router Blog and Marketing Templates

Landing pages and content sites are a strong use case for App Router because the entire page can be a Server Component tree — there's essentially nothing that needs client interactivity on a static marketing page:

Hero, features, pricing sections as pure Server Components

Blog with markdown or MDX rendering in Server Components — no client-side rendering of content

Sitemap and robots.txt auto-generated via app/sitemap.ts and app/robots.ts

Proper metadata using Next.js generateMetadata — not a component from Pages Router

Price range: $19–$59 for a landing page kit. $49–$99 if it includes a full blog with MDX.

App Router Multi-Tenant SaaS Templates

The hardest category to get right, but the most valuable if done correctly. Multi-tenancy on App Router typically works via subdomain routing handled in middleware.ts:

typescript

// middleware.ts
export function middleware(req: NextRequest) {
  const hostname = req.headers.get('host');
  const subdomain = hostname?.split('.')[0];

  if (subdomain && subdomain !== 'www') {
    // rewrite to tenant-specific route
    return NextResponse.rewrite(
      new URL(`/t/${subdomain}${req.nextUrl.pathname}`, req.url)
    );
  }
}

A quality multi-tenant template handles this middleware correctly, isolates tenant data at the database query level (not just at the route level), and includes a subdomain-based routing demo you can actually test.

Price range: $149–$299.

How to Evaluate Before Buying

Check the File Structure

The directory layout tells you whether it's a genuine App Router template or a Pages Router migration:

Good signs:

app/
  (marketing)/       ← route group for public pages
  (app)/             ← route group for authenticated app
  api/               ← route handlers (not pages/api/)
  layout.tsx         ← root layout
  page.tsx           ← home page
middleware.ts        ← route protection

Bad signs:

pages/               ← still using Pages Router
pages/api/           ← Pages Router API routes
app/                 ← App Router bolted on the side

If both pages/ and app/ directories exist with real content in both, treat it as a Pages Router template with an incomplete migration.

Count the 'use client' Directives

A rough rule: in a quality App Router SaaS dashboard, 'use client' should appear in fewer than 30% of component files. You can check this in a public repo:

bash

# Count 'use client' files vs total component files
grep -r "'use client'" components/ --include="*.tsx" -l | wc -l
find components/ -name "*.tsx" | wc -l

If the ratio is above 70%, the developer didn't commit to Server Components — they just moved the files around.

Test the Loading States

Every App Router dashboard route should show skeleton UI during load. In the live demo:

Open Chrome DevTools → Network → set throttling to Slow 3G

Navigate to the main dashboard route

Refresh

You should see immediate skeleton content, then data populating progressively. If you see a blank screen followed by a full page load, the template isn't using loading.tsx or Suspense.

Check for Next.js 15 Compatibility

Next.js 15 changed how caching works. In previous versions, fetch() cached by default. In Next.js 15, fetches are uncached by default. Templates that relied on the old implicit caching behavior will fetch on every request, potentially slowing the app or hammering your API.

Check the release notes or changelog for "Next.js 15 compatibility" or "caching update." If the template was last updated before October 2024 (when Next.js 15 shipped), assume it needs migration work.

Verify the Auth Flow End-to-End

In the live demo:

Create an account

Verify the session persists on page refresh (server-side session, not just localStorage)

Log out and try to directly access a protected route — you should redirect to login

Log back in — you should redirect back to where you were

If any of these fail, the auth is incomplete regardless of what the description says.

Common Mistakes When Buying

Trusting the framework version badge. "Built with Next.js 15" on a listing page just means it runs on Next.js 15. It doesn't mean it uses Server Components correctly, handles the caching changes, or actually uses App Router features. Check the code.

Ignoring the loading experience. Many templates look excellent in screenshots — the full rendered state is beautiful. The loading state is where corners get cut. A blank white screen during load is a user experience failure that affects conversion.

Buying a template with outdated auth. NextAuth v4 (the next-auth package) and NextAuth v5 (now called auth.js, package next-auth@5) have completely different APIs. v5 is built for App Router. v4 requires workarounds. A template using v4 in an App Router project will have awkward client-side session handling. Check the package.json.

Missing Stripe webhooks. Checkout works without webhooks. Subscription state doesn't. If the template doesn't include a webhook handler for customer.subscription.updated and customer.subscription.deleted, your database will never learn when someone cancels, upgrades, or has a failed payment.

No TypeScript on route handlers. App Router Route Handlers (route.ts files) should be typed — request and response types should be explicit. If the route handler files use req: any or no types at all, TypeScript strictness wasn't applied to the API layer.

App Router vs Pages Router: The Summary

Feature	App Router	Pages Router
Default component type	Server Component	Client Component
Data fetching	Co-located in component	`getServerSideProps` / `getStaticProps`
Layouts	Nested, per-route	Single `_app.tsx`
Loading states	`loading.tsx` per route	Manual `isLoading` state
Error handling	`error.tsx` per route	Manual try/catch
API routes	`app/api/**/route.ts`	`pages/api/*/.ts`
Streaming	Yes (Suspense)	No
Active support	Yes	Maintenance only

If you're starting in 2026, you want App Router. The performance headroom and architectural clarity are worth the learning curve — and a quality template removes most of the learning curve by showing the right patterns in context.

Where to Find Quality Options

The tricky part is that "App Router" is a label sellers apply to any template with an app/ directory — even if the underlying architecture is still Pages Router thinking with different file paths.

Browse Next.js App Router templates on CodeCudos — listings are quality-scored on TypeScript strictness, dependency health, and documentation completeness. Filter by framework and check the quality score before reading the description. If you've built an App Router template worth selling, list it on CodeCudos — sellers keep 90% of every sale, and App Router templates at the right quality level consistently outperform Pages Router listings.