Jedes Produkt, das ich gebaut habe, entstand aus etwas, das mich nervte – und hier sind alle fünfzehn Probleme

Niemand wacht morgens auf und beschließt, fünfzehn Softwareprodukte zu bauen. So funktioniert es nicht. Was tatsächlich passiert, ist langsamer, unordentlicher und weit weniger glamourös als jede Startup-Gründungsgeschichte vermuten lässt. Ein Problem taucht auf. Es gärt. Die bestehenden Lösungen stellen sich als überbewertet, unterentwickelt oder in so fest verankerte Abonnementmodelle verstrickt heraus, dass die Nutzung für eine untergeordnete Aufgabe sich wie das Mieten eines Umzugswagens für eine einzelne Lampe anfühlt. Schließlich übersteigt die Frustration einen Schwellenwert, und die einzige rationale Reaktion ist, etwas Besseres zu bauen. Dann taucht ein anderes Problem auf. Und noch eins. Fünfzehn Probleme später gibt es eine ganze Plattform, und jedes einzelne Produkt darauf lässt sich auf einen spezifischen Moment echter Frustration zurückführen.

Dies ist keine sorgfältig zusammengestellte Erzählung, die Unternehmertum romantisch wirken lassen soll. Einige dieser Frustrationen waren winzig. Einige waren kostspielig. Ein paar waren infuriierend genug, um ganze Wochenenden zu verderben. Aber jede Einzelne folgte dem gleichen Muster: ein Problem begegnen, nach einer Lösung suchen, die Lösung für unzureichend befinden, eine bessere bauen. Dieses Muster wiederholte sich über Jahre hinweg, und das Ergebnis ist yeb.to mit seinen einundvierzig APIs, achtzehn SaaS-Anwendungen und achtundsechzig Online-Tools.

Die ersten fünf Frustrationen, die alles in Gang setzten

Das Untertitel-Tool kam zuerst, und es entstand aus der einfachsten aller Ärgernisse. Das Führen von YouTube-Kanälen mit KI-generierter Musik bedeutete die Herstellung von Musikvideos mit eingebrannten Untertiteln. Captions.ai verlangte zehn Euro pro Monat für dieses Privileg, was vernünftig schien, bis die Monate mit nur zwei oder drei Videos sich zu häufen begannen. Für ein Tool, das die meisten Wochen ungenutzt blieb, eine Pauschalabmeldung zu zahlen, war die Art von Verschwendung, die sich stillschweigend summiert. Die Alternative war offensichtlich: ein Tool zu bauen, das pro verarbeitetem Video abrechnet, nicht pro Monat Kalenderzeit. Credits ersetzten Abonnements, und die Einsparungen wurden sofort deutlich.

Das Übersetzungs-Tool entstand aus einer anderen Art von Problem. Maschinelle Übersetzungsdienste handhaben größere Sprachen kompetent genug, aber sobald man Bulgarisch oder Serbisch benötigt, fällt die Qualität steil ab. Geschlechtsvereinbarungs-Fehler. Falsche Verbkonjugationen. Sätze, die technisch übersetzt sind, aber klingen, als wären sie von jemandem zusammengesetzt worden, der die Sprache aus einem Wörterbuch gelernt hat und sie nie gesprochen hat. Die bestehenden Tools behandelten kleinere Sprachen als Nachgedanken, die auf Engines aufgesetzt sind, die für Englisch, Spanisch und Französisch optimiert sind. Ein Übersetzungsdienst, der jede Sprache als Bürger der ersten Klasse behandelt, war keine Geschäftsentscheidung. Es war eine Reaktion auf eine Übertragung zu vieler lächerlich falscher Übersetzungen gewöhnlicher Sätze.

Das Wasserzeichen-Tool entstand aus dem Verlagswesen. Ein Buch zu schreiben, es in PDF zu konvertieren und dann zu sehen, wie es Tage nach der Veröffentlichung auf Piraterie-Websites auftaucht, ist eine einzigartige Art der Verletzung. DRM-Lösungen versprachen Schutz, lieferten aber Unannehmlichkeiten für legitime Leser und null Hindernis für entschlossene Piraten. Die Erkenntnis, dass das, was Autoren tatsächlich brauchen, nicht die Kopienprävention ist, sondern die Kopien-Verfolgung, führte zu einem Wasserzeichen-System, das jede verteilte Kopie individuell identifizierbar macht. Das Problem war persönlich: ein Buch wurde gepiratet. Die Lösung wurde zu einem Produkt.

