L’origine
Tout part d’une mission avec client où j’intègre Bouncer
(un outil qui permet de vérifier la délivrabilité d’un email)
Et là ça a fait tic
Si je peux vérifier un email, alors si j’ai : prénom, nom et nom de domaine
Je peux tester différentes combinaisons, jusqu’à tomber sur un email délivrable. 🤔
J’ai le sentiment que les emails finder actuels ont trop de fonctionnalités,
Deviennent des CRM, voir des outils d’outreach
Et Fonctionnent que sur abonnement
J’ai voulu revenir sur un fonctionnement simple :
Ici une seule fonctionnalité claire et pas d’abonnement
Et un fonctionnement au crédit, 1 crédit = 1 email vérifié
L’Email Finder pour Linkedin
Je pense que vous avez compris où je veux en venir
Je vous présente le premier produit de ce challenge :
Un Email Finder, pour Linkedin
Commerciaux, recruteurs, dirigeants, chercheurs d’emploi : entrez facilement en contact avec votre cible.
Concrètement, c’est :
Une extension chrome
80% de taux de réussite 🔥
Uniquement des emails professionnels et vérifiés ✅
C’est live, et je vous offre 20 crédits à l’inscription.
La stack technique
Quelle est la part de nocode / lowcode dans ce produit ?
Pour commencer, une extension chrome demande du code, donc ce n’est pas un projet 100% no code.
Il y a une partie de Javascript pour gérer la logique côté client.
Cependant il existe des outils pour vous aider à créer votre extension, et notamment FlutterFlow, un éditeur low code d’applications.
Si ça vous intéresse, je vous conseille de consulter cet article.
Côté NoCode, voici les outils utilisés :
Bouncer, la clé pour trouver l’email.
C’est avec cet outil que je teste les différentes combinaisons d’emails, pour trouver une combinaison valide.Baserow, la base de données.
La version open source de Airtable.Stripe, pour collecter les paiements.
N8N, pour gérer la logique entre ces outils.
Pourquoi N8N plutôt que Make (ex Integromat) ?
Je suis un grand fan de Make, et un de leurs partenaires.
Mais il faut avouer que N8N a fait de gros progrès… Et leur modèle tarifaire est clairement intéressant pour moi ici.
Je vous explique :
Le modèle de facturation de Make dépend d’un nombre d’opérations, où une opération = l’exécution d’un module.
Un module c’est une étape d’un scénario, voir l’image ci-dessous.
Ainsi si on a un scénario complexe, il va consommer beaucoup d’opérations.
Du côté de N8N, le modèle se base sur l’exécution d’un scénario quelque soit le nombre de modules qu’il contient.
Vous avez compris, pour les scénarios complexes N8N est un peu plus intéressant financièrement.
Ce qu’on va voir avec ce premier outil
Ce premier outil va nous permettre de couvrir les sujets suivants dans les prochaines semaines :
Faire du reverse engineering sur Linkedin, pour comprendre son API
Créer un processus d’inscription / connexion simple, et en Nocode
Créer la logique d’Email Finder en No code
Créer une API en Nocode
Gérer des paiements en Nocode
À très vite,
Antoine