Jonathan Geiger a bâti la base de son activité suivante en vendant de petits produits

Ce qui restait même sans revenus du premier produit

Jonathan Geiger a conservé des ressources pour son activité suivante même dans des produits aux résultats faibles. Il a consacré environ 120 heures sur près d'un an à son premier produit, LectureKit, mais aucun de ses 190 inscrits n'est devenu client payant. Il est allé jusqu'à terminer le produit et à faire s'inscrire des gens, sans que cela devienne une activité qui encaisse de l'argent en continu. Il a laissé le service tel quel un moment, puis l'a vendu pour 6 750 dollars après avoir reçu une offre de rachat.

La cession de LectureKit lui a appris à mettre un produit dans un état vendable. Son compte rendu de passation, publié en février 2025, décrit le transfert du code vers le dépôt de l'acheteur, la migration de la base de données et du domaine, et la copie vers un nouveau compte du contenu stocké sur AWS. Même pour un service aux ventes faibles, un logiciel qui fonctionne et un environnement d'exploitation restaient des biens échangeables. En fermant sa première activité, Geiger a récupéré une partie de ses coûts de développement et acquis l'expérience pratique qui servirait aux ventes suivantes.

Avec WaitListKit, il s'est arrêté à un stade plus précoce. Il a encaissé un paiement de précommande, mais après avoir jugé si c'était un produit qu'il voulait continuer à développer, il a remboursé l'acheteur et abandonné le projet. La raison de cet arrêt doit être distinguée d'une conclusion selon laquelle il n'y aurait eu aucune demande. Même après avoir confirmé une intention d'achat, si l'opérateur manque de volonté pour porter et construire le produit sur le long terme, il pouvait solder la promesse et passer à l'essai suivant.

Une expérience de vente d'un kit de démarrage bon marché

NextUpKit a été une expérience de vente d'un outil de développement bon marché. Présenté en janvier 2025, c'était un kit de démarrage Next.js regroupant les fonctions qu'il implémentait sans cesse, comme la connexion, le paiement et la connexion à une base de données. Le prix annoncé alors était une licence à vie de 20 dollars, visant les développeurs individuels et débutants que les produits concurrents à plusieurs centaines de dollars rebutaient. Il a cherché à expliquer ce que l'acheteur obtiendrait et à se différencier en abaissant le coût initial.

Le départ n'était pas mauvais. Geiger a indiqué avoir vendu trois exemplaires dans les 24 heures suivant le lancement, dont deux issus d'une liste d'attente préalable. Un encart de présentation de NextUpKit placé en bas de LectureKit a contribué au trafic de la liste d'attente. Le service précédent, qui n'avait pas réussi à obtenir de clients payants, a aussi servi de canal pour annoncer le produit suivant.

Quelques achats précoces n'ont pas fait disparaître le problème de la description du produit, pour autant. De la communauté sont venues des remarques disant qu'on ne comprenait pas exactement ce qui était vendu, des critiques sur une documentation technique trop mince, et des retours jugeant peu claire la raison de demander un nom d'utilisateur GitHub pendant l'achat. Geiger a lui aussi reconnu que si les visiteurs ne comprenaient pas à quoi servait le produit, son explication n'avait pas été suffisante. Ces réactions montrent que le travail de baisse du prix et celui qui consiste à mettre l'acheteur en confiance pour choisir demandent des efforts distincts.

NextUpKit a ensuite enregistré environ 400 dollars de revenus cumulés, et Geiger l'a basculé en open source gratuit. Chaque essai précédent a reçu un traitement différent : vente, remboursement puis arrêt, publication gratuite. Il n'a pas choisi de retenir tous les produits comme activité payante.

Choisir des marchés où des clients paient déjà

Ces expériences ont affiné ses critères de sélection de l'idée suivante. Il cherchait, dans un domaine qu'il comprenait, deux ou trois concurrents réalisant environ 20 000 à 80 000 dollars de chiffre d'affaires mensuel. Il se servait du chiffre d'affaires des concurrents comme preuve que des clients payaient pour résoudre ce problème. À cela s'ajoutaient la question de savoir s'il comprenait les clients et s'il pouvait créer une différence petite mais nette. Les performances d'un concurrent ne garantissent toutefois pas les revenus d'un nouveau produit, si bien que l'étape consistant à confirmer les paiements de ses propres clients après le lancement restait nécessaire.

Le produit qui correspondait bien à ce critère était CaptureKit, une API de capture d'écran et d'extraction de données web. Créer le produit minimum viable a pris environ trois semaines, et les deux premiers mois ont apporté plus de 300 inscrits et sept clients payants. Les revenus récurrents mensuels étaient de 127 dollars, mais le produit a été vendu 15 000 dollars en deux mois et demi environ. Même si ces revenus étaient faibles pour couvrir un coût de vie continu, il a pu traiter avec un acheteur qui avait besoin de la technologie terminée.

Ce que Geiger a tiré de CaptureKit ne s'est pas limité au prix de vente. Il a expliqué qu'en développant SocialKit il a réutilisé les schémas d'authentification, de paiement, de gestion des clés d'API, de structure de documentation et de page de présentation. Le produit suivant a pu réduire le travail consacré aux fonctions communes déjà résolues. La marge pour se concentrer sur un nouveau problème client venait de l'expérience d'implémentation du produit précédent.

De l'extraction de données à une API de publication

Le rôle de SocialKit était de transformer du contenu de réseaux sociaux en données faciles à utiliser depuis d'autres programmes. Quand un développeur ou un marketeur transmettait l'adresse d'une vidéo, il obtenait des transcriptions, des résumés, des indicateurs de réaction et autres, pour les brancher à son propre service ou à son travail d'analyse. C'était une structure qui allégeait pour le client la charge de combiner lui-même le mode d'accès de chaque plateforme et les outils de traitement vidéo. Appliquer l'expérience d'extraction de données web à un usage plus précis a aussi rendu plus clair le travail confié au produit par l'acheteur.

