Niemand wordt op een ochtend wakker en beslist om vijftien softwareproducten te bouwen. Zo werkt het niet. Wat werkelijk gebeurt is langzamer, rommeliger en veel minder glamoureus dan elk origin story van een startup zou suggereren. Een probleem verschijnt. Het blijft hangen. De bestaande oplossingen blijken te duur, onvoldoende krachtig, of zo vastgezet in abonnementssystemen dat het gebruik ervan voor een kleine taak voelt als een verhuiswagen huren om één lamp te dragen. Uiteindelijk overschrijdt de frustratie een drempel, en het enige rationele antwoord is iets beters bouwen. Daarna verschijnt nog een probleem. En nog een. Vijftien problemen later is er een volledig platform, en elk enkel product erop laat zich terugtraceren tot een specifiek moment van echte ergernis.

Dit is geen zorgvuldig samengesteld verhaal dat ondernemerschap romantisch doet klinken. Sommige van deze frustraties waren minuscuul. Sommige waren duur. Enkele waren zo verbolgen dat ze hele weekenden konden verpesten. Maar elk enkel geval volgde hetzelfde patroon: een probleem tegenkomen, een oplossing zoeken, de oplossing onvoldoende bevinden, iets beters bouwen. Dat patroon herhaalde zich jaren lang, en het resultaat is yeb.to met zijn eenenveertig API's, achttien SaaS-toepassingen en achtenzestig online tools.

De Eerste Vijf Frustraties Die Alles Hebben Gestart

De ondertitelingstool kwam eerst, en het kwam uit de eenvoudigste van irritaties. Het uitvoeren van YouTube-kanalen gericht op AI-gegenereerde muziek betekende het produceren van videoclips met ingebrande ondertitels. Captions.ai rekende tien euro per maand voor dit privilege, wat redelijk leek totdat maanden met slechts twee of drie video's zich begonnen op te stapelen. Het betalen van een vast abonnement voor een tool die de meeste weken ongebruikt bleef, was het soort verspilling dat stil samengesteld wordt. Het alternatief was voor de hand liggend: een tool bouwen die per verwerkte video betaalt, niet per kalendermaand. Credits vervingen abonnementen, en de besparing werd onmiddellijk.

De vertaaltool groeide uit een ander soort probleem. Machinevertaaldiensten behandelen grote talen competent genoeg, maar zodra je Bulgaars of Servisch nodig hebt, zakt de kwaliteit sterk af. Geslachtsakkoordfouten. Verkeerde werkwoordvervoegingen. Zinnen die technisch vertaald zijn maar klinken alsof ze werden samengesteld door iemand die de taal uit een woordenboek heeft geleerd en deze nooit gesproken heeft gehoord. De bestaande tools behandelden kleinere talen als nagedachten vastgebouwde op motoren die waren geoptimaliseerd voor Engels, Spaans en Frans. Het bouwen van een vertaaldienst die elke taal als een eersteklas burger behandelde, was geen zakelijke beslissing. Het was een respons op het ontvangen van al te veel lachwekkend verkeerde vertalingen van volkomen normale zinnen.

De watermarktool kwam uit het uitgeverijbusiness. Een boek schrijven, het naar PDF converteren, en het binnen dagen na de release op piraterie-sites zien verschijnen, is een uniek soort schending. DRM-oplossingen belooofden bescherming maar leverden ongemak voor legitieme lezers en geen obstakel voor vastberaden piraten. Het besef dat wat auteurs werkelijk nodig hebben niet kopieën voorkomen is maar kopieën traceren, leidde tot een watermarksysteem dat elke gedistribueerde kopie individueel identificeerbaar maakt. Het probleem was persoonlijk: een boek werd gepirateerd. De oplossing werd een product.

De valutaconverter werd geboren in de kloof tussen geadverteerde wisselkoersen en werkelijk ontvangen bedragen. Elke internationale transfer betrok een ritueel van het controleren van de midmarkt-koers, vervolgens het zien van het ontvangen bedrag aanzienlijk lager binnenkomen vanwege verborgen kosten, opslag percentages en conversie-spreiden die platforms nooit openlijk weergaven. Het bouwen van een valutahulpmiddel dat de werkelijke koers naast wat Wise, Revolut, PayPal en Western Union werkelijk zouden doorberekenen, was een directe respons op het ontvangen van al te veel transfers waarbij de belofte "zonder kosten" in een drie procent spreiding verdampte.

Het linkbeheerplatform pakte een probleem aan dat in 2026 niet zou moeten bestaan. Bitly rekent vijfendertig dollar per maand voor merked korte links. Vijfendertig dollar. Voor een dienst waarvan de kernfunctie een lange URL vervangen door een korte is. De technische complexiteit van URL-verkorting is minimaal. De infrastructuurkosten zijn verwaarloosbaar. Toch convergeerde de markt op prijzen die aannemen dat elke gebruiker een marketingafdeling met een bedrijfsbudget is. Het bouwen van LinkHub als alternatief op basis van credits betekende dat het maken van een korte link een fractie van een cent kost, en de maandelijkse rekening is exact evenredig aan het werkelijke gebruik.

