Payload CMS Starter vs T3 Stack: Content-First vs API-First

Two Frameworks That Start From Opposite Ends

Payload CMS (30K+ GitHub stars, acquired by Vercel in 2024) is a headless CMS framework that runs natively inside Next.js since version 3.0. Define your content schema in TypeScript config files, and Payload auto-generates an admin panel, REST and GraphQL APIs, authentication, access control, and a fully typed data layer. You never build CRUD -- it exists the moment you define a collection.

T3 Stack (28K+ GitHub stars, created by Theo Browne and the open-source community) is a CLI scaffold that generates a type-safe Next.js project with tRPC, Prisma, NextAuth, and Tailwind CSS. Everything is opt-in. You get end-to-end type safety and zero business logic -- no CMS, no admin panel, no content management. You build every feature yourself.

Same language, same meta-framework, completely different philosophies. This comparison breaks down when content-first architecture saves you months -- and when API-first flexibility is worth building from scratch.

TL;DR

Payload CMS Starter auto-generates an admin panel, REST/GraphQL APIs, auth, and access control from TypeScript collection configs. It runs natively inside Next.js since 3.0, supports MongoDB and PostgreSQL, and excels when your application revolves around structured content. T3 Stack gives you tRPC, Prisma, NextAuth, and Tailwind with end-to-end type safety and zero pre-built features -- it excels when you need full architectural control and custom API logic. Choose Payload when content management is core. Choose T3 when content is secondary.

Key Takeaways

• Payload gives you a full CMS out of a config file. Define a collection in TypeScript, and you get an admin panel with rich text editing, media management, versioning, drafts, and localization -- auto-generated, no code required. T3 gives you none of this.
• T3 gives you the best type-safe API layer in the ecosystem. tRPC provides end-to-end type inference from database to frontend with zero code generation. Payload generates REST and GraphQL APIs automatically, but they follow CMS conventions rather than custom RPC patterns.
• Payload is now a Next.js native framework. Since version 3.0, Payload runs inside your Next.js app -- same server, same codebase, same deployment. No separate CMS server to manage. This was a fundamental architecture shift that eliminated the "headless CMS as external service" overhead.
• Vercel acquired Payload in 2024. This gives Payload deep integration with the Vercel deployment platform and signals long-term investment in the framework. T3 is community-maintained with no corporate backing.
• T3 has more database flexibility. Prisma supports PostgreSQL, MySQL, SQLite, SQL Server, and CockroachDB. Payload supports MongoDB and PostgreSQL.
• Auth approaches differ fundamentally. Payload has built-in authentication with email/password, API keys, and custom strategies baked into every collection. T3 uses NextAuth.js, which is more flexible for OAuth providers but requires manual configuration.

Quick Comparison Table

Feature	Payload CMS Starter	T3 Stack
Price	Free (MIT)	Free (MIT)
GitHub Stars	30K+	28K+
Framework	Next.js (native since 3.0)	Next.js
Philosophy	Content-first	API-first
Admin Panel	Auto-generated from config	Not included
CMS Features	Rich text, media, versions, drafts, localization	Not included
Auth	Built-in (email/password, API keys)	NextAuth.js (configurable)
Database	MongoDB or PostgreSQL	Any SQL via Prisma
API Layer	REST + GraphQL (auto-generated)	tRPC (end-to-end typed)
TypeScript	Config-driven, strict	Strict, enforced
Access Control	Built-in, field-level	Not included
File/Media Management	Built-in with S3/cloud support	Not included
Localization	Built-in (i18n)	Not included
Deployment	Vercel, self-hosted, Docker	You configure
Corporate Backing	Vercel (acquired 2024)	Community-maintained
CLI Setup	npx create-payload-app	npx create-t3-app

Philosophy: Content-First vs API-First

This is not a minor difference -- it shapes every decision you make after scaffolding.

Payload CMS: Your Data Model Is Your Application

Payload inverts the typical development workflow. Instead of designing database tables and then building CRUD interfaces on top of them, you define collections in TypeScript config files. A collection describes your content type -- its fields, validation rules, access control, hooks, and admin panel behavior. Payload reads that config and generates everything else.

// payload.config.ts — define a collection, get everything auto-generated
const Posts: CollectionConfig = {
  slug: 'posts',
  admin: {
    useAsTitle: 'title',
  },
  access: {
    read: () => true,
    create: isAdmin,
    update: isAdmin,
    delete: isAdmin,
  },
  fields: [
    { name: 'title', type: 'text', required: true },
    { name: 'content', type: 'richText' },
    { name: 'author', type: 'relationship', relationTo: 'users' },
    { name: 'status', type: 'select', options: ['draft', 'published'] },
    { name: 'publishedDate', type: 'date' },
    { name: 'featuredImage', type: 'upload', relationTo: 'media' },
  ],
}

