Supastarter vs SaaSy Land: Delete What You Do Not Need, or Never Generate It

Last updated 15 August 2026. Every claim about Supastarter is taken from its public site and documentation and linked at the bottom. Every number about this codebase comes out of its own test suite.

Start with the part that is not a criticism

If you have shortlisted Supastarter, you have taste. It is the most serious paid competitor in this category and it is nothing like the weekend templates that dominate the search results. 1,460 developers have bought it. It has been maintained properly for years. Its author is an engineer rather than a marketer, which shows in the code and in the documentation.

Four things it does that most of the category does not do at all:

A real monorepo, split four ways. apps/marketing, apps/saas, apps/docs and apps/mail-preview, each with its own package.json, next.config.ts, tsconfig.json, layouts and Playwright config. If you want the marketing site to deploy independently of the app, that is already done and it is a genuinely good default for a company that will eventually have a marketing team.

Payment options nobody else bothers with. Stripe, Lemon Squeezy, Polar, Creem and Dodo Payments. Creem and Dodo in particular are merchant-of-record providers that a European founder may specifically want for VAT reasons, and finding them supported out of the box is rare.

Auth that is actually finished. Password, passkeys, magic links, two-factor, OAuth, forgot and reset flows, roles and permissions, super admin and impersonation. That list is not marketing. Impersonation in particular is the feature every support team asks for on day 40 and nobody builds on day 1.

ORM choice. Prisma or Drizzle, your call. Many buyers have a strong preference here and being told which one to use is a real irritation.

Anyone telling you Supastarter is bloated weekend code has not read it. The rest of this article is a comparison between two credible options, not a takedown.

At a glance

The decision that happens before you type a command

Every starter kit answers one question before it answers any others: what does the buyer receive?

There are exactly two answers, and they produce entirely different two-year experiences.

Answer one: everything, and you delete. You clone a repository that contains every feature the product supports. Organizations, all five payment providers, the docs app, the mail preview app, the AI module. Then you remove what you do not need. Supastarter's documented start is npx supastarter new my-awesome-project, which the docs describe as cloning, configuring and installing.

Answer two: only the answers. You are asked questions. The generator writes the modules corresponding to your answers and nothing else. A single-tenant project has no organizations code anywhere in it. A project without billing has no Stripe webhook handler to read past. This is what the CLI configurator on our homepage does, live, in front of you: twelve questions, four optional features, and a command that changes as you answer.

Both are legitimate. Answer one gives you a complete reference implementation you can study, and there are days when having the code you do not need is better than not having it. Answer two gives you a smaller repository, which matters more than it sounds like it should.

Here is why it matters more than it sounds like it should.

Unused code is not free. It is read by every developer who joins. It is searched by every grep. It appears in every "find usages." It is walked by your bundler. It is loaded into the context window of every coding agent you point at the repository, which is now a real budget rather than a metaphor. And most of all, it is code you are responsible for and did not write, which is the worst combination in software.

The clearest version of the argument: if you scaffold single-tenant, how confident are you that no organization-scoped query is still running somewhere? With answer two the question is meaningless, because the code does not exist.

Why upstream merges get harder rather than easier

This is the part of the comparison I would want explained to me before buying anything, and it is rarely discussed.

Supastarter's documentation is explicit and, to its credit, honest about the mechanism. You "set the supastarter repository as the upstream origin for your project, so you can pull in updates in the future," with git remote add upstream https://github.com/supastarter/supastarter-nextjs.git. Fetch, merge, resolve.

On day one this works beautifully. You have changed almost nothing, so the merge is a fast-forward.

Consider month eighteen. You have rewritten the dashboard, restructured the billing UI, changed the user schema and deleted two apps you never used. Now a new version lands.

Three things are now true, and they are structural rather than anybody's fault:

The conflict surface is the intersection of their changes and yours, and it only grows. Every file you have touched is a file that can conflict. Your productivity as a builder is precisely what makes upgrading harder, which is an incentive nobody wants.

Deletions are not remembered. You removed apps/docs because you use a hosted docs product. The upstream still has it. Every future merge proposes it again. You re-make the same decision indefinitely, and one day you accept it by accident during a large merge and discover a docs app in production.

A merge is all-or-nothing at the commit level. The update contains a security fix for auth and a redesign of the settings page you have already redesigned. You want the first and not the second, and git will not help you separate them.

The alternative is not magic, and I want to be precise about that. A generator does not eliminate upgrade work. What it changes is the shape of it: because the tool recorded which modules you generated, an update can be expressed as a diff for exactly those modules, against a baseline that matches what you actually took. You can regenerate a clean project with the same answers and diff it against yours. That is a legible operation. Merging an eighteen-month-old fork of a four-app monorepo is not.

E2E tests and a coverage gate are different claims

Supastarter's documentation lists E2E testing with Playwright. That is real, it is more than most competitors offer, and I am not going to pretend otherwise.

It is also a different claim from the one this codebase makes, and the difference is worth understanding because both get filed under "has tests."

An E2E suite proves that the paths you wrote tests for work today. It runs a browser through signup, checkout, and a few flows. It is excellent at catching the catastrophic and useless at catching the specific.

A coverage gate prevents an untested branch from being merged at all. Here is the actual configuration, from this repository's vite.config.ts:

