Comparison
Choosing a SaaS starter: what to compare beyond the feature grid
Starter-kit landing pages compete on feature counts and hero gradients. The differences that actually cost you weeks are structural: where tenancy is enforced, who owns your sessions, whether billing works from your country, and what the test suite proves. Here's the evaluation we'd run — written by people who built a starter to pass it.
The six dimensions that matter
| Dimension | What to evaluate | What a typical boilerplate does |
|---|---|---|
| Stack | SvelteKit-native vs React/Next.js — pick by team skills, not hype | Most marketplace starters are React-first because the audience is bigger; a SvelteKit shop inherits context-switching tax forever |
| Tenancy model | App-layer org scoping vs RLS vs IdP org features — where each breaks | Boilerplates typically ship user-auth only; orgs are "coming in v2" or a thin teams table without hierarchy rules |
| Billing | MoR-based seats (works without Stripe country access) vs Stripe-first starters | Stripe Checkout snippets are the default; founders outside Stripe countries discover the wall after purchase, not before |
| Auth ownership | Your database (portable) vs vendor-managed sessions (convenient, sticky) | Managed-auth integrations dominate; migrating off them later means re-platforming every login |
| Audit log | Append-only, export-ready vs absent or add-on priced | Rarely present at all; usually a "log actions yourself" paragraph in the docs |
| Test surface | Which paths the boilerplate actually tests — most test none of the billing path | A smoke test of the homepage is common; invite edge cases, seat limits, and RBAC denial paths are almost never covered |
The right-hand column describes a composite of commonly-seen patterns, deliberately unnamed: naming products would require re-verifying each claim the week you read it, and stale criticism is worse than none.
A worked evaluation, in five minutes
- Clone and grep. Search the codebase for
org_idor equivalent. If tenancy is a docs page rather than schema columns, you found your answer. - Break an invite. Create two accounts, reuse an invite link twice, accept while over the seat limit. Honest starters fail these gracefully; fragile ones corrupt state or 500.
- Attempt self-promotion. As a member, POST a role-change request straight to the endpoint. A hidden button with no server check is the vulnerability class this catches.
- Count the tests touching money and access. Homepage smoke tests don't protect you; invite/seat/RBAC tests do.
- Read the billing seam. If the payment provider's name is smeared across the codebase instead of behind one interface, today's convenient choice becomes next year's migration.
Where our starter sits in these terms
Stated in the same dimensions, no adjectives: SvelteKit-native; app-layer tenancy enforced server-side on every request with strict owner > admin > member hierarchy; MoR-based seat billing behind a swappable adapter so country-constrained founders aren't locked out; sessions owned in your database as hashed tokens; append-only audit log written inside each mutation; 77 tests covering auth, invites, seats, RBAC denials, and audit paths. It doesn't do Next.js, SSO federation, or component libraries — see the product page for scope, stated plainly.
Related reading
- Multi-tenant Checklist — production readiness checklist
- Multi-tenant Authentication — how this starter models tenancy
- SvelteKit vs Next.js — framework comparison
- Product page — features, pricing, FAQ
- All documentation — guides, deep dives, and evaluations
Get in touch
Questions about the product, team licenses, or anything else? We'll respond within 48 hours.