AI-Fullstack-SaaS-Boilerplate: a tRPC, Fastify and React starting point with a built-in chat

What AI-Fullstack-SaaS-Boilerplate actually saves you

The project is a starting point for a TypeScript SaaS product, not a framework and not a hosted service. The problem it addresses is the first two weeks of a new codebase: choosing a server, wiring a typed API layer between client and server, setting up an ORM against Postgres, adding authentication, and getting a build pipeline that works across more than one package. The README presents the result as a stack table rather than a feature list, which tells you what the author considers the product: the combination of Fastify, tRPC, Drizzle, Better Auth, React 19, Tailwind v4 and pnpm Workspaces.

It is aimed at a small team or a solo developer who already knows these libraries. There is no attempt to hide them behind an abstraction. If you have never used tRPC, the value of the boilerplate drops sharply, because the type safety it provides only pays off once you understand how routers and procedures are composed. The chat feature added in v2.0.7 is the one piece that is specific to this repository rather than to its dependencies, and it is what justifies the AI in the name.

The monorepo layout and how a request moves through it

The repository is a pnpm workspace. Top-level directories are client/, server/, packages/, tests-e2e/ and _layouts/, alongside pnpm-workspace.yaml, example.env and the root package.json. The root scripts address packages by filter name: @fsb/client, @fsb/server, @fsb/drizzle, @fsb/shared and @fsb/tests-e2e. That naming is the clearest map of the architecture available without reading source files.

The data flow implied by those packages is conventional for this stack. The client is a React 19 application built with Vite and routed with React Router v7. It calls the server through tRPC, which means the request and response types are inferred from the server's router definitions rather than written by hand. The server is Fastify. Persistence goes through Drizzle against Postgres, and the Drizzle schema lives in its own workspace package so both the server and the migration tooling can import it. @fsb/shared holds Zod schemas, built before the server in the backend build chain, which suggests validation contracts are shared rather than duplicated. Authentication is handled by Better Auth. The chat feature uses OpenAI and, per the repository topics, server-sent events for streaming.

The build order in the root package.json reflects real dependencies between these packages: build:backend runs build:drizzle, then build:zod, then build:server. If you add a new shared package, that ordering is where you register it.

Installing it and getting the dev servers up

The README does not include a step-by-step install section, so the commands below come from the root package.json scripts and the repository layout. Start by installing dependencies at the workspace root with pnpm, then copy example.env to the environment file your server reads and fill in the Postgres connection and the OpenAI key, since the chat feature depends on the latter.

pnpm install
cp example.env .env

Before the first run you need the database schema pushed to your Postgres instance. The root script delegates to the Drizzle package, which is why the filter name matters.

pnpm push
pnpm seed

The seed script is separate from push, so a fresh database can be populated without re-running migrations. After that, the dev command starts the client and server concurrently, which is what the run-p dev:* script does.

pnpm dev

Because both processes start in parallel, the client may come up before the server is accepting connections. The root package.json lists wait-port as a devDependency, which points at how the project handles that race, though the README does not document the port the server binds to. Check server/ for the Fastify listen call before you assume a default. For a production-style run, pnpm build runs build:frontend, which chains the backend build (Drizzle, then Zod, then server) before the client build, and pnpm start runs the compiled client and server together. End-to-end tests are behind pnpm test, which filters to @fsb/tests-e2e and uses Playwright.

Where this boilerplate will fight you

The README is a stack inventory. It has a demo link, a preview video and two dependency tables, and it stops there. There is no configuration reference, no explanation of the directory structure, no description of the tRPC router surface, and no guidance on adding a feature. For a boilerplate, that is the main cost: you are buying code you will have to read before you can extend it. The repository layout and the root package.json scripts are doing work the documentation should be doing.

The demo is hosted on Render's free tier, and the README warns that it spins down with inactivity, which can delay requests by 50 seconds or more. That is a property of the hosting, not of the code, but it means you cannot use the demo to judge latency or streaming behaviour in the chat.

The release history is a real signal about maturity. v2.0.5 is labelled with manual auth, v2.0.6 is labelled simple stable without chat, and v2.0.7, roughly a month later, added the chat feature. Three releases in under two weeks, one of which removed a feature that the next one reintroduced, describes a project still settling. Nothing in the repository documents a migration path between those versions, so treat a fork as a fork rather than as a tracked upstream.

Finally, the stack is opinionated in ways that are hard to undo. tRPC couples your client and server types; if you later need a public REST API or a non-TypeScript consumer, you will be writing that layer yourself. Better Auth and Drizzle are similarly load-bearing. Swapping any of them is a rewrite of the affected package, not a configuration change. If your team is standardized on Next.js, this is the wrong repository: React Router v7 and Vite are the client-side answer here, and there is no server-rendering story in the README.

How it compares to create-t3-app and to a managed backend

The closest comparison is create-t3-app, which also pairs TypeScript, tRPC and an ORM with a React framework. The difference in approach is the server. create-t3-app builds on Next.js, so API routes and rendering live in one process and one deployment. This boilerplate separates them: Fastify is a standalone server, the client is a separate Vite application, and the two are linked by tRPC over HTTP. That separation is the point. You get a backend you can deploy, scale and test independently of the frontend, and you avoid tying your API to a framework's routing conventions. You pay for it with two build targets, a workspace tool to run them together, and CORS and environment configuration that a single Next.js app does not need.

The second comparison is a managed backend such as Supabase or Firebase. Those give you authentication and a database without a server package at all. Here, Better Auth and Drizzle run inside your own Fastify process against your own Postgres, so you own the schema, the auth tables and the deployment. That is more work up front and more control later. If you want to avoid operating a database and an API server entirely, this repository solves a problem you do not have.

Maintenance, licensing and what an upgrade costs

The repository is not archived, and the last push was on 2026-09-02, which is recent enough that the codebase is being touched. Recent tagged releases are older: v2.0.7 landed on 2025-04-11. The gap between tagged releases and push activity means you should read commit history rather than release notes if you need to know what changed.

The licence is MIT, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is the extent of what can be said here; the LICENSE file at the repository root is the authoritative text, and anything beyond reading it is a question for your own counsel.

Upgrade cost is the weak point. The root package.json pins drizzle-orm at ^0.45.2, and the README lists React 19, Tailwind v4 and React Router v7, all of which are major versions with their own breaking changes. Because the workspace packages are private and named @fsb/*, there is no published package to update against. Upgrading means merging upstream changes into your fork by hand. Budget for that before you build a product on top of it, and expect the Drizzle package and the shared Zod package to be the first places a dependency bump breaks the build, since build:backend compiles them in sequence.

Editorial conclusion

Adopt it if your team already writes TypeScript end to end and wants a Fastify plus tRPC plus Drizzle skeleton with authentication and a chat screen already wired, and you are willing to read the workspace layout rather than a setup guide. Skip it if you need Next.js, a managed auth vendor, or a documented migration path between releases: the README does not cover upgrades. Before committing, verify three things in the repository itself: the environment variables the server reads against example.env, whether the packages/drizzle migrations match the schema you intend to ship, and how the v2.0.6 to v2.0.7 chat addition changed the API surface you plan to build on.

Frequently asked questions

Official sources

1. alan345/AI-Fullstack-SaaS-Boilerplate on GitHub
2. License: MIT
3. Project website
4. README
5. Releases