> ## Documentation Index > Fetch the complete documentation index at: https://supastack.dev/llms.txt > Use this file to discover all available pages before exploring further. > For the full documentation corpus in one file, fetch: https://supastack.dev/llms-full.txt # Votre stack list ne livrera pas votre produit Une centaine de développeurs ont mis ma stack list en signet — ce que la liste laisse de côté, c'est la plomberie qui a permis à un outil de bureau Windows d'être livré en 48 heures. _Publié 2026-10-12._ _Mis à jour le 2026-10-27._ > **Une stack list plus longue vous aide-t-elle à livrer plus vite ?** > Cela dépend de ce que la liste laisse de côté. Une stack list nomme des outils ; elle n'installe pas leurs frontières — webhooks vérifiés, périmètre par tenant, signature des releases — et ces raccords sont précisément là où les projets s'enlisent. Une liste copiée reproduit les outils sans rien de leur intégration. Les listes font un bon menu de pistes à explorer, mais le chemin vers un produit livrable, c'est une plomberie testée, peu importe comment vous l'obtenez. La question honnête, c'est ce que valent vos soirées. ## Le piège des signets Il y a quelques jours, j'ai répondu à un thread sur X avec la stack que j'utilise vraiment — ma « stack de dev indé 2026 », une douzaine d'outils en une seule réponse. [La réponse](https://x.com/noah_z_zhang/status/2114919719538978934) a récolté plus d'une centaine de signets et envoyé plus d'une centaine de clics vers ce site. Les statistiques étaient moins flatteuses : la plupart des visiteurs ont parcouru une page puis sont partis. Une stack list se lit comme un plan abouti ; une liste copiée ne livre rien. Chaque outil doit encore être installé, câblé à ses voisins et testé — c'est dans les raccords entre eux que partent les semaines. Voici l'article que ces signets cherchaient : non pas quels outils j'utilise, mais quelle plomberie portait déjà la charge — et ce que cela m'a permis de livrer en quarante-huit heures. ## Là où les projets meurent vraiment La plupart des projets indé ne meurent pas sur leur fonctionnalité cœur. Ils meurent dès la première semaine, sur de l'infrastructure qui n'a rien à voir avec l'idée. La motivation a une demi-vie d'environ quarante-huit heures — chaque heure passée loin du produit brûle la ressource la plus rare d'un build en solo. La forme de la semaine est remarquablement constante : - Premier jour : structure du monorepo, ESLint, chemins `tsconfig`, migrations de base de données. - Troisième jour : toujours dans la documentation du prestataire de paiement, à régler l'idempotence des webhooks. - Cinquième jour : un compagnon bureau ou mobile — un nouveau pipeline de build, une nouvelle surface d'auth, des mises à jour automatiques à partir de zéro. ## Un build de 48 heures, de bout en bout La semaine dernière, j'ai livré [SpinShare](https://spinshare.dev), un utilitaire de bureau natif Windows : glissez un fichier dans l'Explorateur, appuyez sur Maj, et un menu radial s'ouvre sous le curseur ; relâchez pour lancer une conversion ou une opération locale. Aucune popup, rien n'est téléversé ; le fichier ne quitte jamais la machine. C'est le calendrier qui mérite l'examen : nouveau dépôt, logique cœur en Rust, un flux de licence hors ligne sur mes rails de facturation existants, et une soumission au Microsoft Store — quarante-huit heures de développement cœur, en pair programming avec un agent et presque sans réglage des prompts. L'agent n'a pas déraillé pour une raison peu spectaculaire : les frontières d'architecture où il hallucine étaient déjà scellées dans supastack, mon propre kit. Voici le décompte : la plomberie qu'il n'a pas fallu construire pendant ces deux jours. ## Installation et garde-fous `pnpm setup` réduit l'amorçage à une seule commande : vérifications préalables, alignement des variables d'environnement, installation des dépendances, migrations de base de données. Il n'y a pas de première soirée passée à assembler un environnement fonctionnel — le dépôt passe sa propre checklist ou nomme ce qui manque. Les docs miroir `.ai/`, `AGENTS.md` et `.agents/skills/` forment un contrat écrit pour l'agent plutôt que pour l'humain — le périmètre de responsabilité de chaque package, ses règles de test, ses lignes rouges (l'application de bureau est un shell à webview unique qui ne duplique jamais l'UI produit). Le [guide de la structure du projet](https://supastack.dev/fr/docs/web/project-structure.md) montre l'arborescence que lit l'agent ; l'[article sur le workflow avec agent](https://supastack.dev/fr/blog/building-saas-with-a-coding-agent.md) couvre le rythme de travail. Les frontières mises par écrit sont des frontières qu'un agent ne peut pas traverser à la dérive. ## Facturation et releases livrées prêtes à l'emploi Huit adaptateurs de facturation se tiennent derrière un seul contrat — Stripe, Creem, Polar, Dodo, Lemon Squeezy, Paddle, Whop et PayPal — et un registre `webhook_event` rend chaque règlement vérifié en signature et idempotent avant qu'il ne devienne une licence ou un e-mail. Mon travail commençait en aval : des paliers Early-Bird qui basculent selon le nombre de commandes, et des clés de licence hors ligne signées Ed25519 — un outil de bureau doit s'activer sans appel réseau. Le [guide du module de facturation](https://supastack.dev/fr/docs/modules/billing.md) documente le flux que j'ai étendu. Le côté release était tout aussi dépourvu d'intérêt, et c'est bien le but. Le pipeline Tauri 2 — `desktop-release.yml` — construit des bundles signés et génère `latest.json` via minisign pour les canaux stable et bêta sous Windows (NSIS et msi), macOS (dmg) et Linux (AppImage). Le seul packaging que j'ai fait moi-même était un build MSIX pour le Microsoft Store ; le [quickstart bureau](https://supastack.dev/fr/docs/desktop/ship-in-5-minutes.md) couvre le reste. ## Les dix pour cent que les utilisateurs ressentent vraiment Voici l'arithmétique qu'une stack list dissimule. Environ quatre-vingt-dix pour cent de ce dont un produit a besoin est de la plomberie que l'utilisateur ne voit jamais. La plomberie invisible est le travail qu'une fondation devrait porter — c'est la partie qui peut être portée. Le reste, c'est le produit. Comme la mienne portait déjà la charge, presque toutes mes quarante-huit heures sont allées aux dix pour cent que les utilisateurs peuvent ressentir — un travail qui ne tient jamais dans un commentaire de stack, et qui n'arrive jamais quand la semaine part dans les webhooks et la signature : - Des hooks de glisser-déposer OLE Windows en Rust, pour que le menu ne s'arme que tant qu'un vrai glissé de fichier est maintenu avec Maj — jamais pendant la frappe. - Un flux multi-fenêtres dans la zone de notification, pour que l'outil reste à une frappe de distance sans fenêtre dans la barre des tâches. - L'animation du menu radial, réglée jusqu'à ce que le menu se lise comme instantané plutôt qu'animé. - Plus de trente convertisseurs de formats locaux, chacun avec ses propres tests unitaires. ## La partie pratique : tarifs et transparence L'objection honnête : « J'ai Cursor — pourquoi payer pour une stack list ? » Elle tient jusqu'à ce que votre propre temps ait un prix. Deux soirées d'idempotence de webhooks vous coûtent une fonctionnalité que vous n'avez pas livrée. Sur la transparence : la [documentation](https://supastack.dev/fr/docs/web/ship-in-5-minutes.md) est publique dans son intégralité — arborescence des dossiers, double moteur web, synchronisation interplateforme, les huit adaptateurs de facturation, le routage IA. Je préfère qu'un sceptique la lise de bout en bout et reparte plutôt qu'il n'achète sur un titre ; [starter kit ou from scratch](https://supastack.dev/fr/blog/starter-kit-or-from-scratch.md) est la version honnête de la décision. Deux notes pratiques : les prix affichés incluent déjà une économie de lancement de 100 $, et le paiement prend en charge Alipay. Et un cashback de 50 % pour les builders — livrez un vrai produit sous soixante jours, partagez publiquement le récit du build (5 000 vues organiques ou 50 likes organiques sur X, Reddit, YouTube ou équivalent), puis envoyez-moi le lien par e-mail : la moitié vous revient, et la licence reste vôtre. Les règles sont aux [conditions du launch-cashback](https://supastack.dev/terms#launch-cashback). ## Questions fréquentes sur les stack lists Les mêmes objections refont surface chaque fois que le kit apparaît. Elles méritent des réponses directes. - Un agent ne peut-il pas générer tout cela pour moi ? — Il peut produire quelque chose de plausible ; il ne peut pas vérifier les raccords en une seule passe. Un webhook idempotent se teste, il ne se génère pas — le scaffolding vous remet la même liste entre les mains. - Un boilerplate ne rend-il pas les produits génériques ? — La plomberie est partagée ; le produit ne l'est pas. Les hooks de glisser-déposer, le comportement dans la zone de notification et les convertisseurs de SpinShare n'existent nulle part dans le kit — les dix pour cent que voient les clients restent à vous. - Et si je n'ai besoin que d'une app web ? — Le kit est l'achat dans tous les cas ; le mobile et le bureau sont des surfaces à adopter ou à ignorer, pas des exigences. SpinShare existe parce que la surface bureau était déjà construite. - Un utilitaire de bureau est-il vraiment l'histoire de l'acheteur ? — C'est l'exemple honnête le plus court dont je dispose : deux jours entre un dépôt vide et une soumission en store. La même plomberie sert un SaaS — la [checklist de lancement](https://supastack.dev/fr/blog/saas-launch-checklist.md) est la version longue. - Pourquoi ne pas simplement publier la stack list ? — C'est fait : le [guide de la stack technique](https://supastack.dev/fr/docs/web/tech-stack.md) nomme chaque choix et sa raison. Une liste est un menu, pas un plan — l'argument ici, c'est d'acheter le plan déjà construit.