From this single config, Payload generates an admin panel with forms, a rich text editor, media upload handling, REST and GraphQL endpoints, field-level access control, draft/versioning support, and fully typed TypeScript interfaces. Twenty lines of config replaces two to three weeks of manual development.

This is powerful when your application is content-centric -- blogs, documentation sites, e-commerce catalogs, news publications. Anywhere the core value is creating, editing, and publishing structured content, the admin panel is not a nice-to-have; it is the product.

T3 Stack: Your API Logic Is Your Application

T3 starts from the opposite end. You define procedures -- typed functions that accept input and return output -- and compose them into an API that your frontend consumes with full type inference.

// server/api/routers/post.ts — define procedures, get end-to-end types
export const postRouter = createTRPCRouter({
  getAll: publicProcedure.query(({ ctx }) => {
    return ctx.db.post.findMany({
      orderBy: { createdAt: 'desc' },
      include: { author: true },
    });
  }),

  create: protectedProcedure
    .input(z.object({
      title: z.string().min(1),
      content: z.string(),
    }))
    .mutation(({ ctx, input }) => {
      return ctx.db.post.create({
        data: { ...input, authorId: ctx.session.user.id },
      });
    }),
});

// Client — fully typed, zero codegen
const { data: posts } = api.post.getAll.useQuery();
// TypeScript knows posts is (Post & { author: User })[]

Complete control over data access patterns, business logic, and API surface. The trade-off: you build everything from scratch -- admin interfaces, content editing, media management, access control.

T3 excels when your application logic does not map to CRUD on content types. Real-time collaboration tools, analytics dashboards, developer platforms with complex multi-tenant logic -- these need custom API patterns that a CMS framework would constrain.

Feature-by-Feature Comparison

Content Management and Admin Panel

This is where the comparison is most lopsided. Payload is a content management system -- rich text editing with Lexical, block-based content, media library with image resizing, document versioning with draft/publish workflows, localization, and live preview. All auto-generated from your collection configs. The admin panel includes list views with filtering, document editing forms, relationship management, and role-based access. You can extend it with custom React components, but the default covers 90% of use cases without writing any UI code.

T3 Stack has zero content management features. No admin panel, no rich text editor, no media library. Building a mid-complexity admin panel from scratch takes three to six weeks. If your product manages content, Payload saves months. If it does not, Payload's CMS features are overhead.

Authentication

Payload bakes auth into the framework -- add auth: true to any collection config and you get email/password registration, login, password reset, email verification, API key auth, and field-level access control. T3 uses NextAuth.js, which is more flexible for OAuth providers (Google, GitHub, Discord, and dozens more) but requires manual configuration for every provider, callback, and login page.

Payload wins for email/password flows with tight access control. T3 wins for social login and multi-provider OAuth.

Database and API Layer

Payload supports MongoDB and PostgreSQL, with schema derived automatically from collection configs. APIs are auto-generated -- every collection gets REST endpoints (GET, POST, PATCH, DELETE) plus a full GraphQL API with filtering, pagination, and depth control. You extend behavior through hooks (beforeChange, afterRead), but the default CRUD covers most content operations.

T3 uses Prisma, supporting PostgreSQL, MySQL, SQLite, SQL Server, and CockroachDB. You control your schema and migrations explicitly. tRPC provides a fundamentally different API model -- you define procedures with Zod validation and the client calls them as typed functions with full inference. No REST, no GraphQL, no code generation. You design every endpoint, but every endpoint is exactly what you need.

T3 wins on database flexibility and API type safety. Payload wins on speed-to-API for content operations.

Deployment

Both deploy to Vercel, Railway, Fly.io, and Docker-compatible hosts. Payload 3.0 runs inside your Next.js app -- same process, same deployment, no separate CMS server. Vercel's acquisition gives Payload first-class deployment support. T3 is a lighter deployment with no CMS runtime overhead.

Architecture Comparison

Payload 3.0 runs as Next.js middleware. Your payload.config.ts defines collections, globals (singleton content types), and plugins. Payload processes this at build time to generate TypeScript types, admin panel routes, and API endpoints. Content editors interact with the admin panel, which calls Payload's Local API (same-process, zero HTTP overhead). External consumers use the REST or GraphQL APIs. Your CMS and application share a server, database connection, and deployment -- no "headless CMS hosted somewhere else."

T3 structures projects around the Next.js App Router with tRPC as the API layer. Sub-routers compose into a root router, and the client imports typed hooks that mirror the server structure with full autocomplete and compile-time checking. Prisma and NextAuth connect through tRPC's context system. Each layer is decoupled -- swap Prisma for Drizzle without touching tRPC procedures, or replace NextAuth without changing your schema. Nothing is auto-generated, nothing is assumed, every piece is replaceable.

