Better Fullstack: a scaffold generator that mixes languages inside one project
Scaffold production-ready full-stack apps in TypeScript, Rust, Python, Go, and Java with a visual builder and CLI. Choose your frontend, backend, database, auth, AI, payments, and DevOps integrations, all wired together.
At a glance
- What is it?
- Better Fullstack generates full-stack starter projects from a catalog of "Stack Parts", through a CLI, a browser builder, or an MCP server for coding agents. Its distinguishing claim is that frontend and backend can come from different language ecosystems, and that the result stays editable through a recorded configuration file.
- Who is it for?
- Adopt Better Fullstack if you want a starting point that pairs, say, a TypeScript frontend with a Go backend, and you accept that the generated tree is a template you will own and edit. Skip it if you need a stable, long-lived internal generator with a documented migration path, or if you cannot tolerate a project whose compatibility rules are enforced by a shared engine you cannot see from the README.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap Better Fullstack targets: one repo, several language runtimes
Most full-stack starters pick a single language and stay inside it. A TypeScript meta-framework gives you the frontend and the API in one runtime. A Go or Rust template gives you a server and expects you to bolt a frontend on yourself. Better Fullstack takes the opposite position. Its README describes "Multi-Ecosystem mode", which composes "frontend, backend, database, and mobile parts from different languages, like a TypeScript frontend with a Go backend". The repository topics list the span: TypeScript, Rust, Go, Python, Java, .NET, Elixir, React Native, Next.js, Drizzle ORM, shadcn/ui, TanStack. The audience is a developer who has already decided on a polyglot shape, perhaps because a team owns a Go service and a React app and wants both generated with matching wiring, and who does not want to hand-assemble the glue. It is not aimed at someone who wants a single opinionated framework chosen for them.
Stack Parts, the compatibility engine, and what bts.jsonc records
The unit of composition is the "Stack Part". You choose parts across categories the description enumerates: frontend, backend, database, auth, AI, payments, DevOps integrations. The README states that "the CLI and the builder share one compatibility engine, so invalid combinations are rejected or adjusted before any file is written". That ordering matters. Validation runs before the filesystem is touched, which means a bad combination fails as a message rather than as a half-written directory tree you have to delete by hand. The second half of the mechanism is persistence. "Every project stores its configuration in bts.jsonc and bts.lock.json", and those two files are what the add, update, and check subcommands read to "extend and repair what was generated later". So the generated project is not a one-shot dump. It carries its own manifest, and the tool can be re-run against an existing project rather than only at creation time. The README does not spell out the schema of bts.jsonc or the exact semantics of "adjusted" when a combination is invalid, so treat those as things to read from a generated example rather than from the front page.
Three front doors: CLI, browser builder, MCP server
The same catalog is reachable three ways. The CLI is the conventional path, invoked through a package runner. The Stack Builder runs in the browser at better-fullstack.dev/new and, per the README, "hands you the command to copy, or a ZIP download". The notable claim there is "No Node.js and no terminal required", which is a real difference from most scaffolders: the generation happens server-side or client-side in the browser, and you receive an archive. That is useful on a locked-down machine or for someone evaluating a combination before installing a toolchain. The third door is the MCP server, installed with a single command, which lets a coding agent drive the scaffolder. The README states that after install, "supported agents scaffold projects through the MCP server, 2.6x faster than hand-writing in ScaffBench". That figure comes from the project's own ScaffBench, and the README does not describe the benchmark's methodology, so it should be read as a project claim rather than an independent measurement.
Getting a project on disk: the actual commands
The README gives four equivalent quick-start invocations, one per package manager. With Bun it is `bun create better-fullstack@latest`. With pnpm, `pnpm create better-fullstack@latest`. With npm, `npm create better-fullstack@latest`. With Yarn, `yarn create better-fullstack@latest`. The published package name is `create-better-fullstack`, which is what the create aliases resolve to. For the agent path the command is different: `npx create-better-fullstack@latest install`. That installs the MCP integration rather than scaffolding a project, and the README points to the AI docs at better-fullstack.dev/docs/ai/overview for the per-agent setup. If you prefer not to run any of this locally, the browser builder at better-fullstack.dev/new produces either a copyable command or a ZIP. What the README does not give is the flag surface for the CLI: the subcommands add, update, and check are named, but their arguments and options are not listed in the material available here.
Where the model strains: generated glue and polyglot drift
A scaffolder that spans eight language ecosystems inherits the maintenance surface of all of them. The generated project is a snapshot: it wires a Go backend to a TypeScript frontend at the moment of generation, using whatever conventions the compatibility engine knew about at that version. Nothing in the README suggests the wiring is re-derived automatically as upstream frameworks change. The update and check subcommands read bts.jsonc and bts.lock.json, which implies they can re-apply parts, but the README does not claim they migrate your hand-edited code. Once you modify generated files, which you will, the lock file describes the original configuration rather than the current state of the tree. There is a second, quieter cost. The project ships three releases in the sample shown (v2.6.3, v2.6.4, v2.6.5 across roughly ten days in late August and early September 2026), which is a fast cadence for a tool whose output becomes the foundation of a repository. Fast cadence on a generator means the recommended output can shift between the version you scaffolded with and the version a teammate scaffolds with six weeks later. Pinning the scaffolder version is the obvious mitigation, and the README does not discuss it.
What it is not: the case for staying with a single-runtime starter
The honest alternative is the template it was forked from. The README states that Better Fullstack "was originally forked from Better T Stack by Aman Varshney and is now independently maintained with its own direction". Better T Stack's scope is a TypeScript-centric stack: a TypeScript frontend and a TypeScript backend sharing types across the boundary. The difference in approach is not cosmetic. In a single-runtime starter, the frontend and backend share a type system and often a build pipeline, so a change to an API shape surfaces as a compile error on both sides. In Better Fullstack's multi-ecosystem mode, a TypeScript frontend calling a Go backend has no shared type checker; the contract lives in whatever schema or generated client the parts agree on. If you do not specifically need two runtimes, the single-runtime starter removes a whole category of failure. Choose Better Fullstack when the polyglot split is a requirement you already have, not as a default.
Licence, maintenance, and what the MIT terms do and do not settle
The repository is MIT-licensed. That is permissive: you can use the generated output and the tool itself in commercial and closed-source work, and the fork lineage from Better T Stack is stated openly in the README. MIT covers the code, not the names or logos of the third-party parts you select, and it says nothing about the licences of the frameworks the scaffolder wires together. A generated project that combines a Next.js frontend, a Drizzle ORM data layer and a Go service carries the licence obligations of each of those projects, and those are your obligations, not Better Fullstack's. This is not legal advice; if the combination matters commercially, check each selected part's licence before you ship. On maintenance, the visible signals are the release cadence and the fact that the project is independently maintained rather than archived. The README invites bug reports and contributions through GitHub issues and a contributing guide, and it lists GitHub Sponsors and Patreon as funding channels, which is worth knowing because a generator's value depends on it tracking upstream frameworks after you have stopped looking.
Editorial conclusion
Adopt Better Fullstack if you want a starting point that pairs, say, a TypeScript frontend with a Go backend, and you accept that the generated tree is a template you will own and edit. Skip it if you need a stable, long-lived internal generator with a documented migration path, or if you cannot tolerate a project whose compatibility rules are enforced by a shared engine you cannot see from the README. Before committing, scaffold one throwaway project and inspect three things: what bts.jsonc actually records, whether bts.lock.json pins versions in a form you can diff in review, and whether the add and check commands behave on a part you know well.
Community notes