Lancer un SaaS en solo en 2026 : ma stack et ma méthode

J'ai lancé plusieurs produits seul. Des SaaS web, des apps iOS, des outils open-source. Certains marchent, d'autres non. Mais à chaque fois j'apprends la même leçon : ce qui te tue en solo, c'est pas le manque d'idées, c'est le temps perdu sur des trucs qui ne rapportent rien.

Aujourd'hui je suis CTO de CBlindspot, un SaaS LegalTech. Et en parallèle je continue à shipper mes propres projets. Donc la question "comment lancer un SaaS quand t'es tout seul" je me la pose pour de vrai, toutes les semaines, avec mon propre temps en jeu.

Voici ma stack et ma méthode en 2026. Pas de théorie. Ce que j'utilise vraiment.

Ma stack SaaS solo : le choix par défaut

Quand je démarre un nouveau produit, je ne réfléchis presque plus à la stack SaaS solo. J'ai un défaut, et je m'y tiens sauf raison sérieuse de dévier. Réfléchir à la stack à chaque projet, c'est déjà de la procrastination déguisée.

Mon défaut :

• Next.js + TypeScript : un seul framework pour le front et le back. App Router, Server Actions, API routes quand j'en ai besoin. TypeScript partout, non négociable. Le typage te sauve la vie quand t'es seul à relire ton code à 23h.
• Tailwind + shadcn/ui : je ne dessine plus de boutons à la main. shadcn me donne des composants propres que je possède dans mon repo, que je modifie comme je veux. Tu copies, tu adaptes, tu avances. Le design system est réglé en une journée.
• Prisma : mon ORM. Le schéma est lisible, les migrations sont propres, l'autocomplétion est parfaite avec TypeScript. Je ne touche presque jamais au SQL brut au début.
• Postgres ou MongoDB : Postgres par défaut pour tout ce qui est relationnel (la majorité des SaaS). MongoDB quand le modèle de données est vraiment souple ou que je prototype vite. Je ne mélange pas les deux pour le plaisir.
• Vercel pour le déploiement web. Tu push, c'est en ligne. Preview deploy sur chaque PR. Zéro config serveur. Pour un solo, c'est imbattable au démarrage.
• Hetzner quand j'ai besoin d'un VPS pour les jobs longs, le scraping, ou tout ce qui dépasse les timeouts serverless. Mon VPS Hetzner me coûte moins de 4€ par mois et il tourne 24/7. Vercel pour le web, Hetzner pour le sale boulot.

Cette stack, je la connais par cœur. C'est ça l'intérêt. Je ne perds pas une heure à lire la doc d'un nouvel outil. Je code la feature qui rapporte.

Auth et paiements : ne réinvente rien

Deux trucs où les solo founders perdent un temps fou : l'auth et les paiements. C'est tentant de tout coder soi-même. Ne le fais pas.

Pour l'auth, je prends une solution gérée. NextAuth/Auth.js quand je veux rester dans mon repo et garder le contrôle, ou Clerk quand je veux que ce soit réglé en vingt minutes avec le magic link, le SSO et la gestion de session déjà faits. Coder ta propre gestion de mots de passe, de reset, de sessions, c'est une surface de bugs et de failles de sécu énorme pour zéro valeur ajoutée. Personne n'a jamais acheté ton produit parce que t'as codé ton propre hashing.

Pour les paiements, c'est Stripe sur le web, RevenueCat sur mobile. Sur mes apps iOS (QuranWay, WallCraft AI), RevenueCat gère les abonnements, les essais, la restauration d'achat et le sync cross-device. J'ai migré QuranWay vers RevenueCat et ça m'a enlevé une montagne de code maison fragile. Sur le web, Stripe Checkout + webhooks, point final. Tu branches le webhook qui flippe le flag premium en base, et c'est tout.

La règle : tout ce qui est résolu par le marché, tu l'achètes. Tu codes ce qui te différencie, rien d'autre.

Trigger.dev pour les jobs en arrière-plan

Le moment où les débutants galèrent, c'est quand il faut faire tourner du code en dehors de la requête HTTP. Envoyer des emails, générer un rapport, scraper, appeler un LLM qui prend 40 secondes. Les fonctions serverless de Vercel timeout à 60 secondes. Tu te retrouves coincé.

