Ma stack technique de solo founder en 2026 — Ce que j'utilise pour faire tourner fromscratch.dev et pourquoi

Chaque solo founder fait finalement face à la même question : sur quoi dois-je construire ? La réponse compte plus que la plupart des gens ne le pensent — pas à cause des benchmarks de performance, mais parce que la mauvaise stack vous ralentira, videra votre budget ou vous forcera à apprendre les opérations au lieu de livrer des fonctionnalités.

Ce n'est pas un listicle "top 10 outils". C'est la stack exacte que j'utilise tous les jours, avec des avis honnêtes sur ce qui fonctionne, ce qui est agaçant et ce que je changerais si je recommençais.

Si vous êtes encore en train de décider quoi lancer avant d'optimiser votre stack, commencez par la checklist de lancement SaaS.

La stack complète en un coup d'œil

Coût mensuel total : 35-55 $ selon l'usage. Laissez-moi vous expliquer chaque choix.

Frontend : Next.js 15 + React 19 + Tailwind CSS 4

C'est le choix ennuyeux-mais-correct pour les solo founders en 2026.

Next.js me donne des server components, des API routes, de la génération statique et de l'ISR dans un seul framework. Je n'ai pas besoin d'un backend séparé. Je n'ai pas besoin de configurer un pipeline de build. Je déploie un projet et tout fonctionne.

Pourquoi pas Remix ou SvelteKit ? Les deux sont de bons frameworks. J'ai choisi Next.js parce que l'écosystème est le plus grand — ce qui signifie un meilleur support des outils de coding IA (Cursor et Claude Code comprennent les patterns Next.js en profondeur), plus de réponses communautaires pour déboguer et une embauche contractuelle plus facile si j'en ai besoin.

Tailwind CSS 4 est l'autre incontournable. La v4 a supprimé l'exigence du fichier de config et a ajouté l'imbrication CSS native. L'amélioration DX par rapport à la v3 est significative. Je l'associe à tailwind-merge et clsx pour les classes conditionnelles.

La vraie raison pour laquelle je ne changerais jamais : chaque outil de coding IA en 2026 écrit d'excellent code Next.js + Tailwind. Quand votre assistant IA peut créer une page complète en 30 secondes, la popularité du framework devient un multiplicateur de productivité.

Base de données : Neon Postgres

C'était la décision la plus risquée dans la stack. Les bases de données sont difficiles à migrer.

Neon me donne du Postgres serverless avec autoscaling, branching (comme des branches git pour votre base de données) et un free tier généreux. La connexion utilise leur driver serverless (@neondatabase/serverless), ce qui signifie que je ne paye rien quand personne n'utilise le site et que ça scale automatiquement lors des pics de trafic.

Pourquoi pas Supabase ? Supabase bundle auth, stockage, temps réel et une base de données dans une seule plateforme. C'est excellent pour le prototypage mais crée un couplage serré. Je voulais choisir le meilleur outil pour chaque travail séparément. Neon est une meilleure base de données pure que l'offre Postgres de Supabase — la fonctionnalité de branching seule me fait gagner des heures lors des tests de migrations de schéma.

Pourquoi pas PlanetScale ? Ils ont supprimé leur free tier et ont pivoté loin des développeurs individuels. C'était suffisant pour les éliminer.

Pourquoi Drizzle ORM plutôt que Prisma ? Drizzle génère du SQL que je peux lire et comprendre. Le moteur de requêtes de Prisma ajoute une couche runtime qui abstrait trop. Quand quelque chose casse à 2h du matin, je veux voir le vrai SQL, pas déboguer un moteur de requêtes. Drizzle a aussi un meilleur support des runtimes edge, ce qui compte pour les déploiements serverless.

Auth : Better Auth

L'authentification est la partie la plus agaçante de tout SaaS à implémenter. C'est aussi la partie où les erreurs ont les pires conséquences.

J'utilise Better Auth — une bibliothèque d'auth TypeScript self-hosted qui gère les sessions, les fournisseurs OAuth et la gestion des comptes. Mon setup supporte la connexion GitHub et Twitter, avec les sessions stockées dans ma base de données Neon via l'adapter Drizzle.

