We Counted Every Route in 5 Open-Source SaaS Starters. None of Them Build Your Product.

On 2026-08-23 we cloned five of the most-starred open-source SaaS starter templates on GitHub and counted every page route each one ships. Together they hold 53,876 GitHub stars and 69 routes.

Not one of those 69 routes is the product.

Every starter gives you a landing page, a login form and a settings screen. Zero of them give you the page where your user does the thing they came for. That is the finding, and the route lists below are printed in full so you can check it against the repos yourself.

The five starters

Star counts are what the GitHub API reported on the audit date. They are not tracked live, so treat them as a snapshot, not a current figure.

What they ship, counted

Each row is a page category, how many of the five ship it, and the test used to count it. The test is stated so you can re-derive each number by hand from the route lists.

The three numbers worth arguing about

0 / 5 ship the product's own workflow. This is the headline. A SaaS starter is sold as a head start on a SaaS product, but none of the five contains a page that takes a user's input, runs a job on it, and shows a result. The nearest misses were a Stripe checkout-result page and an organisation-selection step — neither is the product doing its work — plus a generic progress component, which is not a page at all. We counted it as zero rather than rounding up.

2 / 5 ship billing. Subscription revenue is the defining characteristic of SaaS, and three of the five most-starred SaaS starters leave you to wire up payments yourself. If you picked a starter assuming billing was handled, check before you plan your timeline.

5 / 5 ship authentication. Auth is the single most reliably solved problem in the category. It is also the one most founders assume will be the hard part. It isn't — it's the part everyone has already built for you.

Why the distribution looks like this

The pattern isn't laziness. It is the only thing a starter template can do.

Auth, settings and a landing page are identical across every SaaS product ever built, so they generalise perfectly and a template can ship them once for everyone. Your product's core workflow generalises to nothing — it is the part that differs between your product and every other product, which is precisely why it's the part you are building a company around.

So the honest reading is not "these starters are bad." Several are excellent at what they do. The honest reading is that a starter removes the commodity work and leaves 100% of the differentiated work, and the differentiated work is where essentially all of the schedule risk lives. A founder who budgets two weeks because "the boilerplate handles it" has budgeted for the part that was already free.

What to do with this

Three practical consequences:

1. Pick a starter for its auth and billing, not its dashboard. Those are the parts you genuinely inherit. Count the billing routes before you commit — only two of five have them.
2. Budget your schedule around the pages that appear in zero starters. Your intake page, your run/processing state, your result view, your share view. Nobody has written those for you.
3. Check the route list, not the README. Every starter's README describes an ambitious product. The routes directory describes what actually exists. The gap between the two is the work you just signed up for.

Method, and its limits

Five repositories, cloned and read on 2026-08-23. Page routes were counted from each project's routing directory; API handlers, middleware and components were not counted as pages. Where a route was genuinely ambiguous — CMSaasStarter's /account is both its settings area and its signed-in home — it was counted once, under settings, and the ambiguity is recorded rather than smoothed over.

Limits worth stating plainly: five repositories is a small sample chosen by star count, not a random sample of the category. Star counts favour older and more heavily marketed projects. A different five would shift the middle rows of the table. The 0/5 finding on product workflow is the one we would expect to hold across any sample, because it follows from what a template can generalise, not from which templates we picked.

The underlying data — every route, verbatim, per starter — is published and readable at saasreadyit.com/designing-your-app, where each count is shown next to the routes that produced it.

This audit was run by SaaSReadyit, which writes AI-generated market-validation reports for software ideas. The figures above are counted from public repositories, not generated by a model.