Ma réponse : Trigger.dev. C'est un orchestrateur de jobs en TypeScript. Tu écris ta tâche comme une fonction, tu la déclenches depuis ton app, et elle tourne en background avec retry automatique, logs, et durée longue sans souci. Pour tout ce qui est IA (RAG, génération, batch), c'est parfait : tu ne bloques jamais l'utilisateur.

Quand le job est vraiment lourd ou doit tourner en cron permanent, je le bascule sur le VPS Hetzner avec un cron natif. Mais pour 90% des cas, Trigger.dev fait le taf sans que j'aie à gérer d'infra.

La méthode : ship fast, mesure, itère

La stack c'est 30% du game. Le reste c'est la discipline. Ma devise c'est "ship fast, wire AI in, don't over-engineer". Voilà comment ça se traduit au quotidien.

Commence honteusement simple. Ton premier déploiement doit être moche et incomplet. Une landing, un signup, une feature qui marche. Si t'as pas honte de ta v1, t'as lancé trop tard. J'ai des produits qui ont mis trois semaines à voir leur premier user, et j'aurais dû le voir en trois jours.

Ne sur-architecture pas. Pas de microservices. Pas de event-driven sur un produit qui a zéro utilisateur. Pas d'abstraction "au cas où". Un monolithe Next.js bien rangé t'emmène jusqu'à des milliers d'utilisateurs sans transpirer. L'architecture qui scale, tu la construiras quand t'auras le problème de scaler. Aujourd'hui ton problème c'est d'avoir un client.

Mesure avant de coder la feature suivante. Mets de l'analytics dès le jour 1. Sur QuranWay j'ai un hub d'analytics maison qui me dit exactement où les gens décrochent. Résultat : j'ai découvert que mon paywall convertissait à 0,58%. Ce chiffre m'a fait repenser tout le modèle, passer d'un hard paywall à du freemium. Sans la donnée, j'aurais codé dix features inutiles en pensant que le problème était ailleurs.

Itère sur ce qui bouge l'aiguille. Une fois que tu mesures, tu sais. Tu arrêtes de coder à l'instinct. Chaque semaine, une question : qu'est-ce qui rapproche d'un revenu ? Tu fais ça. Le reste attend.

Les erreurs à éviter en solo

J'ai fait à peu près toutes ces erreurs au moins une fois. Apprends des miennes.

• Construire trois mois avant de montrer. Tu vas tomber amoureux de ta vision et passer à côté de ce que veulent les gens. Montre tôt, prends les coups tôt.
• Choisir des outils que tu ne connais pas pour ce projet précis. Garde ta stack par défaut. Un nouveau projet n'est pas une excuse pour apprendre un nouveau framework. Tu apprends sur des side-projects jetables, pas sur ce qui doit rapporter.
• Coder l'auth et le billing maison. Déjà dit. C'est le piège n°1.
• Optimiser des perfs que personne ne subit. Tu n'as pas de problème de performance avec 12 utilisateurs. Tu as un problème d'acquisition.
• Négliger le marketing. En solo, "build it and they will come" est faux. WallCraft AI est live sur l'App Store, et le vrai travail commence là, pas avant. Réserve du temps chaque semaine pour la distribution, sinon ton produit meurt dans le silence.
• Faire du parfait au lieu du fini. Le perfectionnisme en solo, c'est juste de la peur déguisée. Un produit fini en ligne bat un produit parfait dans ta tête, à tous les coups.

En résumé

Lancer un SaaS en solo en 2026, ce n'est pas un problème technique. La stack est résolue : Next.js + TypeScript + Tailwind + shadcn + Prisma sur Postgres ou Mongo, déployé sur Vercel, avec Hetzner et Trigger.dev pour le lourd, et de l'auth + du billing gérés que tu n'écris jamais toi-même.

Le vrai jeu c'est la discipline. Commencer simple. Ne pas sur-architecturer. Mesurer. Itérer sur ce qui rapporte. Distribuer autant que tu codes.

Ta stack ne te fera pas gagner. Ta vitesse à apprendre de tes vrais utilisateurs, si. Choisis des outils ennuyeux que tu maîtrises, et mets toute ton énergie dans le seul truc qui compte : sortir le produit, le montrer, et l'améliorer avec de la donnée. Ship fast. Le reste suit.