Der Währungsumrechner wurde in der Lücke zwischen ausgeschriebenen Wechselkursen und tatsächlich erhaltenen Beträgen geboren. Jede internationale Überweisung beinhaltete das Ritual, den Mid-Market-Kurs zu überprüfen, dann den erhaltenen Betrag noticeably niedriger ankommen zu sehen, weil von versteckten Gebühren, Aufschlagsprozentsätzen und Umrechnungsspreads, die Plattformen nie deutlich anzeigte. Der Bau eines Währungs-Tools, das den echten Kurs neben dem anzeigt, was Wise, Revolut, PayPal und Western Union tatsächlich berechnen würden, war eine direkte Reaktion auf zu viele Überweisungen, bei denen das «gebührenfreie» Versprechen in einer dreiprozentigen Spanne verdampfte.

Die Link-Verwaltungsplattform adressierte ein Problem, das 2026 nicht existieren sollte. Bitly verlangt fünfunddreißig Dollar pro Monat für Markenkurzlinks. Fünfunddreißig Dollar. Für einen Dienst, dessen Kernfunktion darin besteht, eine lange URL durch eine kurze zu ersetzen. Die technische Komplexität der URL-Verkürzung ist minimal. Die Infrastrukturkosten sind vernachlässigbar. Doch irgendwie konvergierte der Markt auf einer Preisgestaltung, die davon ausgeht, dass jeder Benutzer eine Marketingabteilung mit einem Unternehmensbudget ist. Der Bau von LinkHub als kreditbasierte Alternative bedeutete, dass das Erstellen eines Kurzlinks einen Bruchteil eines Cents kostet, und die monatliche Rechnung ist genau proportional zur tatsächlichen Nutzung.

Die Probleme, die technisch wurden

Die Screenshot-API begann mit Uptime-Monitoring. Die Überprüfung, ob eine Website oben oder unten ist, scheint trivial einfach zu sein, bis die Website JavaScript-Rendering, Lazy Loading oder Single-Page-Application-Architektur verwendet. Eine traditionelle HTTP-Anfrage sieht eine leere Seite oder einen Lade-Spinner und meldet alles als gut, während tatsächliche Besucher eine kaputte Erfahrung sehen. Das Erstellen eines echten Browser-Screenshots der gerenderten Seite sagt die Wahrheit auf eine Weise, auf die HTTP-Statuscodes nie können. Dieses Bedürfnis nach visueller Überprüfung entwickelte sich zu einer vollständigen Screenshot-API mit geplanten Erfassungen, visueller Diff-Erkennung und OCR-Textextraktion. Fünf Stunden unerkannter Ausfallzeit in einem Kundenprojekt war der spezifische Vorfall, der alles in Gang setzte.

Bot-Erkennung entstand aus einer alarmierenderen Entdeckung. Überprüfung der Analytik in einem Webprojekt und Feststellung von zehn Millionen Besuchen, die null Konversionen, null Engagement und null Scroll-Tiefe generierten. Zehn Millionen Besuche von Bots, die echte Browser vortäuschten, Metriken aufblähten, Daten verzerrt und jede auf diesem Verkehr basierende Geschäftsentscheidung grundlegend falsch machten. Die bestehenden Bot-Erkennungslösungen waren Unternehmensprodukte, die für Unternehmen mit Sicherheitsbudgets bepreist wurden. Der Bau eines Erkennungs-APIs, das Bot-Verkehr auf Request-Ebene mithilfe von Geräte-Fingerprinting und Verhaltensanalyse identifizieren konnte, war eine direkte Reaktion auf die Erkenntnis, dass ein signifikanter Prozentsatz des Webverkehrs fiktiv ist.

Das Uptime-Überwachungs-Tool füllte die Lücke, die die Screenshot-API enthüllte. Zu wissen, dass eine Site visuell kaputt ist, ist nützlich, aber den Moment zu kennen, in dem sie bricht, ist unverzichtbar. Bestehende Uptime-Monitore überprüften Endpunkte und berichteten HTTP-Codes, was die gesamte Kategorie von Ausfällen vermisst, bei denen der Server mit einem 200-Statuscode antwortet, aber der Seiteninhalte falsch, fehlend oder beschädigt ist. Das Kombinieren von Uptime-Checks mit periodischen Screenshots hat ein Überwachungssystem geschaffen, das Fehler erkennt, die traditionelle Tools unsichtbar machen.

