J’ai réécrit cet épisode quelques temps après sa première publication. Il ne me cringeait pas autant que les précédents mais une repasse était tout de même nécessaire. Par ailleurs, Phantoms Health n’existe plus.

Le contexte est tendu pour les freelances dans la tech.

Il n’y a pas si longtemps, il me suffisait d’exister pour recevoir des propositions de missions. Ce n’est plus le cas, et il en va de la survie de mon auto-entreprise de trouver des clients.

Voilà pourquoi j’ai développé un micro-SaaS sans intention apparente de le monétiser.

En fait, le vrai but de Phantoms Health, c’est d’envoyer des emails à mes utilisateurs pour leur parler de ce que je fais en freelance. C’est ce qu’on appelle un lead magnet.

N’est-ce pas un peu antithétique de lancer un micro-SaaS quand on manque de temps ? Je ne pense pas et pour deux raisons :

1. l’effort marginal à fournir pour obtenir un lead supplémentaire est de plus en plus faible à mesure qu’on optimise un tel produit (i.e c’est scalable)

2. même s’il faut investir du temps en amont, on peut tout à fait faire en sorte que ça n’en prenne pas trop.

C’est le point de vue que je défendrai dans cet épisode. Il ne faut pas s’attendre un tuto détaillé sur la manière de construire un petit SaaS rapidement.

Je vais plutôt te raconter l’histoire de Phantoms Health, de l’idée jusqu’à la release, en détaillant le temps que chaque étape m’a prise.

Tout a commencé par un sondage sur WhatsApp.

Genèse

Qu’on soit freelance ou en CDI, le point de départ demeure de trouver un problème douloureux à résoudre.

Dans mon cas, les idées que j’ai soumises à leur suffrage me viennent de ce que j’ai observé en mission chez mes clients. Et c’est l’option 2 (cf. screenshot WhatsApp) qui a gagné.

Mon lead magnet est une app qui scanne une configuration de Phantombuster et alerte l’utilisateur si elle met ses comptes LinkedIn en danger. Je l’ai appelée Phantoms Health.

Le rapport avec mon offre en freelance

Mon offre (edit: ancienne offre) :

Aider les entreprises sales-led à augmenter leurs taux de conversion outbound en deux mois grâce aux signaux d’intent.

Or les entreprises sales-led qui font de l’outbound sont nombreuses à utiliser Phantombuster (outil de scraping pour les réseaux sociaux) — un outil compliqué à configurer sans se faire bannir par LinkedIn.

Donc, avec Phantoms Health, je résous un problème connexe que rencontrent les growth dans les entreprises que je cible.

Et même si seuls 50% d’entre eux sont dans ma cible, c’est déjà un beau recouvrement. Donc, en vertu de ce “recouvrement”, j’ai commencé à créer le produit.

Création

Modèles mentaux pour aller vite

J’ai appliqué ces deux modèles mentaux pour accélérer le développement de mon projet :

1. Second-order thinking

   Certes, si je ne prenais pas le temps de cadrer le projet, au premier ordre, je m’épargnerais quelques heures de réflexion. Mais au second ordre, je perdrais plus de temps.

   En fait, ne pas cadrer un projet tech nous assure quasi-certainement de devoir rétro-pédaler au milieu parce qu’on fonce dans la mauvaise direction.

   Je pense qu’investir du temps en amont permet d’en gagner beaucoup en aval.

2. KISS: keep it simple stupid

   L’autre bon moyen d’aller vite, c’est de faire simple. Il vaut mieux limiter les fonctionnalités et les faire bien, plutôt qu’en faire plein et de les bâcler.

Cadrage en 8h

La fonctionnalité indispensable

Il m’a semblé que ma principale fonctionnalité était de dire aux utilisateurs quoi faire dans Phantombuster, pour mettre leurs comptes LinkedIn hors de danger.

À cette fonctionnalité principale, il fallait en plus rajouter quelques fonctionnalités secondaires pour lui permettre d’exister (créer un compte, se connecter, ajouter une clé d’API Phantombuster, etc.) et finalement en déduire les routes API à créer.

Une stack technique minimaliste pour y arriver

Je voulais :

1. Aller vite (temps d’apprentissage inclus)

2. Faire simple (pour aller vite)

3. Sans me ruiner 🐀

À l’aune de ces trois critères, j’ai choisi la stack suivante :

• Backend → n8n (oui oui)

  

  Concernant mes choix techniques, voici le meilleur — celui qui m’a fait gagner le plus de temps.

• Frontend → vite, react, typescript, tailwind i.e la même stack technique que pour recruitivity. Ici, j’ai gagné du temps en réduisant mon temps d’apprentissage à néant.

• Base de données → Baserow parce que je paye déjà l’outil, qu’il s’intègre bien avec n8n et qu’il est facile à manipuler.

  Néanmoins, si je devais recommencer, je choisirais Supabase (qui s’intègre aussi avec n8n). Je n’aurais pas eu besoin de réinventer la roue sur le sign up, le sign in, le sign out, etc.

• Emailing → Brevo car bon marché, très simple d’utilisation, et… intégré à n8n.

Bref, en ~8h j’avais :

1. choisi le projet

2. défini sa core feature

3. ses features secondaires

4. ses routes API

5. l’architecture du système

6. et sa stack technique.

Le projet était cadré, je pouvais maintenant rentrer dans le dur et me mettre à coder.

Développement

Une API avec n8n en 34h

C’est le moment où j’ai commencé à bidouiller dans n8n pour créer mes endpoints API : sign up, sign in, password reset, scanner le compte Phantombuster (← la core feature), etc.