Pourquoi l'auth self-hosted plutôt que Clerk ou Auth0 ? Coût et contrôle. Better Auth est gratuit pour toujours parce qu'il tourne dans ma propre infrastructure. Clerk facture par utilisateur actif mensuel, ce qui signifie que les coûts d'auth évoluent linéairement avec la croissance. Pour un solo founder pré-revenus, c'est une courbe de coûts effrayante.

Le vrai compromis : les composants UI prêts à l'emploi de Clerk sont genuinement excellents. Better Auth signifie que j'ai construit mes propres pages de connexion et mon interface de gestion des sessions. Ça m'a pris quelques jours de travail supplémentaire. Si j'optimisais purement pour la vitesse de lancement, je commencerais avec Clerk et migrerais plus tard si les coûts devenaient un problème.

Hébergement : Netlify

Je déploie sur Netlify avec l'adapter @netlify/plugin-nextjs. Chaque push git déclenche un build et déploiement automatique.

Pourquoi Netlify plutôt que Vercel ? Honnêtement, c'était serré. Les deux ont d'excellents free tiers et un bon support Next.js. J'ai opté pour Netlify parce que leur modèle de pricing est plus prévisible — le pricing de bande passante et de fonctions serverless de Vercel peut augmenter de façon inattendue lors de trafic viral. Le modèle de Netlify est plus simple à raisonner.

L'avantage Vercel qui me manque : l'optimisation d'images de Vercel et l'implémentation ISR sont légèrement plus polies, ce qui fait sens puisqu'ils construisent Next.js. Si le pricing de Vercel devient plus prévisible, je pourrais changer.

Et Railway ? Railway est excellent pour les services backend et les conteneurs Docker, mais c'est disproportionné pour une app Next.js que Netlify gère nativement. J'utiliserais Railway si j'avais un serveur API séparé ou un runner de jobs en arrière-plan.

Analytics : Fathom + Google Analytics 4

Je fais tourner un setup analytics double, ce qui semble excessif mais sert deux objectifs différents.

Fathom Analytics (~14 $/mois) est mon dashboard principal. C'est privacy-first, ne nécessite pas de bandeaux cookie et me donne les chiffres que je vérifie vraiment tous les jours : pages vues, meilleures pages, référents. L'interface est rapide et simple.

Google Analytics 4 tourne en parallèle pour une raison : l'intégration Search Console et les données SEO. Fathom ne me dit pas quelles requêtes de recherche amènent du trafic ou comment mes pages se classent. GA4 le fait. Pour un site riche en contenu comme fromscratch, ces données sont essentielles.

Je suis aussi les événements personnalisés (clics, interactions de contenu, recherches) dans ma propre base de données. Ça me donne la pleine propriété des données comportementales sans dépendre d'un fournisseur d'analytics tiers.

Coding IA : Cursor + Claude Code

C'est la partie de ma stack qui a le plus changé au cours de l'année passée. Les outils de coding IA sont passés de "bonne autocomplétion" à "vrai multiplicateur de productivité."

Cursor (~20 $/mois) est mon éditeur principal. Je l'utilise pour :

• Les refactorisations multi-fichiers où j'ai besoin de voir les changements visuellement
• Le développement de composants où j'itère sur l'UI
• Les modifications rapides où la complétion Tab économise des frappes

Claude Code (~20 $/mois) est mon compagnon CLI. Je l'utilise pour :

• Les tâches complexes multi-étapes ("ajouter le support i18n à toutes les pages de glossaire")
• Le débogage où j'ai besoin que l'IA lise de nombreux fichiers et raisonne sur le système
• Les changements autonomes qui couvrent 10+ fichiers

Le workflow combiné : Je planifie dans Claude Code, j'exécute dans Cursor pour les petits changements et je confie les migrations complexes à Claude Code. Ils se complètent bien parce que Cursor est visuel et rapide tandis que Claude Code est minutieux et autonome.

Système de contenu : MDX + gray-matter + Zod