Le travail de collecte de clients a lui aussi commencé en même temps que le développement. Geiger a expliqué avoir préparé une vingtaine de sujets d'articles au début de SocialKit et mis en place des pages de présentation par fonction détaillée ainsi que des outils gratuits. Il a aussi posé des plans pour donner aux premiers utilisateurs l'occasion de l'essayer et recueillir leurs retours, et pour partager le contenu sur plusieurs communautés de développeurs et canaux sociaux. Pendant qu'il construisait le produit, il construisait aussi les chemins par lesquels les gens arriveraient et les points de contact pour recevoir leur avis après usage.

Les outils gratuits et l'API payante étaient reliés pour traiter le même problème à des échelles différentes. Par exemple, SocialKit proposait un extracteur de sous-titres YouTube et un résumeur de vidéo, tout en indiquant l'API qui réalise ce travail depuis un programme. Le visiteur pouvait traiter lui-même une petite tâche et voir le résultat, puis, lorsqu'il avait besoin d'exécutions répétées ou d'une intégration à un service, envisager l'API. Cette configuration était une façon de montrer la valeur du produit par des résultats réels plutôt qu'en s'appuyant seulement sur le texte de présentation.

PostPeer a traité le problème de la publication de contenu sur les réseaux sociaux. Selon l'explication des fondateurs, une fonction d'apparence simple demandait beaucoup de temps de développement, car chaque plateforme a des API, des procédures de connexion de compte et une gestion des identifiants différents. PostPeer a regroupé ce travail dans une seule API pour publier sur plusieurs plateformes. Les deux produits différaient par leur fonction, l'un extrayant des données et l'autre les publiant, mais la direction de l'activité se poursuivait : prendre en charge le travail que les clients implémentent et maintiennent sans cesse.

Une troisième vente et le choix suivant

PostPeer a été créé avec Yoav Mendelson. Mendelson avait lui aussi de l'expérience en développement logiciel et SaaS, et décrivait dans sa présentation officielle son rôle comme la création d'une API rapide, prévisible et facile à intégrer. Geiger a choisi la collaboration en élargissant la gamme de produits. Il a conservé l'expérience de créer des produits seul, sans figer pour autant le mode d'exploitation du nouveau produit.

Dans la structure de vente, il a séparé l'étape où le client essaie le produit de celle où il l'utilise pour de bon. Les pages tarifaires publiques des deux produits proposent des options d'abonnement et d'achat à l'usage, et PostPeer offre 20 crédits gratuits pour tester. Cette configuration permet à un client ayant vérifié les résultats à petite échelle de choisir le mode de paiement correspondant à sa fréquence d'usage. Elle ouvre aussi une voie vers l'usage payant pour les clients à qui il est difficile de s'engager d'emblée sur un abonnement long.

La charge d'adoption ressentie par l'acheteur était également traitée sur les pages de vente. Les pages tarifaires de SocialKit et PostPeer comportent des témoignages de clients soulignant une connexion facile et un support rapide. PostPeer en particulier rassemble un témoignage sur la connexion de plusieurs plateformes en peu de temps et un autre sur un accompagnement jusqu'à la résolution du problème. Au-delà des fonctions et du prix, les deux produits apportaient une information qui réduisait l'inquiétude du client quant à la possibilité d'utiliser réellement le produit après l'achat.

Le chiffre d'affaires mensuel combiné de SocialKit et PostPeer, publié dans un entretien de juillet 2026, était d'environ 6 400 dollars. La répartition était d'environ 5 200 dollars de revenus récurrents mensuels et d'environ 1 200 dollars d'achats ponctuels, et la somme des deux chiffres n'est pas entièrement du revenu récurrent. C'était le moment où l'expérience de créer et de clore de petits produits a débouché sur des ventes durables des deux produits d'API.

Ensuite, Geiger a aussi annoncé la vente de SocialKit. Les chiffres publiés alors étaient 23 150 dollars de revenus cumulés, 3 317 dollars de revenus récurrents mensuels, 117 abonnements actifs et plus de 21 300 inscrits. Sur X, il a expliqué que la taille de l'opération atteignait 85 000 dollars, en additionnant 75 000 dollars de prix de vente et 10 000 dollars de conseil. C'était la troisième vente après LectureKit et CaptureKit, et cette fois il cédait une activité ayant déjà sécurisé des revenus récurrents.

Dans l'annonce de l'acquisition, il a exposé un plan pour se concentrer sur PostPeer avec Mendelson. Il n'a pas figé même un produit déjà développé comme une chose qu'il devait conserver, et l'a jugé avec l'activité sur laquelle il se concentrerait ensuite. L'expérience de vente apprise en clôturant ses premiers produits s'est prolongée dans le choix autour d'une activité plus grande.

Ce qui a rendu l'essai suivant plus favorable dans le parcours de Geiger, c'est d'avoir traduit les résultats antérieurs en changements concrets. Il a complété les explications que les clients ne comprenaient pas, réutilisé le travail de développement répétitif et resserré ses choix sur des domaines où des clients payaient. Il a clos les produits qu'il n'avait pas la volonté de continuer à exploiter, et pour ceux qu'il comptait faire grandir il a préparé à la fois les voies d'acquisition de clients et de paiement. Même quand le résultat du premier produit est modeste, les conditions de départ du suivant peuvent être améliorées, et lorsque ces améliorations se poursuivent, les essais répétés s'accumulent en une seule capacité d'activité.