coverage: {
  thresholds: {
    branches: 100,
    functions: 100,
    lines: 100,
    statements: 100,
  },
}

Four numbers, all of them 100, all of them enforced. Today that gate runs across 141 test files and 472 tests. The src/app/** route layer and generated integration code are excluded, which is stated in the config rather than hidden, because gating on framework glue produces tests that assert nothing.

The practical difference shows up in a specific place: the error branch. Your webhook handler has a path for a signature that does not verify. Your invitation flow has a path for a token that expired. Your permission check has a path that returns false. An E2E suite almost never exercises those, because setting up a failing signature in a browser test is tedious and everyone skips it. A branch-coverage gate at 100 will not let you merge them untested.

And those branches are exactly where SaaS products fail, because they are the ones nobody runs by hand before shipping.

Four apps you might not want

The four-app monorepo is listed above as a Supastarter advantage, and for the right buyer it is. It is also worth naming the cost, because "monorepo" is a word people accept as automatically good.

Four apps means four package.json files, four tsconfig.json files, four Next configs, four build pipelines and four sets of dependency upgrades. If you are one person building one product, you are now operating a platform team's structure with a solo founder's time.

The alternative is not "no monorepo." It is deciding, rather than inheriting. The CLI configurator asks the shape question directly: monolith, split API, or microservices. Pick a monolith and you get one deployable and one dependency tree. Pick split and you get a frontend and a separate API. The architecture is your answer to a question rather than a property of the product you bought.

Architecture that is executable

Both products have an architecture. The difference is whether the compiler knows about it.

This codebase's module boundaries are lint rules, not documentation:

// vite.config.ts, abridged
{
  files: ["src/modules/*/domain/**/*.{ts,tsx}"],
  rules: {
    "no-restricted-imports": ["error", { patterns: [{
      group: ["react", "react/**", "next", "next/**", "drizzle-orm", "drizzle-orm/**",
              "~/src/app/**", "~/src/presentation/**", "~/src/platform/**",
              "~/src/integrations/**", "~/src/modules/*/infrastructure/**",
              "~/src/modules/*/application/**"],
      message: "Domain may only import shared-kernel domain and same-context domain code.",
    }] }],
  },
}

Three rules, in the same file. Domain code cannot import React, Next, the ORM, infrastructure or application code. Application code cannot import infrastructure. Presentation code cannot import Drizzle and must go through an application use case.

The result: you cannot accidentally put a database query in a React component. The build fails, with a message explaining why. That is the difference between a clean architecture and a codebase that used to have one.

This matters more every month, for a reason that has nothing to do with human developers. Coding agents learn a codebase's rules from what fails, not from the readme. A boundary that fails the build is a boundary an agent respects on its second attempt. A boundary that is a convention is one it will violate politely and repeatedly. We wrote about that in repository readiness for AI coding agents.

What each product actually costs

Supastarter's tiers are Solo at $299 for one developer seat, Startup at $799 for up to five seats with a consulting call and priority support, and Agency at $1,499 for up to ten seats, white-label ready, with a private Discord channel.

SaaSy Land is $249 for the codebase, $399 with the video masterclass, and $899 for the agency tier. All one-time. All unlimited projects. No seat count on any of them.

To be fair about it: the Startup and Agency tiers include real things beyond seats. A sixty-minute consulting call with the author has value. Priority support has value. Founder access in a private Discord has value. If those are what you want, the price is defensible and you should buy the thing you want.

But if what you want is source code, the seat count is a licensing decision rather than a product one, and it is the sort of decision that becomes irritating precisely when your company is going well.

Who should buy Supastarter

Buy Supastarter if you want a four-app monorepo out of the box and would build one anyway. If you need Creem or Dodo Payments specifically, because almost nobody else supports them. If you value a complete reference implementation you can read and prune yourself over a generator that decides for you. If a sixty-minute call with the author is worth several hundred dollars to you, which for some buyers it clearly is. If you are on Prisma and intend to stay there.

It is a good product with real customers and it will not embarrass you.

Who should buy this instead

Buy this if you want a repository containing only the code you asked for. If a 100% coverage gate is something you would actually maintain, because it is worthless to someone who will disable it in week two. If your architecture matters enough that you want it enforced by the linter. If your team is larger than one and you would rather not count seats. If you might not want Next.js, since TanStack Start and React Router are options here. If you want a store with sample products, a subscription course, a page builder or a visual post editor, which are optional extras here and not offered there.

And buy this if you spend a large part of your day working with coding agents, because everything above about enforced boundaries and a smaller repository is worth more to an agent than it is to you.

Related reading

Frequently asked questions

Sources

• Supastarter homepage, for pricing tiers, seat counts, the feature list and the customer count
• Supastarter documentation, for the monorepo structure and the four apps
• Supastarter setup documentation, for the CLI command and the git upstream update model
• SaaSy Land documentation and the configurator, for the module list and the scaffold questions
• This repository's vite.config.ts, for the coverage thresholds and the architectural lint rules quoted above

Written by Piotr J. Borowiecki, who builds SaaSy Land. Figures for Supastarter were read from its public pages on 15 August 2026 and may have changed since; the links go to the source rather than to a screenshot. If anything here is out of date or wrong, tell me and I will correct it.