Pourquoi j'ai créé 6 apps SaaS en solo

En mars 2024, je lançais ma première app. 18 mois plus tard, j'en ai 6 en production. Une seule stack, un seul monorepo, zéro équipe. Cet article raconte pourquoi je l'ai fait, comment, et ce que je referais différemment.

Le contexte : développeur aéronautique à Pau

Je suis ingénieur en usinage CNC chez un sous-traitant aéronautique. Mon quotidien : des pièces en Inconel 718, des tolérances de quelques microns, et un ERP industriel qui a 15 ans d'âge. Le genre d'environnement où on apprend très vite à coder ses propres petits outils pour survivre.

Le soir, j'avais envie de construire autre chose. Pas un side project dormant sur GitHub, mais des vrais produits avec des vrais utilisateurs. Et j'avais des idées : un outil pour gérer le magasin d'outils de mon atelier, un cockpit pour le groupe de musique que je joue le week-end, un tableau de bord budgétaire pour ma boîte auto-entrepreneur.

La règle : un monorepo, zéro équipe

La décision clé a été celle-ci : pas de nouveau repo pour chaque idée. Tout vit dans `pilotone/` : un monorepo pnpm + Turborepo, avec un dossier `apps/` et un dossier `packages/` partagé.

```
pilotone/
├── apps/
│ ├── toolpilot/ # ERP magasin + licences CNC
│ ├── bandpilot/ # Cockpit groupes de musique
│ ├── budgetpilot/ # Budget auto-entrepreneur
│ ├── pathpilot/ # Coach carrière IA
│ ├── oustapilot/ # Assistant construction maison
│ └── pilotone-web/ # Site vitrine + HQ privé
└── packages/
├── ui/ # Composants shadcn partagés
└── config/ # ESLint, TSConfig, Tailwind
```

Pourquoi ? Parce qu'en solo, la fragmentation tue. 6 repos = 6 CI, 6 dépendances, 6 migrations de stack. 1 repo = 1 `pnpm install`, 1 commande pour builder tout, 1 Claude Code qui voit l'intégralité du code.

La stack : prévisible à l'ennui

Je n'ai pas choisi les technos les plus hype. J'ai choisi celles qui me permettent de livrer vite et de dormir la nuit :

• Next.js 16 + React Server Components pour les sites vitrines et dashboards admin


• Vite + React 18 pour les SPA à forte interactivité (BandPilot, BudgetPilot, ToolPilot)


• Prisma + PostgreSQL pour les apps avec schéma riche (BandPilot)


• Supabase pour les apps qui ont besoin d'auth + realtime (BudgetPilot, PathPilot, PilotOne)


• Tailwind + shadcn/ui partout, sans négociation


• Render pour l'hébergement (Frankfurt, proche de mes utilisateurs français)

Le choix de Supabase + Prisma en parallèle n'est pas un accident : chaque outil pour son terrain. Supabase quand je veux du realtime et de l'auth gratuite, Prisma quand je veux un schéma à 50+ tables avec des migrations propres.

Le vrai secret : Claude Code

Je ne pourrais pas faire ça sans Claude Code. Pas "Claude Code m'aide à coder" — Claude Code porte 70 % du code. Je rédige des prompts détaillés avec critères de validation, je lance, je relis, je valide.

Les règles que j'ai mises en place :

1. Chaque prompt est un contrat : décrit un livrable complet, pas une suggestion. 8 features listées = 8 features livrées.
2. Le frontend est le livrable : un endpoint backend sans UI = pas livré.
3. Test comme un utilisateur : ouvrir la page, interagir, recharger, revenir. Pas juste `tsc + npm test`.
4. Zéro report : si c'est trop gros, simplifier et livrer — pas supprimer.

Ces règles vivent dans `.claude/rules/REGLES-CLAUDE-CODE.md` à la racine du monorepo. Claude les lit au début de chaque session.

Comment je découpe ma semaine

Mon job salarié m'occupe 40h/semaine. Il me reste environ 15-20h pour PilotOne. Je les répartis ainsi :

• Lundi soir : planification de la semaine, mise à jour de la file de prompts Supabase


• Mardi/Mercredi/Jeudi soir : exécution des prompts, code review, déploiement


• Vendredi soir : marketing, réponse aux utilisateurs, facturation


• Samedi matin : écriture de blog articles, réflexion stratégique


• Dimanche : off, ou petit refactoring plaisir

Le secret : ne jamais coder sans prompt clair. Ouvrir l'éditeur sans savoir ce qu'on veut faire, c'est la recette pour perdre 3h à scroller du Twitter.

Ce que je referais différemment

• Plus de marketing, plus tôt. J'ai sous-estimé la quantité de contenu nécessaire pour exister dans un marché saturé. BudgetPilote avait 0 utilisateur au bout de 2 mois parce que personne ne savait qu'il existait.


• Moins de perfectionnisme sur le design. Le premier design de BandPilot était magnifique. Ça m'a pris 3 semaines. Personne n'a remarqué.


• Pricing plus tôt. J'ai lancé gratuit partout au début. Résultat : des milliers d'utilisateurs free, zéro euro. Maintenant je mets un pricing Pro dès le jour 1.

Et maintenant ?

Je vise les 1000 € MRR cumulés sur les 6 apps d'ici fin 2026. Ce n'est pas la Silicon Valley, mais c'est plus que la plupart des side projects. Et surtout, c'est sans investisseur, sans équipe, sans burn-out.

Si tu veux construire ton propre portfolio de micro-SaaS, commence par choisir ta stack. Puis tiens-toi-y quoi qu'il arrive. La cohérence battra toujours l'excellence théorique.

Voir mon monorepo sur GitHub →