Ask HN : Y a-t-il des personnes qui vivent d’une API payante ?

• Question sur l’existence de développeurs solo ou de petites équipes qui vivent de la vente d’accès à une API
  • De quelle API s’agit-il ? Quel est le MRR ? Quel est le modèle de tarification ? Comment avez-vous trouvé votre premier client payant ?
• Et surtout, quel problème résolvez-vous pour lequel des gens sont réellement prêts à payer tous les mois ?
• En complément, j’aimerais aussi avoir des retours sur la plus grande difficulté rencontrée (limitation de débit ? support client ? concurrence ?) ainsi que sur ce que vous auriez aimé savoir avant de vous lancer.

---

Exemples de succès d’API payantes

• API d’OCR/extraction de documents, d’authentification (CIAM) : FormX(https://formx.ai), Authgear(https://authgear.com)

  • Facturation à l’usage, contrats annuels, pour un MRR d’environ 35 000 à 55 000 dollars
  • Les premiers clients B2B ont été obtenus via des partenariats GCP/Azure et ISV, puis le marketing est devenu le principal défi
  • Difficultés rencontrées dans le support aux développeurs (résolution de problèmes avec les développeurs d’autres équipes, troubleshooting)

• API de capture d’écran : ScreenshotOne(https://screenshotone.com)

  • Développée en solo, MRR de 20 000 dollars, coût serveur mensuel de 5 500 dollars
  • Élargissement de la base utilisateurs via le SEO, les réseaux sociaux et un marketing direct
  • Entrer sur ce marché est très difficile ; si c’était à refaire, le choix se porterait sur une niche plus accessible
  • Exploitation directe d’un cluster de navigateurs pour garantir la qualité, avec des extensions personnalisées (suppression des pubs/bannières cookies, etc.)

• API de télécom/SMS : 46elks

  • Intégration directe avec des opérateurs mobiles locaux en Suède et en Europe, plateforme personnalisée basée sur Python
  • MRR de 500 000 euros, facturation basée sur l’usage
  • Les premiers clients ont été trouvés grâce au réseautage hors ligne, comme les hackathons et meetups ; la mise à l’échelle reste un défi
  • Présence de grands concurrents mondiaux comme Twilio, différenciation par la localisation et le support

• API de machine learning (ML) :

  • API de machine learning spécialisées sur des domaines précis, avec facturation à l’usage/à l’opération
  • MRR allant de quelques milliers à plusieurs dizaines de milliers de dollars
  • Structure où les entreprises front-end captent l’essentiel des revenus, ce qui limite une simple API ML

• API de reconnaissance vocale (Speech-to-Text) : borgcloud.org

  • Facturation horaire (0,06 dollar/h), MRR d’environ 5 000 dollars
  • Les premiers clients payants sont venus de communautés comme Reddit
  • Intensification de la concurrence sur les prix face aux grands cloud providers (Whisper, Groq, etc.)
  • Réduction des coûts grâce à l’utilisation d’un réseau GPU interne

Défis et enseignements communs

• Le marketing et le support client sont des défis plus grands que la technique
  • Même avec des développeurs comme cible, il faut une démarche active de vente et de support
  • Utilisation de canaux variés : GCP/Azure, hackathons, blogs, réponses sur Stack Overflow, etc.
• Il faut aussi gérer la compétitivité prix, les éléments de différenciation et les questions juridiques
  • Si l’on ne fournit qu’une API, la structure de revenus est moins favorable que pour une entreprise front-end
  • Il faut aussi réfléchir aux coûts d’exploitation internes (serveurs, etc.) et aux commissions de plateformes comme RapidAPI

Structure du marché et stratégies de survie

• L’activité API fonctionne lorsqu’elle s’appuie sur une niche forte (problème/client/domaine spécifique)
  • ImageMagick, SMS, authentification, parsing de recettes, etc. : les clients paient lorsqu’on supprime des frictions ou inefficacités face à l’open source existant ou aux grandes entreprises
  • Il est aussi possible d’empaqueter jusqu’au front-end, ou, si l’on ne propose qu’une API, d’atteindre indirectement les clients via plusieurs applications
• La clé est de résoudre le “vrai problème” (pain point) du client
  • Les points de contact directs avec le client (front-end) portent davantage de valeur, et une API seule montre clairement ses limites de monétisation

Autres enseignements

• La plupart des répondants soulignent les mêmes points : « il est difficile de démarrer mais c’est possible avec une exploitation constante », « attention à l’intensification de la concurrence et à l’apparition d’alternatives », et « fournir une API ne permet de capter qu’une partie de la valeur totale du marché »
• Une activité d’API ne peut réussir que si le problème à résoudre est clair et que les clients sont réellement prêts à payer

[unqocn]

C’est génial... ! Ça a l’air d’offrir une vraie liberté, mais le plus difficile doit être de devoir constamment se poser la question de la pérennité.

[GN⁺]

Avis Hacker News

• Partage d’expérience : au départ, l’auteur a commencé comme société de prestation de développement, puis a créé deux produits API à partir de la demande de ses clients. Le premier est un service d’OCR et d’extraction de documents ; au début, faute de solution utile prenant en charge les caractères chinois, il l’a construit lui-même. Plus récemment, il a réorienté le produit en y ajoutant diverses fonctionnalités à l’aide de LLM/VLM (fine-tunés). Par exemple : fine-tuning sur les données d’un client spécifique, ajustement de prompts pour des éléments précis comme les cases à cocher, ou découpage de PDF de plusieurs centaines de pages en plusieurs documents plus courts. Le produit génère actuellement environ 55 000 dollars de MRR, avec une tarification à la page et des contrats annuels, souvent assortis de remises. Le second est un CIAM open source, qui atteint environ 35 000 dollars de MRR. Parti de zéro en marketing, il a d’abord trouvé ses premiers clients payants en collaborant comme ISV avec des partenaires locaux de GCP/Azure, ce qui l’a naturellement amené vers le marché « entreprise ». Il souligne que le marketing produit compte beaucoup, mais que le support client auprès des développeurs n’est pas simple non plus — en tant que développeur, on peut aider d’autres développeurs, mais cela implique parfois de déboguer les problèmes d’autres équipes. Exemple concret : un client signalait soudainement des résultats d’API erronés ; après de nombreux échanges par e-mail, une réunion vidéo avec partage d’écran a permis de découvrir que le client appelait l’API derrière un proxy avec le cache activé. Liens vers les services FormX.AI et Authgear

  • Question sur les raisons et la méthode derrière le partenariat avec les entités locales de GCP/Azure : cette approche paraît intelligente, mais les grands fournisseurs cloud accueillent-ils favorablement ce type de proposition ? Leur a-t-il été proposé d’aider à conclure des deals en fournissant des solutions sur mesure pour les clients ?

• Présentation d’un cas atypique vécu par une connaissance. Dans une entreprise du secteur de l’énergie, des consultants externes avaient complexifié l’IT interne, tandis que des employés permanents inefficaces peinaient à exécuter la moindre requête. Cette personne connaissait très bien la base de données clients du gaz, a créé sa propre société et est passée du statut d’employé à celui de consultant. Après avoir brièvement mis l’entreprise en difficulté puis être revenu, il a proposé un contrat pour migrer et gérer les données clients dans son propre système, améliorant l’efficacité opérationnelle grâce à l’automatisation et gagnant de l’argent via des frais d’usage de l’API et un abonnement mensuel

  • Avis selon lequel le fait de transférer les données clients du gaz dans son propre système semble juridiquement problématique

  • Impression qu’il s’agit d’une entrée sur le marché similaire à celle des consultants externes existants, mais avec un processus bien plus automatisé et efficace

  • Impression que cela ressemble à une étape supplémentaire de coercition ou d’extorsion, tout en se demandant s’il existe une manière plus positive d’interpréter la situation

  • Interrogation sur la légalité d’une telle pratique, et sur la fréquence à laquelle une personne connaissant très bien une entreprise devient indépendante pour faire ce genre de travail

• Présentation de ScreenshotOne, un business d’API de captures d’écran exploité en solo par un ami nommé Dmytro, qui a récemment dépassé les 20 000 dollars de MRR. Liens vers le compte X de Dmytro et le service

  • Question pour savoir s’il gère lui-même les navigateurs automatisés ; hypothèse selon laquelle il pourrait s’agir d’un wrapper autour de services comme Scrapfly, Scraping Bee ou Zen Rows, avec éventuellement du JavaScript sur mesure pour supprimer des bannières

  • Curiosité sur la manière dont une entreprise comme ScreenshotOne construit sa base d’utilisateurs, avec demande d’idées ou d’hypothèses

• Travaille dans une petite entreprise où l’essentiel du chiffre d’affaires provient d’une API payante. Les détails ne peuvent pas être partagés pour des raisons de confidentialité. Cette API repose sur un modèle de machine learning de tout premier plan pour un scénario spécifique, avec une grille tarifaire publique et des remises négociées individuellement. Le plus grand défi récent est l’arrivée d’alternatives gratuites suffisamment bonnes pour le grand public, comme Google Lens, qui grignotent le marché. L’auteur regrette de n’avoir construit qu’une API ML sans application propre, car ce sont en pratique ceux qui réalisent le frontend qui captent plus de revenus

  • Demande d’explication sur la raison pour laquelle ceux qui construisent le frontend finissent par gagner l’argent

  • Avis selon lequel ce sont eux qui résolvent directement le problème de l’utilisateur final, c’est-à-dire de la source de revenu ; l’API est une étape plus éloignée de la monétisation

  • Demande pour savoir s’il est vraiment si regrettable de n’avoir exploité qu’une API ML au lieu d’une application destinée aux utilisateurs finaux ; si plusieurs apps utilisent l’API, se concentrer sur sa compétence clé et agréger de petits revenus peut malgré tout avoir du sens

  • Analyse selon laquelle, dans ce cas, le marché de l’API lui-même était peut-être trop petit. Si l’API correspond quasiment à une seule application, il faut sans doute construire l’app ; mais si elle sert plusieurs apps sans générer assez de chiffre d’affaires, c’est peut-être que le besoin du marché est insuffisant

• Exploite une API qui convertit des recettes de cuisine (phrases d’ingrédients, par ex. 2 cups finely chopped onions) en JSON structuré, avec un revenu d’environ 200 dollars par mois. Le service tourne depuis 2019 en mode maintenance, avec une gestion très passive (une à deux heures par an). Il se dit surpris que tous les clients n’aient pas encore complètement migré vers les LLM ; sans doute que sur ce type de niche, l’API existante reste compétitive en prix ou en précision. Il aimerait qu’un repreneur rachète le service et le fasse évoluer, mais rien que la préparation de la cession demanderait 30 à 40 heures ; en coût d’opportunité, cela représente 5 000 à 10 000 dollars, et il paraît peu probable que quelqu’un achète une API à 200 dollars mensuels à ce prix. Il insiste sur le fait qu’avoir utilisé RapidAPI au départ a été une grosse erreur (20 % de commission, UI peu pratique, paiements impayés) et qu’il aurait mieux valu construire son propre système de facturation avec Paddle. Lien vers ZestfulData

  • Partage d’une expérience où une personne a recréé exactement le même site avec l’API ChatGPT comme projet de préparation à un entretien ; la plus grande difficulté était que, lorsqu’on demandait à ChatGPT comment utiliser l’API, les exemples de code proposés étaient souvent obsolètes et ne fonctionnaient plus

  • Remarque selon laquelle, dans le pays de l’intervenant, le coût du travail en freelance est d’environ 200 euros par mois, principalement à cause des charges comme l’assurance santé. En d’autres termes, avec 200 dollars de revenus mensuels, ce n’est pas viable ; question sur la manière de faire cela légalement avec une marge aussi faible

  • Question sur le type de clients qui utilisent cette API ; l’auteur avait eu plusieurs idées similaires, mais du point de vue marketing, il a l’impression que des développeurs capables de créer leurs propres outils n’utiliseraient pas forcément une API externe comme celle-ci

  • Question directe sur la manière dont les premiers clients ont été trouvés

• L’auteur s’intéresse lui aussi à la manière de créer de la valeur avec des projets techniques. Mais le problème, lorsqu’on explore ce sujet, est que les personnes qui ont réussi ont peu d’incitation à partager leurs expériences en détail. Au pire, cela peut même faciliter l’entrée de concurrents. Contrairement aux communautés ouvertes à la croissance comme l’open source, la culture des business d’API pousse peu au partage d’informations, car ils sont faciles à copier. Parmi les types de services découverts récemment, il cite un service qui diffuse automatiquement de longs fichiers vidéo, par exemple des livestreams YouTube

  • Du point de vue d’un technicien, on peut facilement se dire : « n’importe qui pourrait construire ça ». Mais au final, la vraie question est de savoir si les clients sont prêts à payer. À l’époque du Pirate Bay triomphant, la musique était pratiquement gratuite, mais Spotify a créé un marché payant grâce à une meilleure commodité. Il existe aussi de l’open source comme ImageMagick, mais certains services réussissent malgré tout en API/SaaS au-dessus de cette brique. La raison est simple : les personnes et les entreprises paient pour la commodité. Le point de départ est donc de trouver un problème dans un domaine qu’on connaît bien et qu’on peut résoudre techniquement ; il recommande de commencer par un secteur ou un profil de client qui nous intéresse vraiment et qu’on connaît bien. Comme il était développeur, il a lui-même construit une API pour les besoins des développeurs

  • Chaque entreprise a quelques secrets que seule une minorité connaît, et une connaissance approfondie d’un secteur permet d’analyser ce que font les concurrents. Mais ce qui permet vraiment de développer un business tient souvent à un savoir-faire caché, difficile à voir de l’extérieur. L’auteur affirme qu’il pourrait encore aujourd’hui appliquer une nouvelle variante à son activité existante et générer 1 million de dollars de revenu annuel supplémentaire en deux ans. Mais il travaille déjà plus de 60 heures par semaine et gagne bien sa vie ; partager l’idée avec quelqu’un pour monter ce business en partenariat ferait courir un risque d’exposition analytique trop important, d’où sa réticence assumée

• Vit de l’API SMS & appels qu’il a créée. Le revenu récurrent mensuel est d’environ 500 000 euros, avec une tarification à l’usage (SMS/MMS à l’unité, appels à la minute, numéros virtuels au tarif mensuel). Le cœur de la valeur est de pouvoir accéder de manière programmatique aux réseaux mobiles locaux en Europe, notamment en Suède. Les premiers clients ont été trouvés par du networking hors ligne (hackathons, meetups, contacts personnels, etc.), mais cette approche reste la plus grande difficulté lorsqu’il s’agit de faire croître l’entreprise. Le parcours jusqu’ici a été difficile, et il dit qu’il lui arrive encore de trouver irréel que tout fonctionne aussi bien aujourd’hui

  • Question sur la stack technique utilisée, avec remarque qu’il y a beaucoup d’histoires liées à l’infrastructure IT suédoise parmi les connaissances de l’intervenant

  • Question directe pour savoir s’il faut comprendre cela comme un service similaire à Twilio, mais orienté réseaux européens locaux

• Partage d’expérience autour de dreamlook.ai, une API de fine-tuning de modèles texte-vers-image exploitée par une équipe de deux personnes. Lors du lancement, il y a trois ans, l’avantage différenciant était de pouvoir entraîner moins cher et plus vite avec des TPU ; mais récemment, les GPU ont beaucoup progressé et la concurrence open source s’est intensifiée. Le service réalise aujourd’hui 5 000 dollars de revenu mensuel ; comme l’équipe s’en est presque totalement détachée, c’est encore acceptable, mais le chiffre d’affaires a nettement baissé par rapport à il y a un an. Les défis non techniques ont été plus difficiles : ils préféraient une approche très centrée technologie et ont insisté pour faire un produit API-first, mais ont rencontré des difficultés en marketing, en support commercial, etc. Aujourd’hui, l’auteur est revenu à un poste de développeur ML dans une grande entreprise et s’en dit satisfait. Il est fier d’avoir construit son propre business, mais il se sent plus heureux maintenant

  • Question sur l’existence de chiffres concrets concernant les coûts d’exploitation GPU et le budget utilisé au moment de la mise en place

• À propos de la recherche de clients payants, présentation de Postman comme plateforme de distribution et de réseau pour développeurs et API (Postman Explore). La facturation doit être gérée soi-même, mais la plateforme permet de gagner en visibilité grâce à son réseau

• Partage d’un retour d’expérience sur la naissance d’un business d’API de podcasts, en indiquant qu’on peut y lire le cas de wenbin