The T3 Stack’s Tradeoffs, Explained by Its Creator

I created the T3 Stack and use these technologies, but this 2022 discussion focuses on their weaknesses. A stack can be productive for full-stack applications and still be a poor fit for particular projects.

The components I discuss include Prisma, tRPC, Tailwind, NextAuth, Next.js, React and Vercel. Their capabilities have evolved since this recording, so treat specific limitations as historical and consult current documentation before deciding.

In the version I used, Prisma’s Rust binary and bundle size made edge deployment and serverless cold starts difficult. A persistent server could initialize the client once, while ephemeral environments exposed more of that startup cost.

Prisma generated types during installation, which I found opinionated and sometimes awkward. Generated types are useful for database safety, but the build step and its interactions with dependencies add another concern for developers.

I also warn about performance on large or nested queries. These are workload-dependent observations, not a universal benchmark. [Prisma’s later edge documentation](https://www.prisma.io/docs/orm/v6/prisma-client/deployment/edge) describes a configuration that does not ship the Rust query-engine binary.

tRPC is especially appealing when both frontend and backend are TypeScript and can share types. I consider it less suitable as the primary contract for a third-party API or clients written in unrelated languages.

A large number of procedures can also strain TypeScript tooling. I observed improvements in tRPC v10, but recommend watching editor and type-checking performance as a project grows rather than assuming an unlimited scale.

Client integrations were at different stages of maturity in 2022, with React bindings especially developed. The [tRPC documentation](https://trpc.io/docs/) explains its TypeScript inference approach; check the current clients for the framework you need.

Tailwind scans files to find utility classes and requires enough CSS knowledge to use those classes well. Its generated stylesheet can be small overall without being perfectly minimal for each individual page.

I find NextAuth valuable but frustrating in some areas: its broad scope and configuration choices can make an apparently simple use case require extra work. In 2022 I particularly mention user IDs, type overrides and token refresh.

I also encountered problems with edge execution and uneven support outside React. These describe my experience with the versions at the time; authentication and deployment details should be checked against the currently selected release.

Next.js makes specific choices about routing, build tools and React. Those conventions can be productive, but they reduce freedom to swap individual parts, and the JavaScript shipped may be more than a largely static page needs.

I criticize the data-loading and page-prop patterns available in my 2022 setup, including rough edges around server rendering and route parameters. Those comments refer to the Pages Router-era code I was using, not every later Next.js release.

For a mostly static site, React’s client-side machinery can introduce work the page does not need. For an interactive application, those costs may be reasonable; the right answer depends on the rendered content and user experience.

React intentionally leaves many choices—such as routing, data and styling—to the surrounding ecosystem. I value that flexibility, but teams seeking uniform conventions may find the broad solution space harder to manage.

I praise the React documentation work while noting that the new documentation was not yet localized at the time. Documentation access and translations affect adoption for developers who do not primarily work in English.

For the Vercel deployment model I used, I call out stateless functions, cold starts and the need to plan storage separately. Regional options, edge behavior and pricing were also part of the decision in 2022; current plans and products may differ.

I like the convenience of deployment and CDN integration, but warn that costs can grow differently for image optimization and function invocations. Estimate costs from the workload and current provider terms.

The stack’s modularity is both a benefit and a responsibility. Teams can replace pieces and make different architecture choices, but the flexibility also creates room for decisions that are hard to maintain.

I have seen the stack used for static blogs, direct server deployment and distributed databases. These examples illustrate different needs; for a simple blog I would generally favor a solution designed for mostly static content.

There are several pieces to learn: React, TypeScript, Next.js, tRPC and the query library it uses, plus whichever database and authentication options the team selects. The list can be intimidating even when each piece has a clear role.

At the time, Create T3 App did not prescribe a testing solution. That gives teams choice but leaves them responsible for selecting tools and establishing useful test practices.

I explain that our then-default data-fetching setup did not place fetched application data in the first HTML response. Users could see a loading state while the client fetched data, a deliberate tradeoff in that implementation.

The tradeoff can suit an interactive app but may be undesirable for content or commerce pages that need complete initial HTML or metadata. This was a property of the setup I describe, not a general statement that Next.js cannot render on the server.

The ecosystem has changed since then. Current [Create T3 App installation options](https://create.t3.gg/en/installation) include the App Router and several optional components, so evaluate the generated project and its version directly.

End-to-end types do not automatically prove that database data or runtime inputs are valid. Teams still need to understand where assumptions enter the system and validate data at appropriate boundaries.

Large TypeScript projects can slow editor services and type checking, especially when inference and complex types accumulate. Project references and other tooling choices can help, but their value should be measured in the actual codebase.

I distinguish runtime latency from horizontal scalability. A different runtime may execute a particular backend operation faster, while a serverless platform can add instances to handle concurrent load; neither property alone guarantees the other.

The learning curve depends on prior experience. A React developer who already knows TypeScript and the query library may move quickly, while someone new to programming must learn more concepts at once.

Documentation is another tradeoff in a modular stack. I explain that the project then leaned on the component libraries’ own docs and videos, which can leave newcomers navigating several sources.

My conclusion is to choose for the application. I still favor the stack for interactive, data-changing full-stack apps, while recognizing that a mostly static site or a team with different constraints may be better served elsewhere.

Before adopting a stack at work, review its limitations with the team and compare them with the project’s requirements. A tool is useful when its tradeoffs fit the actual work.