Le reflexe qui tue les premiers projets
Un fondateur qui lance son premier SaaS a pose la question que tout le monde se pose au debut : "Combien de travail mettez-vous dans la phase de planning avant d'ecrire du code ?"
Question legitime. Reponse honnete : c'est la mauvaise question.
Pas parce que planifier est inutile. Mais parce que 90 % des premiers SaaS meurent d'un probleme qui n'a rien a voir avec le code. Ils meurent parce que personne ne sait qu'ils existent.
Le vrai plan, c'est un plan de distribution
Quand tu es a ton premier projet, tu as un biais naturel : tu penses produit. Tu dessines des specs, tu choisis ta stack, tu structures ta base de donnees. Tu passes des semaines a perfectionner quelque chose que personne n'a encore demande.
Le probleme, c'est que le planning technique te donne une illusion de progression. Tu avances sur le produit. Tu coches des cases. Tu te sens productif. Sauf que la seule metrique qui compte a ce stade, c'est : est-ce que quelqu'un est pret a payer pour ca ?
Et cette reponse, tu ne la trouves pas dans un fichier de specs. Tu la trouves en parlant a des gens. En publiant. En te rendant visible.
Un operateur qui installe un SaaS sans pipeline d'acquisition, c'est un cuisinier qui ouvre un restaurant sans adresse. Le plat peut etre excellent. Personne ne viendra le gouter.
Ce que ferait un operateur au lieu d'un planificateur
Premier reflexe concret : avant d'ecrire une ligne de code, publie du contenu sur le probleme que ton SaaS resout. Pas un post generique. Un contenu precis, avec un point de vue, sur le terrain de tes futurs clients. Si tu veux vendre un outil de facturation pour freelances, ecris sur les galeres de facturation des freelances. Chaque semaine. Pendant un mois.
Tu fais deux choses en meme temps : tu valides que le sujet interesse des gens (les signaux d'engagement te le disent vite), et tu commences a construire une audience avant meme d'avoir un produit a montrer.
Deuxieme reflexe : remplace la moitie de ton temps de planning technique par du planning distribution. Ou sont tes futurs clients ? Quels canaux ils consomment ? Quel format de contenu fonctionne dans ton segment ? C'est ca, le vrai travail de fondation. Pas le choix entre PostgreSQL et MongoDB.
Troisieme reflexe : le LLM que tu utilises pour ecrire du code, utilise-le aussi pour produire du contenu. C'est le meme levier d'acceleration. La difference, c'est que le contenu te ramene des signaux du marche. Le code, a ce stade, ne te ramene que de la complexite.
Le piege du perfectionnisme technique
Il y a une raison pour laquelle les fondateurs techniques passent trop de temps a planifier : c'est confortable. Tu maitrises le code. Tu ne maitrises pas la vente. Alors tu restes dans ta zone.
Mais un SaaS, c'est un business. Et un business sans clients, c'est un hobby. La phase de planning devrait inclure, au minimum, autant de travail sur l'acquisition que sur le produit. Idealement plus.
Les fondateurs qui reussissent leur premier SaaS ne sont pas ceux qui ont le meilleur code. Ce sont ceux qui ont trouve leurs 10 premiers clients avant de finir la V1. Parce qu'ils avaient un pipeline. Parce qu'ils etaient visibles. Parce qu'ils avaient commence a publier bien avant d'avoir quelque chose a vendre.
La question que personne ne pose au bon moment
Ta capacite a attirer des clients, c'est ton ascenseur social. C'est vrai pour un freelance. C'est vrai pour un fondateur SaaS. C'est vrai a chaque etape.
Le code, tu peux le faire ecrire. Le design, tu peux le sous-traiter. L'hebergement, c'est un commodity. La seule chose que tu ne peux pas deleguer au debut, c'est ta capacite a etre trouve par les bonnes personnes.
Alors avant de passer une semaine de plus sur ton fichier de specs, pose-toi une question : si tu lances demain, est-ce que quelqu'un le sait ?
Si la reponse est non, ton planning a un trou. Et c'est le seul qui compte.
Plus sur le pipeline B2B dans Le Journal.