What people ask SaaS templates for, and what I changed in mine

I was looking at a preview of the new CrabStack landing page, and I liked the design, but it read like a page selling the template. Big CrabStack name, sentences about sign-in and billing, screenshots of the admin panel.

(Quick context if you don't know it: CrabStack is a SaaS template I sell as code, a NestJS backend and a Next.js frontend on Postgres, with sign-in, Stripe billing, email, a blog and an admin panel wired together. $199 for one developer or $349 for a team, paid once.)

Nobody buys a template so their customers can read about the template. So before changing anything else I went through what people who use the other templates say, in their GitHub issues and on HN, and wrote down every request and complaint I could find in their own words. Then I checked my own template against the list.

Two things about where these quotes come from. First, only people using a template count: a lot of the loudest quotes out there turned out to be from people selling a competing kit (including a couple I was about to use), so those are out. Second, almost all of them are from free open-source starters like next-forge and Open SaaS, because that's where the conversation is public. The paid kits (ShipFast, Makerkit, supastarter, and mine) don't have public issue trackers, so read this as "what people run into with templates", not as a scorecard of those two projects. Several of the problems below they've since fixed, and I say so where I found it. Reddit wouldn't load for me, so it's not in here.

"Building the entryway separately to the rest of the house"

That line is from an HN comment about a SvelteKit starter, and it's the best summary of the landing page problem I found: "It's easy to make few elements look good for a landing template. I never get the point of these SaaS starters, it's like building the entryway separately to the rest of the house." (HN)

And what people do with the landing page they get, is remove it. On ixartz's Next.js boilerplate one fork "Replaced home and about pages with minimal placeholders" while removing "all demo-specific content so the boilerplate starts clean" (PR #549), and another titled their PR "set up health app auth, dashboard, and remove marketing pages" (PR #557).

So the CrabStack landing page is a kit of sections now: a hero, feature rows, pricing, an FAQ and a closing call to action, each one a component that takes its words as props. My first pass wrote the sample copy for an invented product (a customer-feedback inbox), and I didn't like it, so now it describes what the app you clone does for its own users (sign in with an email link, a workspace for your team, invites, API keys), which means every line on it is true on day one. All of it sits in one file you rewrite for your product. The pictures are empty frames labelled with what goes in them. Until you flip one flag, the server prints a warning at startup that the landing still has sample copy.

Restyling it shouldn't mean refactoring it

On Open SaaS, a user who had added shadcn ended up with three styles to reconcile: "OpenSaaS-App, OpenSaaS-Admin and Chadcn. Everything comes in light and dark mode. Now refactoring everything to be consistent is a lot of annoying work" (open-saas #95). On next-forge someone restyling the auth screens "tried to have the .css variables to design it, but it became to much work" (next-forge #499).

The asks are pretty consistent too. Dark mode ("Light/Dark/System themes would be awesome", nextjs-subscription-payments #279; "Add dark mode to all pages", still open on nextjs/saas-starter #44), and shadcn/ui. One Open SaaS user said the only reason they were looking elsewhere was a kit that "incorporates ShadCN from the ground up" (open-saas #415), and another voted for it because "It's LLM-friendly since the component code is scaffolded into your project" (open-saas #415). Open SaaS listened, by the way: by October 2025 they had moved to shadcn.

In CrabStack every colour, radius, font and shadow is now a CSS variable in one stylesheet, named the way shadcn/ui names them where it has a name, with a light and a dark value. Dark mode follows the system, with a System / Light / Dark switch that's remembered in a cookie and rendered on the server, so the page never flashes the wrong theme first. A test checks the text colours against WCAG AA in both themes. The template ships no Tailwind and no UI library of its own (just a small set of components), and there's a recipe for adding Tailwind and shadcn/ui on top of the same variables so your brand and dark mode carry over. I tested that recipe on a fresh copy before writing it down.

"Removing things i dont need is incredibly annoying/breaks everything!"

That's from next-forge (#426), where another user in the same thread called removing packages "a headache" that "takes significant amount of time just to even start the projects properly" (#426), and a team listed what they had spent time ripping out: "cms, docs, collaboration, notifications, and webhooks" (#514).

There's a new recipe in CrabStack for exactly this, "Remove a feature you don't use". It covers deleting the blog and the admin MCP server, and I had an agent follow it on a fresh copy and run the full test suite. The first blog run failed twice, which is the point of doing it (those fixes are steps in the recipe now). Billing I couldn't remove cleanly, it's tied into the item limit and account deletion, so the recipe tells you how to leave it switched off, which it is until you add a Stripe key.

Three hours of setup

This was the most quoted thing in my notes. A November 2025 comment on a next-forge issue: "Trying to fight with this for the past 3 hours, what a painful experience is this setup." (#647) Same thread, two more people: one "Unfortunately decided to go with a different template" (#647) and another "Ultimately couldn't hit the ground running and abandoned using this for now" (#647). The maintainer had written about it a year earlier, "The reliance on 30ish environment variables makes next-forge difficult to spin up quickly" (#251), and closed that issue as done at the end of 2024.

CrabStack isn't small either: about 600 files and 31 environment variables across the two halves. What I can do is make the first run cheap. There's one ./setup.sh now that installs both halves and writes the env files (generating the secrets), then tells you how to start it, and billing and the OAuth providers stay off until you add their keys, so a local run doesn't need a single outside account.

Agents get lost

"Due to its size, its hard for cursor to keep context" is from next-forge in February 2025 (#454), and their answer, a year later, was to ship a Claude Code skill. On Bullet Train: "I've been working with it with Claude code for the past two hours, and still don't have it running locally." (bullet_train #2176) Around the same time their maintainer proposed adding an AGENTS.md (#2324).

This part CrabStack already had: an AGENTS.md with a "you want to do X, read Y" table, a CLAUDE.md for each half, and a skill for adding a module. Every feature has the same folders and the same checks, so once the agent has seen one it knows where the next one goes.

Sample data in production

I didn't find a template user saying demo data ended up in their production app, so I won't pretend I did. What I found is a reviewer who went through 162 kits and flagged one that "sets VITE_USE_MOCK=true in .env.production, so a production build ships fake data" (dev.to) (in fairness to that template, a comment right in the file says it's a demo and tells you to set it to false), and a maintainer of Open SaaS worried about the same thing with placeholder legal pages: "they forget to update them, and they have wrong stuff there wrong privacy and similar" (open-saas #392).

Then I checked my own template and found it there. The deployment guide told you to run the seed script in production, and the seed publishes sample blog posts and queues emails to @example.com addresses that the worker would try to send. The seed now refuses to run in production and the guide doesn't mention it, and the startup warning lists every page still on placeholder content (the landing copy, the privacy page, the terms page).

Taking updates

"Once I have created my own instance, what is the best way to get all the latest changes? ... What if I add my own code?" (next-forge #279) Same question on ixartz's boilerplate (#365), and an HN commenter put the trade-off plainly: "if I want updates I'd need to merge in upstream and manage merge conflicts etc with own changes" (HN).

CrabStack has a guide for pulling upstream into your copy, and the changelog lists every file that moved. This one is only partly done, there are no version tags yet, so you can't diff release to release.

Tests you can see in a browser

"There is no mention of end-to-end (E2E) testing in the documentation" (next-forge #604), and a still-open request to "add playwright configuration" (next-forge #602).

CrabStack had over a thousand unit and integration tests, and a CI that checks routes, deletions and the API contract, but nothing that opened a browser. Now CI runs a small Playwright test against the production build (the pages load, the 404 works). Small on purpose, it's there so you have the setup when you write your own.

What people asked for that I didn't have

Complaints only show what hurts, so I also counted requests for things that weren't there, by the number of different people asking rather than by issues. Three came up again and again.

Teams. On Open SaaS: "The entire projects assumes that an user can only be an admin or not. Any idea how to overcome this without touching tens of places?" (open-saas #639), and later from the same person, "I did my own, but I spent two days to make it work." Others on the same tracker: "If you introduce Shadcn and basic multi tenant support, this will be used by many more" (#415) and "I came here looking for multi-tenacy." (#415)

CrabStack had one admin flag per user, the exact situation in that first quote. So it has workspaces now: owner, admin and member roles, email invites, and every account gets a personal workspace from the start, so nobody retrofits anything later. A workspace runs on its owner's plan, which kept the billing code as it was, and there are tests that a member of one workspace can't read or write another's data. One more signal I took from this: four people (three on ixartz's SaaS boilerplate, #55, and one on BoxyHQ's) asked to skip a forced "create an organization" step at sign-up, so the personal workspace is created quietly and you never see a step for it.

Languages. "I live in Switzerland, everything needs 2-4 Languages" (open-saas #23, open since February 2024), "I really need multiple languages!" (same issue), "Is it possible to add i18n?" (next-saas-stripe-starter #34). That setup is in now, with next-intl. It ships in English, and every word the interface shows is in one file, so a new language starts as a translated copy of that file plus one line in the config. The emails stay English until you translate them too, the "Add a language" recipe covers both.

Paying with something other than Stripe. 21 different people asked across the trackers I could read, usually for one of two reasons. Either Stripe isn't available where they are ("Stripe isn't available in India, and several other regions (parts of SEA, LATAM) have the same issue. Users hit a dead end at setup with no first-class alternative", next-forge #730), or they want a merchant of record to handle sales tax for them. Open SaaS has since added Lemon Squeezy and Polar.

CrabStack stays on Stripe for now. crabstack.dev itself sells through that same Stripe code, so it's the one payment path that gets used for real every day, and a second provider would ship without that. Billing sits behind one module (the rest of the app only asks "what plan is this user on?"), so it's a reference if you write your own for Paddle or Lemon Squeezy. But if Stripe doesn't work where you are, CrabStack isn't a good fit yet.

Lower down, with a few people each: Supabase auth, an Expo mobile app, a monorepo setup, one-time payments, API keys for your own customers, and free trials. API keys and one-time payments I've added since: a workspace can make keys for its own scripts (shown once, stored only as a hash, and limited to that workspace's items), and billing has an optional Lifetime product, paid once through Stripe Checkout, that gives Pro. Things I expected to find and didn't (one person or none, or only vendors asking): audit logs, feature flags, outbound webhooks, analytics, impersonation, usage-based billing. People may still want them, they just aren't asking for them in public on these templates.

Thanks for reading!

If you've used a template before (mine or anyone's), what did you rip out first, and what did you have to build yourself? I'd really like to know, it goes straight into the next list.

Best Regards
Carl-W.