Ask HN: Gibt es hier Leute, die mit einer kostenpflichtigen API ihren Lebensunterhalt verdienen?

 (news.ycombinator.com)
14 Punkte von GN⁺ 2025-06-02 | 2 Kommentare | Auf WhatsApp teilen
  • Frage, ob es Solo-Entwickler oder kleine Teams gibt, die vom Verkauf von API-Zugriffsrechten leben
    • Was ist eure API? Wie hoch ist euer MRR? Wie sieht euer Preismodell aus? Wie habt ihr euren ersten zahlenden Kunden gefunden?
  • Und das Wichtigste: Welches Problem löst ihr, für das Menschen tatsächlich jeden Monat bezahlen?
  • Zusätzlich würden mich die größten Schwierigkeiten interessieren (Rate Limits? Kundensupport? Konkurrenz?) sowie Ratschläge nach dem Motto: „Das hätte ich gern gewusst, bevor ich angefangen habe.“

Erfolgreiche Beispiele für kostenpflichtige APIs

  • OCR-/Dokumentenextraktions-, Authentifizierungs- (CIAM) APIs: FormX(https://formx.ai), Authgear(https://authgear.com)

    • Abrechnung pro Vorgang, Jahresverträge, MRR im Bereich von 35.000 bis 55.000 US-Dollar
    • Erste B2B-Kunden über GCP-/Azure- und ISV-Partnerschaften gewonnen, danach wurde Marketing zur größten Herausforderung
    • Schwierigkeiten mit Support für Entwickler erlebt (gemeinsame Problemlösung mit Entwicklern anderer Teams, Troubleshooting)

  • Screenshot-API: ScreenshotOne(https://screenshotone.com)

    • Einzelentwickler, 20.000 US-Dollar MRR, 5.500 US-Dollar Serverkosten pro Monat
    • Nutzerbasis durch SEO, Social Media und direktes Marketing ausgebaut
    • Markteintritt sehr schwierig; bei einem Neustart würde man eine leichtere Nische wählen
    • Eigener Browser-Cluster für Qualitätssicherung, mit benutzerdefinierten Erweiterungen (Entfernung von Werbung/Cookie-Bannern usw.)

  • Telekommunikations-/SMS-API: 46elks

    • Direkte Anbindung an lokale Mobilfunkanbieter in Schweden/Europa, kundenspezifische Plattform auf Python-Basis
    • 500.000 Euro MRR, nutzungsbasierte Abrechnung
    • Erste Kunden über Offline-Networking wie Hackathons/Meetups gewonnen, Skalierung ist die Herausforderung
    • Globale große Wettbewerber wie Twilio vorhanden, Differenzierung über Lokalisierung/Support-Services

  • Machine-Learning-(ML)-API:

    • Auf bestimmte Domänen spezialisierte Machine-Learning-API, Abrechnung nach Nutzung/Anzahl der Vorgänge
    • MRR von einigen Tausend bis einigen Zehntausend US-Dollar
    • Struktur, bei der Frontend-Unternehmen den Großteil der gesamten Erlöse abschöpfen; mit einer reinen ML-API allein gibt es Grenzen

  • Speech-to-Text-API: borgcloud.org

    • Stundenbasierte Abrechnung (0,06 US-Dollar/h), etwa 5.000 US-Dollar MRR
    • Erste zahlende Kunden über Communities wie Reddit gewonnen
    • Verschärfter Preiswettbewerb mit großen Cloud-Anbietern (Whisper, Groq usw.)
    • Senkung der Kosten durch Nutzung eines eigenen GPU-Netzwerks

Gemeinsame Herausforderungen und Learnings

  • Marketing und Kundensupport sind eine größere Herausforderung als die Technik
    • Auch bei einer Zielgruppe aus Entwicklern sind aktiver Vertrieb und Support nötig
    • Nutzung verschiedener Kanäle wie GCP/Azure, Hackathons, Blogs oder Antworten auf Stack Overflow
  • Man muss auf Preiswettbewerbsfähigkeit, Differenzierungsmerkmale und sogar rechtliche Fragen achten
    • Wenn man nur die API anbietet, ist die Erlösstruktur gegenüber Frontend-Entwicklungsfirmen nachteilig
    • Auch eigene Betriebskosten (z. B. Server) und Plattformgebühren wie bei RapidAPI müssen bedacht werden

Marktstruktur und Überlebensstrategien

  • API-Geschäfte funktionieren in starken Nischen (bestimmtes Problem/bestimmter Kunde/bestimmte Domäne)
    • Bei Themen wie ImageMagick, SMS, Authentifizierung oder Rezept-Parsing zahlen Kunden tatsächlich, wenn Unbequemlichkeiten und Ineffizienzen gegenüber bestehendem Open Source oder Großunternehmen beseitigt werden
    • Entweder das Frontend mit verpacken oder bei einer reinen API indirekt über viele Apps an Kunden herankommen
  • Entscheidend ist, das „echte Problem“ (pain point) des Kunden zu lösen
    • Dem direkten Kundenkontaktpunkt (Frontend) wird ein höherer Wert beigemessen, und bei einer reinen API sind die Erlösgrenzen klar erkennbar

Zusätzliche Erkenntnisse

  • Die meisten Antwortenden betonen gemeinsam: „Der Einstieg ist schwer, aber mit beständigem Betrieb machbar“, „Achtet auf zunehmenden Wettbewerb und das Auftauchen von Alternativen“ und „Mit dem bloßen Anbieten einer API schöpft man nur einen Teil des Gesamtmarktwerts ab“
  • Ein API-Business ist erfolgreich, wenn das tatsächlich zu lösende Problem klar ist und Kunden zahlungsbereit sind

Verwandte Beiträge

2 Kommentare

 
unqocn 2025-06-03

Klingt großartig ...! Es wirkt, als könnte es Freiheit bedeuten, aber zugleich scheint es schwierig zu sein, sich ständig Gedanken über die Nachhaltigkeit machen zu müssen.
 
GN⁺ 2025-06-02
Hacker-News-Kommentare

  • Jemand berichtet, zunächst als Entwicklungsdienstleister gestartet zu sein und darauf basierend auf Kundennachfrage zwei API-Produkte entwickelt zu haben. Das erste ist ein OCR- und Dokumentenextraktionsdienst; anfangs gab es keine brauchbare Lösung mit Unterstützung für chinesische Schriftzeichen, daher wurde eine eigene Lösung gebaut. In letzter Zeit wurde die Ausrichtung geändert, um mit (feinabgestimmten) LLMs/VLMs verschiedene Funktionen hinzuzufügen. Zum Beispiel werden Features angeboten wie Fine-Tuning mit Daten eines bestimmten Kunden, Prompt-Tuning für spezielle Elemente wie Checkboxen oder das Aufteilen von PDFs mit hunderten Seiten in mehrere kleinere Dokumente. Derzeit etwa 55.000 Dollar MRR, mit seitenbasierter Preisgestaltung und Jahresverträgen (mit vielen Rabatten). Das zweite Produkt ist ein Open-Source-CIAM und erzielt etwa 35.000 Dollar MRR. Ohne jegliches Marketingwissen gestartet, wurden anfangs durch Zusammenarbeit mit lokalen GCP-/Azure-Partnern als ISV die ersten zahlenden Kunden gewonnen, wodurch sich ganz natürlich der Einstieg in den „Enterprise“-Markt ergab. Produktmarketing sei wichtig, aber auch der Kundensupport für Entwickler sei nicht einfach — als Entwickler könne man zwar andere Entwickler unterstützen, lande aber manchmal dabei, sogar Probleme in fremden Teams zu debuggen. Als konkretes Beispiel wird geschildert, wie ein Client meldete, die API liefere plötzlich falsche Ergebnisse; nach mehrfachem E-Mail-Austausch wurde in einem Videoanruf mit Screen-Sharing schließlich entdeckt, dass die Ursache ein aktivierter Cache im Proxy bei den API-Aufrufen war. Links zu FormX.AI und Authgear

    • Frage, wie es zu Partnerschaften mit regionalen GCP-/Azure-Anbietern kam und welche Tipps es dazu gibt; ob dieser Ansatz klug sei, ob große Cloud-Vendoren solche Vorschläge begrüßen und ob angeboten wurde, kundenspezifische Lösungen bereitzustellen, um Deals abzuschließen

  • Vorstellung eines ungewöhnlichen Falls, den ein Bekannter erlebt hat. In einem Energieunternehmen hätten externe Berater die interne IT unnötig komplex gemacht, und ineffiziente Festangestellte lebten in einer Umgebung, in der schon eine einzelne Query schwer auszuführen war. Dieser Bekannte kannte die Gas-Kundendatenbank sehr gut, gründete seine eigene Firma und wechselte vom Angestellten zum Berater. Er habe dem Unternehmen kurzzeitig Unordnung hinterlassen, sei dann zurückgekehrt und habe einen Vertrag vorgeschlagen, um die Kundendaten in sein eigenes System zu überführen und dort zu verwalten, die Abläufe zu automatisieren und Einnahmen über API-Nutzungsgebühren plus monatliche Gebühren zu erzielen

    • Die Meinung, dass das Verschieben von Gas-Kundendaten in das eigene System rechtlich problematisch wirke

    • Der Gedanke, dass dies dem Vorgehen klassischer externer Berater ähnelt, nur mit einem wesentlich stärker automatisierten und effizienteren Prozess

    • Der Eindruck, dass es wie eine zusätzliche Stufe von Zwang oder Erpressung (extortion) klingt, verbunden mit der Frage, ob es eine positivere Interpretation dafür gibt

    • Die Frage, ob so etwas legal ist und wie häufig es vorkommt, dass jemand mit guter Firmenkenntnis sich selbstständig macht und so arbeitet

  • Vorstellung des Screenshot-API-Businesses ScreenshotOne, das Dmytro allein betreibt und das kürzlich die Marke von 20.000 Dollar MRR überschritten hat. Geteilt werden der X-Account von Dmytro und der Dienst

    • Frage, ob die automatisierten Browser direkt selbst betrieben werden; Vermutung, dass es auch ein Wrapper um Dienste wie Scrapfly, Scraping Bee oder Zen Rows sein könnte und möglicherweise kundenspezifisches JS enthält, um Banner zu entfernen

    • Neugier, wie ein Unternehmen wie ScreenshotOne seine Userbase aufbaut; Bitte um Ideen oder Vermutungen

  • Jemand arbeitet in einem kleinen Unternehmen, dessen Umsatz größtenteils aus einer kostenpflichtigen API stammt. Wegen Vertraulichkeit können keine Details genannt werden. Die API sei ein erstklassiges Machine-Learning-Modell für ein bestimmtes Szenario, mit öffentlicher Preisliste und individuell verhandelten Rabatten. Die größte aktuelle Herausforderung sei, dass kostenlose Alternativen, die für normale potenzielle Kunden „gut genug“ sind, wie Google Lens, das Geschäft zunehmend kannibalisieren. Bedauert wird, nur eine ML-API gebaut und keine eigene App entwickelt zu haben; geteilt wird die Beobachtung, dass am Ende diejenigen mehr verdienen, die das Frontend implementieren

    • Bitte um Erklärung, warum ausgerechnet die Seite, die das Frontend baut, am Ende das Geld verdient

    • Die Meinung, dass genau diese Seite das Problem der Nutzer (also der Erlösquelle) unmittelbar löst, während eine API in der Wertschöpfung eine Stufe weiter vom Umsatz entfernt ist

    • Die Frage, ob es wirklich so bedauerlich ist, nur eine ML-API statt einer Endnutzer-App betrieben zu haben; wenn mehrere Apps die API nutzen, könne es sinnvoll sein, sich auf die Kernkompetenz zu konzentrieren, und auch kleinere Erlösströme könnten in Summe bedeutend sein

    • Die Analyse, dass in solchen Fällen vielleicht einfach der Markt für die API zu klein war. Wenn eine API faktisch 1:1 einer App entspricht, sollte man eher die App bauen; wenn sie mehrere Apps unterstützt und dennoch nicht genug Umsatz bringt, könnte die eigentliche Marktnachfrage zu gering sein

  • Jemand betreibt eine API, die Rezeptangaben (Zutatenzeilen wie „2 cups finely chopped onions“) in strukturiertes JSON umwandelt, und verdient damit etwa 200 Dollar pro Monat. Das Ganze läuft seit 2019 im Wartungsmodus und wird sehr passiv betreut (ein bis zwei Stunden pro Jahr). Überraschend sei, dass nicht alle Kunden vollständig zu LLMs gewechselt sind; vermutlich bleibe in solchen Nischen die bestehende API wegen Preis oder Genauigkeit konkurrenzfähig. Es wäre schön, wenn jemand das Projekt übernehmen und weiterentwickeln würde, aber schon die Vorbereitung auf eine Übernahme würde etwa 30–40 Stunden kosten, was als Opportunitätskosten von 5.000–10.000 Dollar gerechnet wird; für eine API mit 200 Dollar Monatsumsatz werde wohl niemand so viel zahlen. Es wird betont, dass die anfängliche Nutzung von RapidAPI ein großer Fehler war (20 % Gebühr, unkomfortables UI, ausstehende Zahlungen); stattdessen hätte man lieber mit Paddle ein eigenes Billing-System gebaut. Link zu ZestfulData

    • Vorstellung eines ähnlichen Projekts, das als Interview-Vorbereitungsprojekt mit der ChatGPT API nachgebaut wurde; die größte Schwierigkeit sei gewesen, dass bei Fragen an ChatGPT zur API-Nutzung wegen veralteter Trainingsdaten Beispielcode vorgeschlagen wurde, der nicht mehr funktionierte

    • Der Hinweis, dass in dem Land der schreibenden Person schon die Kosten für Freelancing bei etwa 200 Euro pro Monat liegen, größtenteils durch Sozialabgaben wie Krankenversicherung. Damit sei ein Umsatz von 200 Dollar im Monat wirtschaftlich unmöglich; gefragt wird, wie man mit so niedriger Marge legal arbeiten kann

    • Die Frage, wer eigentlich die Kunden für diese API sind; es habe viele ähnliche Ideen gegeben, aber am Ende wirke es aus Marketingsicht so, als würden Entwickler, die eigene Tools bauen, eine solche API vermutlich gar nicht extern einkaufen

    • Die direkte Frage, wie die ersten Kunden gefunden wurden

  • Jemand interessiert sich ebenfalls sehr dafür, wie man mit technischen Projekten Wert schaffen kann. Das Problem bei diesem Thema sei jedoch, dass erfolgreiche Leute wenig Anreiz hätten, ihre Erfahrungen im Detail zu teilen. Im schlimmsten Fall lade so etwas sogar Konkurrenz ein. Anders als bei Open Source, wo es oft eine wachstumsorientierte Community gibt, sei die Kultur rund um API-Businesses eher verschlossen, weil sie leicht kopierbar seien. Als kürzlich entdeckte Dienstkategorie werden Services genannt, die lange Videodateien, etwa YouTube-Livestreams, automatisch streamen

    • Aus technischer Sicht sei die Fehlannahme naheliegend: „So etwas kann doch jeder bauen.“ Entscheidend sei aber, ob Kunden tatsächlich bereit sind zu zahlen. Zur Hochzeit von Pirate Bay war Musik faktisch kostenlos, aber Spotify schuf durch bessere Bequemlichkeit einen zahlungsbereiten Markt. Auch für Open Source wie ImageMagick gebe es erfolgreiche API-/SaaS-Angebote. Der Grund sei letztlich, dass Menschen und Unternehmen für „Convenience“ zahlen. Ausgangspunkt sollte ein Problem in einem Bereich sein, den man gut kennt und technisch lösen kann; empfohlen wird, in einer Branche oder bei einem Kundenprofil zu starten, das man wirklich versteht und für das man echtes Interesse hat. Da die schreibende Person Entwickler war, hat sie direkt die APIs gebaut, die Entwickler brauchen

    • Jedes Unternehmen habe einige Geheimnisse, die nur wenige kennen, und mit tiefem Branchenwissen könne man analysieren, was Wettbewerber tun. Aber die eigentlichen Hebel, um ein Geschäft groß zu machen, lägen oft in einer schwer sichtbaren „Geheimzutat“. Die schreibende Person ist überzeugt, sofort einen neuen Twist auf ihr bestehendes Geschäft anwenden zu können und innerhalb von zwei Jahren 1 Million Dollar zusätzlichen Jahresumsatz zu erzielen. Gleichzeitig wird offen gesagt, dass bereits mehr als 60 Stunden pro Woche gearbeitet und gut verdient wird und dass das Risiko, durch Teilen der Idee Analysevorsprung zu verlieren, zu groß ist, um daraus mit anderen ein Gemeinschaftsprojekt zu machen

  • Jemand bestreitet seinen Lebensunterhalt mit einer selbstgebauten SMS-&-Telefon-API. Der monatlich wiederkehrende Umsatz liegt bei etwa 500.000 Euro, die Preisgestaltung basiert auf Nutzung (SMS/MMS pro Nachricht, Anrufe pro Minute, virtuelle Nummern mit monatlichem Stückpreis). Der entscheidende Problemlöser sei der programmatische Zugang zu regionalen Mobilfunknetzen in Europa/Schweden. Die ersten Kunden wurden über Offline-Networking gewonnen (Hackathons, Meetups, Kontakte usw.), aber genau das sei auch die größte Hürde beim Skalieren des Geschäfts. Der Weg bis hierhin sei hart gewesen, und selbst jetzt wirke es noch unrealistisch, dass alles so gut funktioniert

    • Neugier auf den verwendeten Tech-Stack; die schreibende Person kenne viele Leute mit Einblick in die schwedische IT-Infrastruktur und habe dazu allerlei Geschichten gehört

    • Direkte Frage, ob man das als einen Twilio-ähnlichen Dienst für regionale europäische Netze verstehen kann

  • Jemand berichtet von der Erfahrung, bei dreamlook.ai in einem Zweierteam eine Fine-Tuning-API für Text-zu-Bild-Modelle betrieben zu haben. Beim Launch vor drei Jahren bestand der Vorteil darin, mit TPUs günstiger und schneller trainieren zu können, aber inzwischen hätten GPUs stark aufgeholt und die Open-Source-Konkurrenz sei intensiver geworden. Der aktuelle Umsatz liegt bei 5.000 Dollar im Monat; da man sich bereits weitgehend zurückgezogen habe, sei das in Ordnung, aber im Vergleich zu vor einem Jahr sei der Umsatz stark gesunken. Nichttechnische Aufgaben seien schwieriger gewesen, und obwohl das Team den Fokus auf Technik und ein API-first-Produkt mochte, gab es Probleme bei Marketing und Sales Support. Inzwischen sei die Person wieder als ML-Entwickler in einem großen Unternehmen tätig und damit zufrieden. Auf den eigenen Business-Aufbau sei man stolz, aber jetzt glücklicher

    • Frage nach konkreten Zahlen zu GPU-Betriebskosten und dem damaligen Budget für den Aufbau

  • Im Zusammenhang mit der Suche nach zahlenden Kunden wird Postman als Entwickler- und API-Vertriebsplattform sowie Netzwerk erwähnt (Postman Explore). Die Abrechnung müsse man selbst übernehmen, aber über das Netzwerk könne man Sichtbarkeit gewinnen

  • Verweis auf den Beitrag Wie ich aus Versehen ein Podcast-API-Business aufgebaut habe, mit dem Hinweis, dort die Geschichte von wenbin lesen zu können