De Problemen Die Technisch Werden

De screenshot-API begon met uptime-monitoring. Controleren of een website omhoog of omlaag is, lijkt triviaal eenvoudig totdat de site JavaScript-rendering, lazy loading of single-page application-architectuur gebruikt. Een traditioneel HTTP-verzoek ziet een lege pagina of een laadspinner en rapporteert dat alles prima in orde is, terwijl werkelijke bezoekers een kapotte ervaring zien. Het nemen van een echte browserscreenshot van de weergegeven pagina vertelt de waarheid op een manier die HTTP-statuscodes nooit kunnen. Die behoefte aan visuele verificatie ontwikkelde zich tot een volledige screenshot-API met geplande captures, visuele diff-detectie en OCR-tekstextractie. Vijf uur onopgemerkte downtime op een klantproject was het specifieke incident dat alles begon.

Botdetectie groeide uit een meer alarmerend ontdekking. Het controleren van analysen op een webproject en het vinden van tien miljoen bezoeken die nul conversies, nul engagement en nul scroll-diepte genereerden. Tien miljoen bezoeken van bots die voorgaven echte browsers te zijn, die metriek opzwepten, gegevens scheefzetten en elke zakelijke beslissing op basis van dat verkeer fundamenteel verkeerd maakt. De bestaande botdetectieoplossingen waren enterprise-producten geprijsd voor bedrijven met beveiligingsbudgetten. Het bouwen van een detectie-API die botverkeer op aanvraagniveau kon identificeren, met behulp van apparaatvingerafdrukken en gedragsanalyse, was een directe respons op het besef dat een aanzienlijk percentage van webverkeer fictief is.

Het uptime-monitoringhulpmiddel vulde de kloof die de screenshot-API onthulde. Weten dat een site visueel kapot is, is nuttig, maar het moment weten waarop het breekt, is essentieel. Bestaande uptime-monitors controleerden eindpunten en rapporteerden HTTP-codes, waardoor de hele categorie fouten werd gemist waarbij de server met een 200-statuscode reageert maar de paginainhoud verkeerd, ontbrekend of beschadigd is. Het combineren van uptime-controles met periodieke screenshots creëerde een monitoringsysteem dat fouten vangt die onzichtbaar zijn voor traditionele tools.

De Problemen Die Klein Voelden Maar Niet Waren

QR-codegenerering lijkt een opgelost probleem te moeten zijn. Duizenden gratis generatoren bestaan online. Maar probeer een QR-code te genereren met een specifiek kleurenschema, ingebed logo, aangepast foutcorrectieniveau en tracking-analysen, en de gratis tools onthullen hun grenzen bijna onmiddellijk. De QR-codegenerator op yeb.to bestaat omdat elk gratis alternatief hetzij een eenvoudig zwart-wit vierkant zonder aanpassingsmogelijkheden produceerde, hetzij een maandelijks abonnement voor functies die slechts penningen per gegenereerde code zouden moeten kosten.

De PDF-tools kwamen voort uit documentworkflowwrijving. Het samenvoegen van drie PDF's mag niet het downloaden van desktopsoftware of het uploaden van gevoelige documenten naar een willekeurige website met onduidelijke privacybeleid vereisen. Het splitsen van een PDF, het comprimeren ervan, het converteren naar afbeeldingen, of het extraheren van tekst ervan, moeten bewerkingen zijn zo eenvoudig als op een knop klikken. Elk PDF-hulpmiddel op het platform bestaat omdat een specifieke documenttaak nodig was, de beschikbare opties onvoldoende waren, en het bouwen van het hulpmiddel minder tijd kostte dan doorgaan met het omzeilen van de onvoldoendheid.

De GeoIP-opzoekdienst begon als een onderdeel voor analysen maar werd zijn eigen product toen de noodzaak om bezoekerslocaties over verschillende projecten heen herhaaldelijk te identificeren opdaagde. Commerciële GeoIP-databases berekenen jaarlijkse licentiekosten. De API verpakt vrij beschikbare gegevens in een indeling die onmiddellijk kan worden bevraagd, en de creditkosten per opzoeking zijn laag genoeg zodat zelfs toepassingen met hoog volume zich dit zonder onderhandeling over enterprise-contracten kunnen veroorloven.

De WordPress-analyseplugin bracht verschillende van deze frustraties samen. Het uitvoeren van WordPress-sites betekende analysen nodig die echte bezoekers van bots konden onderscheiden, geografische oorsprong konden identificeren en apparaattypen konden detecteren. Google Analytics behandelt sommige hiervan maar begraft de nuttige gegevens onder lagen van interfacecomplexiteit en steeds agressievere gegevenssample. De WordPress-plugin gebruikt internalaan drie yeb.to-API's, wat op zichzelf een demonstratie is van hoe producten die uit echte behoeften zijn voortgekomen, op natuurlijke wijze verbonden raken in iets groter dan enig afzonderlijk hulpmiddel.

Het Patroon Dat Alle Vijftien Verbindt