Die Probleme, die klein wirkten, es aber nicht waren

Die QR-Code-Generierung scheint ein gelöstes Problem sein zu sollte. Tausende von kostenlosen Generatoren existieren online. Aber versuchen Sie, einen QR-Code mit einem spezifischen Farbschema, eingebettetem Logo, benutzerdefiniertem Fehlerkorrektur-Level und Tracking-Analytik zu generieren, und die kostenlosen Tools zeigen ihre Grenzen fast sofort. Der QR-Code-Generator auf yeb.to existiert, weil jede kostenlose Alternative entweder ein einfaches schwarzes und weißes Quadrat ohne Anpassung oder ein monatliches Abonnement für Features verlangte, das Pennies pro generiertem Code kosten sollte.

Die PDF-Tools entstand aus Reibung im Dokument-Workflow. Das Zusammenführen von drei PDFs sollte nicht das Herunterladen von Desktop-Software oder das Hochladen von sensiblen Dokumenten auf eine zufällige Website mit unklar Datenschutzrichtlinien erfordern. Das Teilen einer PDF, das Komprimieren, das Konvertieren in Bilder oder das Extrahieren von Text sollte einfache Operationen sein wie das Klicken auf einen Button. Jedes PDF-Tool auf der Plattform existiert, weil eine spezifische Dokument-Aufgabe benötigt wurde, die verfügbaren Optionen unzureichend waren, und das Bauen des Tools weniger Zeit dauerte als die Fortsetzung der Arbeit um die Unzulänglichkeit.

Der GeoIP-Lookup-Service begann als Komponente für Analytik, wurde aber sein eigenes Produkt, als die Notwendigkeit, Besucherstandorte zu identifizieren, wiederholt über verschiedene Projekte auftauchte. Kommerzielle GeoIP-Datenbanken berechnen jährliche Lizenzgebühren. Die API wickelt frei verfügbare Daten in ein Format, das sofort abgefragt werden kann, und die Gutschrift pro Lookup ist niedrig genug, dass auch hochvolumige Anwendungen es sich ohne Verhandlung von Unternehmensverträgen leisten können.

Das WordPress-Analyse-Plugin band mehrere dieser Frustrationen zusammen. Das Führen von WordPress-Sites bedeutete die Notwendigkeit von Analysen, die echte Besucher von Bots unterscheiden, geografische Ursprünge identifizieren und Gerätetypen erkennen können. Google Analytics behandelt etwas davon, vergräbt aber die nützlichen Daten unter Schichten von Oberflächenkomplexität und zunehmend aggressivem Daten-Sampling. Das WordPress-Plugin verwendet intern drei yeb.to-APIs, was selbst eine Demonstration ist, wie Produkte, die aus echten Bedürfnissen gebaut werden, sich natürlich in etwas Größeres als jedes einzelne Tool verbinden.

Das Muster, das alle fünfzehn verbindet

Das Betrachten der vollständigen Liste von Produkten und das Zurückverfolgen jedes einzelnen zu seinem Ursprung offenbart ein Muster, das so konsistent ist, dass es sich fast formulisch anfühlt. Jedes Produkt begann mit einer persönlichen Begegnung mit einem Problem. Nicht ein Marktforschungsergebnis, nicht eine Konkurrenzanalyse, nicht ein Trendbericht. Ein echtes, spezifisches, nerviges Problem, das eine Lösung verlangte. Das Untertitel-Tool existiert, weil zehn Euro pro Monat für drei Videos falsch wirkte. Der Übersetzer existiert, weil Bulgarisch immer wieder zerhackt wurde. Das Wasserzeichen-Tool existiert, weil ein Buch gepiratet wurde. Der Währungsumrechner existiert, weil versteckte Gebühren internationale Transfers aufzehrten. Der Link-Manager existiert, weil fünfunddreißig Dollar für die URL-Verkürzung absurd sind.

Produkte, die aus persönlicher Frustration gebaut werden, haben einen strukturellen Vorteil gegenüber Produkten, die aus Marktmöglichkeiten gebaut werden. Der Gründer versteht das Problem auf zellularer Ebene, weil sie damit gelebt haben. Sie wissen, welche Features wichtig sind und welche Dekoration sind. Sie wissen den genauen Moment, in dem eine bestehende Lösung fehlschlägt, weil sie diesen Fehler persönlich erlebt haben. Sie bauen für den Use-Case, den sie kennen, nicht für den Use-Case, den sie sich vorstellen.

