Une fondation sur laquelle construire.

Le travail que chaque produit répète

Un nouveau produit commence par un problème particulier. Ses premières semaines semblent souvent bien moins particulières : sessions, enregistrements d'espace, état d'abonnement, travail en arrière-plan et livraison d'e-mails. Ces pièces doivent coopérer avant que le produit puisse faire quoi que ce soit d'utile — chacune est un problème résolu dans l'abstrait et un risque d'intégration dans le concret.

supastack donne un domicile à ce travail répété. Une application web Next.js et une application mobile Expo partagent des packages TypeScript pour l'infrastructure sous-jacente. L'objectif est de rendre ces frontières assez compréhensibles pour qu'un produit les configure sans hériter du modèle métier de quelqu'un d'autre.

Aucune de ces pièces n'est difficile isolément. Le coût vit dans leur coordination — un paiement qui doit devenir un droit d'accès, une session qui doit devenir un périmètre d'espace, une tâche qui doit survivre à la fermeture d'un ordinateur portable. Les produits échouent rarement sur une fonctionnalité manquante. Ils échouent sur une jointure.

Pourquoi le construire une fois, correctement

L'argument d'une infrastructure partagée n'est pas que ce travail est en dessous de vous — c'est que le travail répété mérite d'être fait une fois, avec soin. Une frontière d'espace de travail bien implémentée dans un module partagé protège chaque produit construit dessus. La même frontière improvisée produit par produit devient un ensemble de quasi-réussites qui diffèrent de façons intéressantes et dangereuses.

Cela concentre aussi la maintenance. Les API des fournisseurs changent, les bibliothèques d'auth évoluent, la sémantique de facturation dérive. Quand ces changements atterrissent en un seul endroit — la documentation des modules du kit les suit — un correctif se propage au lieu d'être réappris par projet. Et quand vous pesez le compromis pour un seul produit, starter kit ou from scratch applique le même raisonnement à la décision acheter-ou-construire.

L'infrastructure partagée concentre aussi la relecture. Une frontière qui vit en un seul endroit peut être testée durement une fois — cas négatifs, événements rejoués, tentatives inter-tenants — au lieu d'espérer que cinq réimplémentations l'aient chacune réussie. C'est en partie pourquoi le kit investit dans sa suite de tests : maintenir la confiance dans du code partagé coûte moins cher que de la regagner par projet.

Donnez à chaque module une responsabilité

L'identité établit qui fait une requête. Les espaces de travail déterminent à quels enregistrements cette personne peut accéder. La facturation enregistre l'état de paiement, tandis que les droits répondent si une capacité est disponible. Garder ces préoccupations distinctes empêche qu'une redirection de paiement réussie devienne une décision d'autorisation.

La même discipline s'applique au travail en arrière-plan. Le contrat JobRunner partagé promet enqueue, status et cancel. Trigger.dev possède le comportement de workflow. Une petite interface a de la valeur quand ses limites sont visibles ; cacher les retries ou la planification derrière une méthode générique rendrait le système plus difficile à raisonner.

Better Auth répond à l'identité. Postgres et Drizzle tiennent les enregistrements. Stripe ou Lemon Squeezy rapportent l'état de paiement. Aucun d'eux n'est prié d'être malin sur le travail d'un autre module — les jointures restent assez étroites pour être raisonnables — et une fondation ne vaut que par ses jointures.

Laissez de la place au produit

Un flux de prospection, un éditeur de documents et un assistant de recherche peuvent utiliser les mêmes modules d'identité et de facturation. Leurs enregistrements, leur langage et leurs flux restent différents. La logique propre au produit appartient au codebase consommateur, avec la configuration qui la relie à la fondation.

Cette séparation est aussi une décision pratique de maintenance. Un correctif d'isolation d'espace doit être réutilisable. Un changement dans la façon dont un produit évalue un prospect ne doit pas devenir une nouvelle exigence pour tous les autres produits.

Voilà la différence entre une fondation et un thème. Un thème vous donne un look à garder ou à remplacer. Une fondation vous donne des décisions structurelles — qui possède l'identité, comment les enregistrements sont rattachés, où un paiement devient un accès — sur lesquelles un produit s'appuie plutôt qu'il ne les contourne. Le guide de structure du projet montre où l'une s'arrête et où l'autre commence.

Commencez par un flux complet

Démarrez avec le flux de référence local : connectez-vous, inspectez l'accès, soumettez une tâche et lisez son résultat. Les adaptateurs fake et locaux permettent à des tests déterministes d'exercer le chemin sans requêtes payantes aux fournisseurs — le quickstart de cinq minutes l'exécute de bout en bout. Configurez ensuite les intégrations de production dont votre produit a réellement besoin.

L'acceptation locale et l'acceptation en production répondent à des questions différentes. Un test local qui passe établit le comportement de l'application dans des conditions contrôlées. La persistance réelle de l'authentification, la livraison fournisseur, le déploiement et le comportement appareil demandent encore leur propre vérification. Gardez cette distinction visible à mesure que le produit grandit.

Une fondation mérite son nom lentement : dans le deuxième produit qui sort plus vite que le premier, et dans le jour de maintenance qui corrige un module au lieu de cinq codebases. C'est le pari derrière supastack — et c'est la barre à laquelle chaque module est tenu.

Les questions derrière l'approche

Quelques questions sous-tendent cette approche, et elles méritent des réponses directes.

• supastack est-il un template ou un framework ? — Une fondation de modules avec des contrats entre eux. Le code produit vit hors de Starter Core et se connecte par la configuration, donc la plateforme peut être mise à jour sans forker vos fonctionnalités.
• Une infrastructure partagée ne rend-elle pas les produits génériques ? — Seule la plomberie est partagée. Enregistrements, flux et langage restent dans le codebase du produit — les parties que les clients voient vraiment demeurent les vôtres.
• Où commence le code propre au produit ? — Avec les enregistrements et les flux que lui seul possède. La fondation authentifie l'utilisateur et borne les données ; elle ne sait pas ce qu'est un prospect.
• Pourquoi un monorepo ? — Pour que les applications web, mobile et bureau changent en même temps que les packages en dessous : un seul système de types, une seule barrière de tests, aucune dérive entre dépôts.
• Et si je n'ai besoin que de l'app web ? — La fondation est l'achat ; mobile et bureau sont des surfaces à adopter ou à ignorer. Rien ne vous oblige à livrer une app dont vous n'avez pas besoin.