Starter kit ou from scratch ? Décidez ce que vous voulez posséder

Séparez le travail produit de l'infrastructure répétée

Listez les fonctionnalités qui rendent votre produit utile, puis l'infrastructure nécessaire à son fonctionnement. Un flux de recherche peut être distinctif ; la gestion de session, les enregistrements appartenant au client et l'accès abonnement ne le sont généralement pas. Cet inventaire est un meilleur outil d'évaluation que le nombre de fonctionnalités sur la page d'un starter.

La seconde liste est plus longue qu'elle n'en a l'air. La plupart des produits SaaS réimplémentent la même douzaine de pièces, et chacune doit s'intégrer correctement aux autres avant que le produit puisse faire quoi que ce soit.

Construire from scratch donne un contrôle direct sur ces choix, mais aussi la responsabilité de les intégrer et de les maintenir. Un starter change le point de départ. Vous devez toujours comprendre son code et vérifier les hypothèses qu'il fait sur votre produit, votre équipe et votre déploiement.

• Identité : méthodes de connexion, sessions, récupération de compte.
• Espaces de travail : appartenance des enregistrements, invitations, rôles des membres.
• Facturation : checkout, webhooks, droits d'accès, annulation.
• Travail en arrière-plan : files, retries, planifications, suivi de statut.
• Livraison : e-mail transactionnel, stockage de fichiers, déploiement.

Comparez le coût total, pas le prix affiché

Le prix d'un starter est visible ; le coût du from scratch se répartit sur des mois. Faites le compte honnêtement : les semaines passées à assembler auth, facturation, jobs et déploiement ; les bugs d'intégration livrés avec ces assemblages ; et la maintenance que chaque mise à jour fournisseur déclenche ensuite.

Le coût du starter, c'est d'apprendre et d'adapter du code que vous n'avez pas écrit : lire ses conventions, remplacer le contenu d'exemple, tordre parfois une frontière qu'il a tracée. Quand l'inspection ci-dessous se passe bien, ce compromis revient généralement moins cher que de reconstruire la même plomberie. Quand il se passe mal, c'est un avertissement à ne pas ignorer — une frontière illisible aujourd'hui est un incident de production l'an prochain.

Évaluez le code que vous allez hériter

Exécutez les instructions d'installation et suivez un enregistrement de l'interface à la persistance. Vérifiez si l'autorisation vit à la frontière serveur, si la configuration est validée et si les identifiants fournisseur restent hors des bundles client. Lisez un test négatif, pas seulement l'écran de démo.

Cherchez les endroits où le produit d'exemple est devenu inséparable de l'infrastructure. Si retirer une fonctionnalité de démo exige de modifier l'authentification ou la facturation, le travail produit futur sera peut-être plus dur que l'installation initiale ne le suggère. Dans supastack, les produits consommateurs gardent leur logique métier hors de Starter Core et se connectent via la configuration et les contrats — le guide de structure du projet montre où passe cette ligne.

• Chaque étape d'installation non documentée que vous avez dû deviner vous-même.
• Où l'autorisation est appliquée, et si elle l'est par route ou systématiquement.
• Si un test négatif existe — une lecture inter-espaces, un webhook rejoué — et ce qu'il prouve.
• Où vivent les secrets, et si l'un d'eux atteint un bundle client.
• Ce qu'il advient de l'infrastructure quand vous essayez de supprimer une fonctionnalité de démo.

Faites-le tourner avant de décider

Passez une journée dans le dépôt avant de vous engager. Dans supastack, cela veut dire corepack pnpm install, un apps/web/.env.local configuré, et le flux de référence local : connexion, inspection de l'accès, soumission d'une tâche, lecture de son résultat. Ensuite pnpm verify:local exécute le chemin nominal contre des fournisseurs fake sans aucun identifiant requis — le guide d'installation locale parcourt la séquence.

Puis cassez quelque chose exprès. Soumettez la même tâche deux fois. Appelez une route API avec le mauvais espace de travail. Rejouez un webhook. Un starter qui gère l'échec ordinaire avec grâce vaut plus qu'un starter à la liste de fonctionnalités plus longue, car ce que vous ne pouvez pas faire échouer proprement sur votre machine, vous finirez par le déboguer en production.

Rendez le compromis explicite

Choisissez un starter quand ses frontières existantes correspondent à vos besoins et que vous pouvez expliquer le flux dont vous dépendrez. Choisissez une fondation sur mesure quand les contraintes du produit forceraient des changements répétés aux hypothèses du starter. Les deux choix peuvent être raisonnables ; la question importante est quelle charge de maintenance votre équipe peut porter.

Réservez du temps pour remplacer le contenu d'exemple, configurer les intégrations, revoir l'appartenance des données et tester le déploiement. Un dépôt qui compile est un point de départ pour l'acceptation en production. Avant le lancement, vérifiez le vrai chemin de connexion, le cycle de vie de facturation et le comportement de reprise dans l'environnement que vos clients utiliseront — la checklist de lancement l'énumère. Et si la stack sous-jacente est aussi indécise, choisir une stack SaaS couvre l'évaluation couche par couche ; les deux décisions s'éclairent mutuellement.

Questions fréquentes sur les starter kits

Le débat acheter-ou-construire suscite des opinions fortes. Voici les questions qui font réellement bouger la décision.

• Utiliser un starter kit est-il risqué pour un produit sérieux ? — Beaucoup de SaaS en production tournent sur des fondations achetées. Le risque n'est pas le starter ; c'est d'hériter de code que vous n'avez pas inspecté. Lisez les frontières avant d'en dépendre.
• Comment savoir si un boilerplate est maintenu ? — Cherchez des commits récents, un chemin de mise à jour documenté, des tests qui exercent les cas d'échec, et des issues auxquelles on répond par des détails plutôt que des promesses de roadmap.
• Et si les choix du starter ne correspondent pas aux miens ? — Distinguez les préférences des contraintes. Repeindre une UI coûte peu ; se battre contre un modèle de session ou une frontière de tenant, non. Un décalage structurel est une raison de construire le vôtre.
• Puis-je quitter un starter plus tard ? — Vous possédez le code, donc il n'y a rien dont il faille migrer — la vraie question est de savoir si sa plomberie reste un atout à mesure que vous la modifiez, et c'est pourquoi la séparabilité du code produit et du code d'infrastructure compte.
• Combien de temps un starter fait-il vraiment gagner ? — En gros les semaines qu'auraient pris auth, facturation, jobs et déploiement, moins les jours nécessaires pour apprendre et adapter ce que vous avez hérité.