En tout, il aura fallu 16 workflows : les plus petits ne comportant que deux ou trois blocs, le plus gros en comportant une vingtaine.

De cette section il n’y a qu’une chose à retenir : l’utilisation des sous-workflow.

Elle m’a permis de décomposer une logique complexe en une multitude de petits modules beaucoup plus simples à interpréter, débugger et faire évoluer.

Bref, ~34h plus tard, j’avais mon API, donc je pouvais passer au développement de l’UI. Je ne la voulais pas belle, je la voulais cohérente avec mon actif le plus cher : ma marque personnelle.

31h sur le frontend, véhicule de ma marque

Je veux que tout soit cohérent, de mon contenu à mon expérience client, en passant par mes outils. Je veux que les gens atterrissent dans un univers sans fausse note.

Je veux simplement être identifiable pour que quiconque arrive sur Phantoms Health se dise : “ah c’est encore un truc de bastien ça”.

Et ces considérations valables pour ma petite personne en freelance, me semblent l’être d’autant plus pour une marque plus établie qui déciderait de faire de l’engineering as marketing (i.e créer des outils gratuits pour attirer des leads vers une offre annexe).

Concrètement, je pense qu’il faut absolument réutiliser ses brand assets (palette de couleur, tone of voice, police, etc.), même pour un simple lead magnet.

Alors, avec cet objectif en tête, je me suis mis à créer mes “wireframes”.

Ce serait évidemment un affront que de les appeler wireframes, mais c’était amplement suffisant pour ce projet :

Si bien que 11 jours et 48 commits plus tard, après ~31h de développement, mon frontend était prêt. Je n’avais plus qu’à faire les jointures avec le backend et me préparer au déploiement.

Sauf que le déploiement, c’est ma hantise. C’est le truc que je maîtrise le moins. J’y vais toujours comme un condamné monte sur l’échafaud…

…la boule au ventre

Je me suis rendu sur Digital Ocean (plateforme pour héberger des applis web) en me demandant à quelles circonvolutions j’allais devoir me plier.

J’ai du indiquer la localisation du repo Github où se trouvait le code de mon projet et… c’est tout 🙂

C’est tout ce qu’il a fallu à Digital Ocean pour déployer mon projet et me faire une CI/CD (i.e dès que j’envoie mon code sur Github, Digital Ocean le détecte et répercute les changements sur mon app).

En quelques clics, l’appli était prête.

Il est maintenant l’heure d’aborder un sujet que j’ai totalement occulté alors qu’il représente 30% du temps alloué à ce projet.

Une séquence de 14 emails en 39h

Le but de n’importe quel funnel de demand generation, c’est qu’email après email, je réduise le scepticisme de mes lecteurs et augmente leur confiance en moi :

J’ai donc réfléchi à tout ce que je pouvais leur dire, leur apprendre, leur montrer pour les aider à augmenter leurs taux de conversion outbound (le sujet de mon offre en freelance).

J’ai eu à cœur qu’ils n’aient jamais l’impression de perdre leur temps, qu’ils tirent de la valeur de chacun de mes mails, et, qu’ils n’aient qu’une envie : lire le suivant. Au point qu’à la fin, ils veuillent quand même les partager avec un collègue, même si mon offre ne les intéresse pas.

Pour y parvenir, il ne s’agit pas seulement de dire des choses intéressantes : il faut mettre le lecteur sur un toboggan dont il ne sortira pas.

Après les avoir rédigés, il ne me restait plus qu’à les mettre dans Brevo, puis à faire la jonction entre Brevo et mon backend, pour que n’importe quelle personne s’inscrivant sur Phantoms Health atterrisse dans la séquence.

5h pour exploiter une émotion

Bien sûr, le marketing d’un produit ne repose jamais sur un unique lancement, mais il faut quand même une étincelle pour lancer la machine. Je voulais la lancer sur LinkedIn (parce que j’y ai une petite audience) et que l’étincelle soit la plus grosse possible.

Or, pour faire une grosse étincelle sur les réseaux sociaux, on ne peut pas y couper, il faut que le contenu suscite des émotions (wtf, omg, lol, …).

Je suis de près un créateur qui s’appelle Marc Lou et qui l’a fait plusieurs fois avec brio. Inspiré par ses lancements, je me suis dit que l’émotion à susciter serait “lol” car :

1. c’est une émotion que les growth (genZ, millenials) un peu cool kids de startups peuvent apprécier

2. en me cachant derrière l’humour, je pouvais être moins regardant sur la qualité du montage de ma vidéo

Or, d’expérience, le moyen le plus simple de faire une vidéo drôle, c’est de choisir une séquence culte et de jouer avec ses sous-titres (un exemple).

De cette manière, il m’aura fallu 5h pour créer ma vidéo de lancement.

Conclusion

In fine, voici le temps que ça m’a pris :

Je ne l’ai pas fait en un claquement de doigt, mais ça ne m’a pas pris énormément de temps non plus. D’autant plus que si j’avais travaillé pour une entreprise, on aurait pu parallèliser le développement du lead magnet et de l’app pour livrer le tout en 10 jours.

Bref, j’espère vous avoir convaincu :

1. que c’est pas long de lancer un micro-SaaS

2. et qu’on peut diminuer drastiquement le temps de développement, grâce à n8n notamment.

Dans une prochaine édition, on adressera l’éléphant dans la pièce : mes résultats et les conclusions qu’on peut (ou pas) en tirer.

Outro

Voici toutes les modifications que j’ai dû faire à cet épisode avant de le publier :

Relatability > editing quality, illustré par cette meme trend qui m’atomise de rire :

workingbestie

View more on Instagram