Het bekijken van de volledige lijst met producten en het terugtraceren van elk product naar zijn oorsprong onthult een patroon dat zo consistent is dat het bijna formulaïsch voelt. Elk product begon met een persoonlijke ontmoeting met een probleem. Geen marktonderzoeksbevinding, geen concurrentieanalyse, geen trendrapport. Een echt, specifiek, vervelend probleem dat een oplossing eiste. De ondertitelingstool bestaat omdat tien euro per maand voor drie video's verkeerd voelde. De vertaler bestaat omdat Bulgaars steeds verminkt werd. De watermarktool bestaat omdat een boek werd gepirateerd. De valutaconverter bestaat omdat verborgen kosten internationale transfers bleven opeten. De linkbeheerder bestaat omdat vijfendertig dollar voor URL-verkorting absurd is.

Producten gebouwd uit persoonlijke frustratie hebben een structureel voordeel ten opzichte van producten gebouwd uit marktkans. De oprichter begrijpt het probleem op een cellulair niveau omdat zij ermee hebben geleefd. Ze weten welke functies belangrijk zijn en welke decoratie. Ze weten het exacte moment waarop een bestaande oplossing faalt omdat zij die faling zelf hebben ervaren. Ze bouwen voor het gebruiksscenario dat zij kennen, niet voor het gebruiksscenario dat zij zich voorstellen.

Het nadeel is dat deze benadering producten op een onvoorspelbaar schema produceert. Er is geen routekaart aangestuurd door driemaandelijkse planning. Een nieuw product verschijnt wanneer een nieuwe frustratie de drempel overschrijdt. Soms verschijnen drie producten in één enkel kwartaal. Soms gaan zes maanden voorbij met alleen verfijningen van bestaande tools. De ontwikkelingstijdlijn volgt de vorm van echte problemen, niet de vorm van een bedrijfsplan.

Vijftien frustraties werden vijftien productlijnen, die uitbreidde naar eenenveertig API's en achtenzestig tools. Het creditsysteem bindt alles samen zodat een gebruiker die met ondertitels begint watermerking, linktracking, vertaling en valutaconversie kan ontdekken zonder nieuwe accounts te maken of nieuwe abonnementen te kopen. Het ecosysteem groeide organisch omdat de problemen die het oplost, organisch met elkaar verbonden zijn. Creators die video's maken, hebben ook ondertitels nodig. Auteurs die boeken schrijven, hebben ook watermerken nodig. Bedrijven die links verkorten, hebben ook QR-codes nodig. De verbindingen werden nooit gepland. Ze werden ontdekt, één ergernis tegelijk.

Veelgestelde Vragen

Zijn alle vijftien producten door één persoon gebouwd?

Ja. Elke API, SaaS-toepassing en online tool op yeb.to werd ontworpen, ontwikkeld en onderhouden door één ontwikkelaar. De tech stack is het toepassingskader, browserautomatisering voor rendering en AI-modellen voor audiotranscriptie.

Waarom zijn er zoveel verschillende producten in plaats van één gericht gereedschap?

Elk product pakt een specifieke frustratie aan die persoonlijk was tegengekomen. De variatie weerspiegelt de breedte van problemen die een werkende ontwikkelaar en contentmaker over verschillende domeinen heen tegenkomt. Het gedeelde creditsysteem en de infrastructuur betekenen dat het onderhouden van meerdere producten aanzienlijk efficiënter is dan het zou zijn als elk product op afzonderlijke infrastructuur draaide.

Gebruiken alle producten hetzelfde creditsysteem?

Ja. Één creditsaldo werkt over alle eenenveertig API's, achttien SaaS-apps en achtenzestig tools. Tien dollar koopt honderd credits, en bulkaankopen verlagen de kostprijs per credit verder. Credits vervallen nooit en worden alleen afgetrokken wanneer een service werkelijk wordt gebruikt.

Welk product was het moeilijkst om te bouwen?

De screenshot-API vereiste de meest complexe infrastructuur omdat deze headless Chromium-browsers in containers uitvoert. Het beheren van browserinstanties, het behandelen van JavaScript-zware pagina's, het implementeren van OCR en het bouwen van visuele diff-detectie betrokken aanzienlijk meer onderdelen dan tekstverwerking of API-wrapperhulpmiddelen.

Kan iemand slechts één product gebruiken zonder de anderen nodig te hebben?

Absoluut. Elk product werkt onafhankelijk. Het creditsysteem is gedeeld, maar er is geen vereiste om meerdere services te gebruiken. Iemand die alleen ondertitels nodig heeft, zal nooit met het watermark of valutahulpmiddel communiceren tenzij zij dit kiezen.

Wat gebeurt er wanneer een nieuwe frustratie verschijnt?

Het wordt een nieuw product. Het ontwikkelingproces is sinds het eerste hulpmiddel niet veranderd. Een probleem wordt geïdentificeerd, bestaande oplossingen worden geëvalueerd, en als zij tekortkomen, wordt een nieuw hulpmiddel gebouwd. Het platform groeit in het tempo van echte problemen, niet in het tempo van geplande productlanceringen.