fromscratch est un site riche en contenu avec 100+ pages de comparaisons, reviews, termes de glossaire et articles de blog. Tout le contenu vit sous forme de fichiers MDX dans le dépôt, validés par des schémas Zod au moment du build.

Pourquoi MDX dans le dépôt plutôt qu'un CMS ? Trois raisons :

1. Contrôle de version — chaque changement de contenu est un commit git avec un historique complet
2. Sécurité de type — les schémas Zod détectent le frontmatter cassé avant qu'il n'atteigne la production
3. Vitesse — pas d'appels API pour récupérer le contenu, tout est local au moment du build

J'utilise gray-matter pour parser le frontmatter et next-mdx-remote pour rendre le MDX avec des composants React personnalisés. Le système de contenu supporte le double locale (anglais et français), le calcul automatique du temps de lecture et l'extraction de données structurées.

Le compromis : les collaborateurs non techniques ne peuvent pas éditer le contenu sans connaître git. Pour un solo founder, ça va. Si j'embauche un rédacteur de contenu plus tard, j'ajouterais une couche CMS simple (probablement Keystatic ou Tina) qui commite dans le même dépôt git.

Ce que je dépense par mois

Voici le vrai détail. Pas de liens affiliés, pas de chiffres sponsorisés.

Les items à 0 $ ne sont pas des appâts — le free tier de Neon vous offre 0,5 Go de stockage et du compute en autosuspend, ce qui gère des milliers d'utilisateurs. Le free tier de Netlify inclut 100 Go de bande passante et 300 minutes de build. Les deux sont genuinement suffisants pour un SaaS en phase initiale.

Ce que je changerais si je recommençais

Je commencerais avec Clerk plutôt que Better Auth. Le temps que j'ai passé à construire l'interface d'auth était réel. Les composants prêts à l'emploi de Clerk m'auraient fait économiser 2-3 jours, et je pourrais migrer vers l'auth self-hosted plus tard quand l'optimisation des coûts devient importante.

Je sauterais le système double-locale initialement. Construire des traductions françaises avant d'avoir de la traction SEO en anglais était prématuré. Leçon apprise : maîtrisez une langue en premier, puis élargissez.

J'ajouterais Fathom dès le premier jour. J'ai gâché le premier mois sans analytics, ce qui signifie que je n'ai pas de données de référence pour mon trafic le plus ancien. 14 $/mois en vaut la peine dès le jour du lancement.

Je ne changerais pas la stack de base. Next.js + Neon + Drizzle + Netlify est la bonne fondation. C'est ennuyeux, ça fonctionne et ça s'écarte de mon chemin pour que je puisse me concentrer sur le contenu et les fonctionnalités plutôt que sur l'infrastructure.

conclusion

La meilleure stack de solo founder en 2026 n'est pas la plus impressionnante techniquement — c'est celle qui vous permet de livrer tous les jours sans penser à l'infrastructure. Next.js + Postgres serverless + hébergement managé vous y amène pour moins de 50 €/mois. Choisissez des outils avec des free tiers généreux, un fort support TypeScript et de grandes communautés. Gardez l'astronomie architecturale pour quand vous aurez les revenus pour justifier la complexité.

Où chaque outil s'intègre dans l'ensemble

Si vous évaluez des outils pour votre propre stack, j'ai rédigé des comparaisons détaillées et des guides de catégorie pour la plupart des outils mentionnés ici :

• Bases de données : Neon vs Supabase · Supabase vs Firebase · Les meilleurs outils de base de données
• Hébergement : Vercel vs Netlify · Railway vs Vercel · Les meilleures plateformes de déploiement
• Auth : Clerk vs Auth0 · Les meilleurs fournisseurs d'authentification
• Paiements : Stripe vs Lemon Squeezy · Stripe vs Paddle · Les meilleurs processeurs de paiement
• Coding IA : Cursor vs Claude Code · Cursor vs GitHub Copilot · Les meilleurs outils de coding IA
• Analytics : Les meilleurs outils d'analytics

De combien de clients avez-vous besoin ?

Entrez votre niveau de prix et votre objectif de revenus pour voir exactement combien de clients payants votre SaaS a besoin.

Essayer le calculateur