Time-to-Launch Analysis

Milestone	Payload CMS Starter	T3 Stack
Project scaffolding	5 minutes	5 minutes
Content schema defined	1-2 hours	N/A
Admin panel working	0 (auto-generated)	3-6 weeks (build yourself)
Auth working	30 minutes (config only)	1-2 hours
API endpoints live	0 (auto-generated)	1-2 weeks
Media management	0 (built-in)	1-2 weeks
Access control	1-2 hours (config only)	1-2 weeks
Content editing UX	0 (built-in rich text)	2-4 weeks
Total to content-driven MVP	1-2 days	8-14 weeks

For content-centric applications, the gap is dramatic. But these numbers only apply when your product genuinely revolves around content management. For a SaaS dashboard or developer platform, most rows are irrelevant -- you do not need a media library or rich text editor.

Community and Ecosystem

Payload CMS has 30K+ GitHub stars, an active Discord, and an official plugin ecosystem (SEO, form builder, nested documents, redirects). The Vercel acquisition brought additional resources, and creator James Mikrut continues leading development with Vercel's backing.

T3 Stack has 28K+ GitHub stars, Theo Browne's YouTube channel (1M+ subscribers), an active Discord, and the broader ecosystem including T3 Turbo for monorepos. Community-produced tutorials, blog posts, and video content are extensive.

Both communities are strong but serve different audiences. Payload skews toward content creators, agencies, and CMS-backed websites. T3 skews toward TypeScript enthusiasts, SaaS builders, and developers who value architectural control.

When to Choose Payload CMS Starter

• Content management is your core product. Blogs, documentation, e-commerce catalogs, news publications, portfolio sites -- anywhere creating and publishing structured content is the primary workflow.
• You need an admin panel immediately. Payload's auto-generated admin saves weeks. If your project requires a content editing interface, this alone justifies the choice.
• Your team includes non-technical content editors. Rich text editing, media management, and draft workflows work without developer training.
• You want corporate backing. Vercel's acquisition signals long-term investment and first-class deployment integration.
• Localization is a requirement. Built-in i18n at the field level -- a feature that takes weeks to build from scratch.

Best for: Content platforms, editorial sites, e-commerce, documentation, marketing sites, agency projects.

When to Choose T3 Stack

• Your logic does not map to content types. Real-time features, multi-tenant workflows, analytics dashboards, developer tools -- custom logic over content management.
• End-to-end type safety is your top priority. tRPC's compile-time type checking across the full stack is unmatched.
• You need maximum database flexibility. Prisma supports six database engines versus Payload's two.
• You want zero framework opinions. No admin panel conventions, no content model assumptions, no CMS runtime overhead.
• OAuth and social login are critical. NextAuth's provider ecosystem is broader than Payload's built-in auth.

Best for: SaaS dashboards, developer tools, analytics platforms, real-time applications, custom API services.

The Hybrid Path

These frameworks are not mutually exclusive. Some teams use Payload for content (blog posts, marketing pages, documentation) while building core application logic with custom Next.js routes. Payload 3.0's native Next.js integration makes this practical -- content collections and custom features live in the same codebase.

This works well for products that are primarily SaaS applications but have significant content needs: a developer platform with documentation, a SaaS with a content marketing blog, or e-commerce where the storefront is content-managed but checkout is custom.

The Deciding Question

The choice is not about which framework is better. It is about what your application fundamentally is.

If content-centric -- the core workflow involves creating, editing, and publishing structured content -- Payload eliminates months of work. The auto-generated admin panel, APIs, auth, and access control are not nice-to-have features. They are the product.

If logic-centric -- custom business logic, real-time interactions, or API integrations that do not map to CRUD on content types -- T3's clean foundation and end-to-end type safety are the right starting point.

Ask yourself: "Will my application have an admin panel where non-technical users manage content?" If yes, start with Payload. If no, start with T3. If "partially," consider the hybrid path -- Payload for content, custom logic for everything else, same Next.js application.

Methodology

This comparison is based on publicly available documentation, GitHub repositories, and feature lists for both projects as of March 2026. Payload CMS was evaluated via its official documentation at payloadcms.com and the create-payload-app CLI. T3 Stack was evaluated via the create-t3-app CLI and official docs at create.t3.gg.

Payload's architecture analysis reflects version 3.0+, which introduced native Next.js integration. Earlier versions of Payload used a separate Express server and have different deployment characteristics.

We have no affiliate relationship with either project. Both are free and open source under the MIT license.

---

Looking for more boilerplate comparisons? StarterPick has side-by-side feature breakdowns, community reviews, and stack analysis for dozens of SaaS boilerplates -- so you can find the right one without the research rabbit hole.