Quand Sushi SaaS est un bon choix

Un starter ne fait gagner du temps que si vous voulez ses décisions. Sushi SaaS est un socle source pour relier identité, tenancy, facturation, usage et opérations ; il ne dispense pas de comprendre ces systèmes.

Choisissez Sushi SaaS si

• Next.js, TypeScript, PostgreSQL, Drizzle, Better Auth et Stripe correspondent à votre stack.
• Les clients travaillent seuls ou en équipe et facturation, crédits, fichiers, tâches et limites appartiennent à l’organisation.
• Argent et usage exigent idempotence, ledger immuable, replay webhook et rapprochement.
• Vous comptez opérer stockage privé, emails transactionnels, rate limits, jobs durables et erreurs localisées.
• Le support a besoin d’une console séparée avec MFA, rôles lecture/écriture, modération, inspection financière et audit.
• L’équipe valorise et maintiendra des frontières imposées et des tests de panne.

Le bénéfice n’est pas le nombre de pages, mais le modèle tenant et les invariants partagés par ces systèmes.

Choisissez plus léger si

• Vous validez la demande avec une landing page ou un prototype jetable.
• Le produit est individuel, sans paiement, ou une plateforme hébergée identité/base réduit l’exploitation.
• Base, framework, identité ou modèle de facturation requis contredisent la stack.
• Vous cherchez un no-code hébergé plutôt que du code possédé par l’équipe.
• Remplacer le modèle tenant ou conformité coûterait plus qu’un départ minimal.

Stratégies d’adoption

Garder le socle

Si la plupart des frontières conviennent. Remplacez marque et exemples, configurez les providers et bâtissez votre flux différenciant. C’est le chemin rapide et les mises à jour restent compréhensibles.

Retirer des capacités complètes

Si l’architecture convient mais pas un domaine. Retirez verticalement UI, routes, services, modèles, schéma, config, jobs, tests et docs ; ne masquez pas seulement la navigation en laissant un chemin de données sans propriétaire.

Copier un pattern

Pour une application existante. Emportez migrations, contraintes, tests et exploitation avec le code. Une fonction de crédits sans clé d’idempotence ni règle de base n’est pas le même pattern.

Partir ailleurs

Bonne réponse si stack ou modèle de propriété diffèrent. Un starter doit réduire les décisions futures, pas créer une longue réécriture avant le produit.

Le coût après clonage

Vous restez responsable des comptes providers, secrets, prix, taxes, remboursements, textes légaux, rétention, sauvegardes, exercices de restauration, monitoring, accessibilité, menaces et incidents. Il faut aussi remplacer l’adaptateur texte-vers-vidéo et décider si réservations et parrainage appartiennent au produit.

« Pensé pour la production » signifie que le dépôt expose responsabilités et contrôles ; il ne certifie pas votre déploiement.

Vérification en une heure

1. Lancez le Démarrage rapide et ouvrez les deux applications.
2. Mappez vos capacités indispensables aux pages et services réels.
3. Marquez garder, modifier ou retirer pour stack, organisations, facturation, crédits, stockage, jobs, langues, admin et parrainage.
4. Suivez un flux financier ou d’autorisation et lisez ses tests.
5. Estimez la colonne « modifier » ; si elle domine, choisissez une base plus petite.

Continuez avec Comment Sushi SaaS est structuré et Déploiement et sécurité. Évaluation fondée sur le commit 7580470.