Qu’est-ce que Sushi SaaS ?
Ce que contient le starter, les choix produit qu’il fait et comment décider d’en adopter tout ou partie.
Sushi SaaS est un starter open source sous licence MIT pour les produits par abonnement ou à l’usage. Ce n’est ni une plateforme hébergée, ni un générateur d’application par formulaire. Vous clonez le dépôt, devenez responsable du code obtenu et adaptez ses choix produit à vos utilisateurs.
Documentation ou Guides ?
Utilisez la Documentation lorsque la tâche est connue et que vous cherchez les étapes exactes de configuration, d’extension, de vérification ou d’exploitation du code publié. Utilisez les Guides pour décider si un choix convient, comprendre sa raison et savoir quoi conserver, modifier ou supprimer. Ce sont deux étapes du même parcours d’adoption.
Pour qui ?
Évaluez Sushi SaaS si vous êtes développeur ou une petite équipe déjà orientée vers Next.js, TypeScript, PostgreSQL, Drizzle, Better Auth et Stripe. Il apporte le plus de valeur si le produit a aussi besoin d’organisations, de crédits partagés, d’uploads privés, de tâches en arrière-plan, d’une interface localisée et d’une console opérateur.
Préférez une base plus légère pour valider une landing page, construire un outil mono-utilisateur sans paiement ou remplacer la majorité de cette stack. Commencer avec moins de contrats coûte moins cher que supprimer ceux dont vous n’avez jamais voulu.
Ce qui est livré
Le dépôt contient trois applications déployables et un worker portable :
- l’application client
src/app, avec auth, organisations, facturation, crédits, stockage privé, réservations et tâches payantes de référence ; apps/admin, avec MFA, rôles, reprise des jobs, modération, rapprochement, facturation et audit ;apps/content-studio, application Payload avec base et auth éditoriale propres ;- un worker durable pour VM/conteneurs ou scheduler.
Web et admin partagent schéma et auth SaaS ; Content Studio jamais. Identité, consentement et audit de livraison restent dans le SaaS. Le site public est un quatrième dépôt indépendant.
Les décisions héritées
| Choix livré | Pourquoi | Quand le revoir |
|---|---|---|
| Couches horizontales route → service → modèle → base | Donne une place prévisible aux règles métier et aux requêtes | Votre équipe a adopté une autre architecture et modifiera aussi les tests qui l’imposent |
| Chaque compte possède ou rejoint une organisation | Donne à la facturation, aux fichiers, crédits et limites une frontière tenant unique | Le produit est réellement mono-tenant et vous retirez le scope organisation de bout en bout |
| Les événements Stripe finalisent la facturation | Considère retry et webhook tardif comme des entrées normales | Votre fournisseur ou modèle commercial diffère |
| Admin déployé séparément | Isole l’accès opérateur de la navigation client | Vos opérations sont assez simples pour partager application et frontière de déploiement |
| Cinq langues produit | Localise l’interface et les erreurs visibles | Vous en gardez moins et retirez ensemble routes, catalogues et tests associés |
Ce sont des valeurs par défaut, pas une affirmation que tous les SaaS doivent choisir pareil.
Trois façons de l’adopter
- Conserver tout le socle. Gardez les frontières, remplacez la marque et les exemples, puis configurez fournisseurs et politiques.
- Adopter certains patterns. Copiez un ensemble autonome—comme le ledger de crédits ou la gestion des replays Stripe—avec migrations, tests et règles opérationnelles.
- L’utiliser comme référence. Comparez ses échecs et invariants avec votre système sans reprendre le code.
Évitez une demi-migration où deux architectures ou modèles de tenancy coexistent : chaque changement aurait deux emplacements apparemment corrects.
Ce qui reste à votre charge
Le starter ne choisit pas vos prix, remboursements, rétention, textes légaux, processus support, objectifs de sauvegarde, contrôles antifraude ou modèle de menace. Les récompenses de parrainage sont désactivées car un paiement relève du métier et de la conformité. Le provider texte-vers-vidéo et le parcours de réservation sont des exemples d’intégration, pas une proposition produit finalisée.
Une évaluation concrète
- Suivez le Démarrage rapide et ouvrez client, admin, Content Studio et worker.
- Suivez un flux dont vous avez besoin—inscription, Checkout, upload ou dépense de crédits—de la route à la base.
- Lisez Quand Sushi SaaS est un bon choix et listez les décisions à garder, modifier ou supprimer.
- Consultez Déploiement et sécurité avant d’estimer la mise en production.
Source : starter Sushi SaaS au commit 2a1a04a.