Der Nachteil ist, dass dieser Ansatz Produkte auf unvorhersehbarem Plan erzeugt. Es gibt keinen Fahrplan, der durch vierteljährliche Planung angetrieben wird. Ein neues Produkt taucht auf, wenn eine neue Frustration den Schwellenwert überschreitet. Manchmal entstehen drei Produkte in einem einzigen Quartal. Manchmal vergehen sechs Monate nur mit Verfeinerungen an bestehenden Tools. Der Entwicklungszeitplan folgt der Form echter Probleme, nicht der Form eines Geschäftsplans.

Fünfzehn Frustrationen wurden zu fünfzehn Produktlinien, die sich in einundvierzig APIs und achtundsechzig Tools erweiterten. Das Kreditsystem bindet alles zusammen, damit ein Benutzer, der mit Untertiteln beginnt, Wasserzeichen, Link-Tracking, Übersetzung und Währungsumrechnung entdecken kann, ohne neue Konten zu erstellen oder neue Abonnements zu kaufen. Das Ökosystem wuchs organisch, weil die Probleme, die es löst, organisch verbunden sind. Creator, die Videos machen, brauchen auch Untertitel. Autoren, die Bücher schreiben, brauchen auch Wasserzeichen. Unternehmen, die Links verkürzen, brauchen auch QR-Codes. Die Verbindungen waren nie geplant. Sie wurden entdeckt, ein Ärgernis nach dem anderen.

Häufig gestellte Fragen

Sind alle fünfzehn Produkte von einer Person gebaut?

Ja. Jede API, SaaS-Anwendung und jedes Online-Tool auf yeb.to wurde von einem einzigen Entwickler entworfen, entwickelt und gewartet. Der Tech-Stack ist das Application-Framework, Browser-Automatisierung für das Rendering und KI-Modelle für die Audio-Transkription.

Warum gibt es so viele verschiedene Produkte statt eines fokussierten Tools?

Jedes Produkt adressiert eine spezifische Frustration, die persönlich erlebt wurde. Die Vielfalt spiegelt die Breite der Probleme wider, mit denen ein arbeitender Entwickler und Content Creator über verschiedene Domänen hinweg konfrontiert ist. Das gemeinsame Kreditsystem und die Infrastruktur bedeuten, dass die Wartung mehrerer Produkte erheblich effizienter ist, als wenn jedes auf separater Infrastruktur laufen würde.

Nutzen alle Produkte das gleiche Kreditsystem?

Ja. Ein Guthaben funktioniert über alle einundvierzig APIs, achtzehn SaaS-Apps und achtundsechzig Tools hinweg. Zehn Dollar kaufen einhundert Credits, und Mengenrabätte reduzieren die Pro-Credit-Kosten weiter. Credits verfallen nie und werden nur abgezogen, wenn ein Service tatsächlich verwendet wird.

Welches Produkt war am schwierigsten zu bauen?

Die Screenshot-API erforderte die komplexeste Infrastruktur, weil sie headless Chromium-Browser in Containern ausführt. Das Verwalten von Browser-Instanzen, das Handhaben von JavaScript-schweren Seiten, die Implementierung von OCR und die Erstellung der visuellen Diff-Erkennung beteiligten erheblich mehr bewegliche Teile als Text-Verarbeitung oder API-Wrapper-Tools.

Kann jemand nur ein Produkt nutzen, ohne die anderen zu brauchen?

Absolut. Jedes Produkt funktioniert unabhängig. Das Kreditsystem ist gemeinsam, aber es gibt keine Anforderung, mehrere Services zu nutzen. Jemand, der nur Untertitel braucht, wird nie mit den Wasserzeichen- oder Währungs-Tools interagieren, es sei denn, er entscheidet sich dafür.

Was passiert, wenn eine neue Frustration auftaucht?

Es wird zu einem neuen Produkt. Der Entwicklungsprozess hat sich seit dem ersten Tool nicht verändert. Ein Problem wird identifiziert, bestehende Lösungen werden evaluiert, und wenn sie zu kurz greifen, wird ein neues Tool gebaut. Die Plattform wächst in dem Tempo echter Probleme, nicht in dem Tempo geplanter Produktstarts.