Combien de temps pour lancer un micro SaaS quand on est seul ?

Compte trois à six semaines de travail effectif, étalées sur six à dix semaines calendaires si tu codes en dehors d'un emploi à temps plein. C'est le chiffre qui revient chez les solos qui sortent vraiment un micro SaaS, à condition de couper le périmètre aussi fort qu'un solo doit le faire.

La contrainte n'est pas le code, c'est le temps disponible

Une équipe qui lance un produit compte en semaines de travail. Un solo compte en heures volées : deux heures le soir, une matinée le week-end. Sur une base de dix à quinze heures utiles par semaine (le rythme réel d'un solo qui garde un emploi ou des clients à côté), trois à six semaines de travail effectif s'étalent sur six à dix semaines de calendrier. Le calcul qui compte n'est donc pas « combien de jours » mais « combien d'heures disponibles par semaine », et c'est cette variable, pas la complexité technique, qui fixe la date de sortie.

Ce qu'un solo doit acheter, jamais construire

La différence entre un solo qui sort en un mois et un solo qui traîne six mois se joue sur une décision simple : ne rien construire qui existe déjà. Authentification, paiement, hébergement, emails transactionnels se branchent en quelques heures avec des briques toutes faites (Supabase ou équivalent, Stripe, Vercel). Chaque brique reconstruite à la main, « pour mieux contrôler », coûte une à deux semaines qui n'apportent rien au client final : il ne voit jamais si l'auth est maison ou pas, il voit seulement si le produit résout son problème.

Le découpage qui fait gagner deux semaines

Un solo qui vise plusieurs personas ou plusieurs cas d'usage dès la V1 double mécaniquement sa durée de lancement, parce que chaque persona ajoute ses propres écrans, ses propres textes, ses propres bugs. La version qui sort en trois semaines résout un seul problème, pour un seul type d'utilisateur, avec un seul chemin pour payer. C'est la même logique que le MVP poussée plus loin : quand on est seul, le découpage n'est pas une option de confort, c'est ce qui rend la date de sortie tenable.

Ce qui double la durée sans qu'on s'en rende compte

Trois pièges reviennent chez les solos qui annoncent un mois et sortent au bout de trois :

• Le design avant l'usage : polir l'interface d'un écran que personne n'a encore testé, au lieu de le mettre devant un vrai utilisateur en version brute.
• La feature de confort : ajouter un réglage, un mode sombre, un export PDF parce que « ça se fait facilement », alors que rien ne prouve encore que quelqu'un l'utilisera.
• Le prix reporté : repousser la question du tarif à après le lancement. Elle se règle en une heure avec la bonne méthode, pas en trois semaines de comparaison de grilles concurrentes.

Retire ces trois pièges et le calendrier solo rejoint celui d'un lancement à plusieurs sur le même périmètre : ce n'est pas la solitude qui ralentit, c'est le scope qu'on n'a pas su couper.