Alle Produktene Jeg Bygde Startet Med Noe Som Irriterte Meg Og Her Er Alle Femten Problemene
Ingen våkner opp en morgen og bestemmer seg for å bygge femten programvareprodukter. Slik fungerer det ikke. Det som faktisk skjer er langsommere, rotete, og langt mindre glamorøst enn noen oppstarts-opprinnelseshistorie ville antyde. Et problem dukker opp. Det varer. De eksisterende løsningene viser seg å være overpriste, underpowered, eller så låst inn i abonnementsmodeller at bruk av dem for en mindre oppgave føles som å leie en flyttebil for å bære en enkelt lampe. Til slutt krysser frustrasjonen en terskel, og det eneste rasjonelle svaret er å bygge noe bedre. Så dukker et annet problem opp. Og et til. Femten problemer senere, er det en hele plattformen, og hvert enkelt produkt på den spores tilbake til et spesifikt øyeblikk av ekte irritasjon.
Dette er ikke en nøye kuratert fortelling designet for å få gründerskap til å høres romantisk ut. Noen av disse frustrasjionene var tiny. Noen var dyre. Noen få var så irriterende at de ødela hele helger. Men hver eneste en fulgte samme mønster: møt et problem, søk etter en løsning, finn løsningen utilstrekkelig, bygg en bedre. Det mønsteret gjentok seg i år, og resultatet er yeb.to med sin 41 APIer, 18 SaaS-applikasjoner, og 68 nettbaserte verktøy.
De Første Fem Frustrasjionene Som Startet Alt
Bildeoverskrift-verktøyet kom først, og det kom fra den enkleste av irritasjoner. Kjøring av YouTube-kanaler fokusert på AI-generert musikk betød produksjon av lyrikkvideaoer med innbrent undertekster. Captions.ai belastet ti euro i måneden for dette privilegiet, som føltes rimelig til månedene med bare to eller tre videoer begynte å stable seg opp. Betaling av et fast abonnement for et verktøy som var ubrukt de fleste ukene var den slags avfall som akkumuleres stille. Alternativet var åpenbart: bygge et verktøy som belaster per video behandlet, ikke per måned med kalendertid. Kreditter erstattet abonnementer, og sparingene ble umiddelbare.
Oversettelsesverktøyet vokste fra en annen type problem. Maskinoversettelsestjenester håndterer større språk kompetent nok, men fra det øyeblikket du trenger bulgarsk eller serbisk, faller kvaliteten av en klippe. Kjønns-samsvar feil. Feil verb konjugasjoner. Setninger som er teknisk oversatt men høres ut som de var satt sammen av noen som lærte språket fra en ordbok og aldri hørte det talt. De eksisterende verktøyene behandlet mindre språk som ettertanker boltet på motorer optimalisert for engelsk, spansk og fransk. Bygning av en oversettelsestjeneste som behandlet alle språk som borgere av første klasse var ikke en forretningsbeslutning. Det var et svar på mottak av en gangs altfor mange latterlig feil oversettelser av helt ordinære setninger.
Vannmerkeverktøyet kom fra publisering. Skriving av en bok, konvertering til PDF, og se det dukke opp på piratkopiering nettsteder innenfor dager fra utgivelse er en unik type brudd. DRM-løsninger lovte beskyttelse men leverte ulempe for legitime lesere og null hindring for besluttede pirater. Innsikten at det forfattere faktisk trenger er ikke kopieringsforebygging men kopieringssporing ledet til et vannmerkesystem som gjør hver distribuert kopi individuelt identifiserbar. Problemet var personlig: en bok ble piratkopieret. Løsningen ble et produkt.
Valutakonverterer ble født i gapet mellom annonserte valutakurser og faktisk mottatte beløp. Hver internasjonal overføring involverte en ritual å sjekke midtmarkedskursen, så se det mottatte beløpet kommer inn merkbart lavere på grunn av skjulte gebyrer, markup-prosenter, og konverteringsspreader som plattformer aldri viste på forhånd. Bygning av et valutaverktøy som viser realraten sammen med hva Wise, Revolut, PayPal, og Western Union faktisk ville belaste var et direkte svar på mottak av en gang altfor mange overføringer hvor "avgiftsfri" løftet fordampet i en tre prosents spredning.
Koblingsadministrasjonsplattformen behandlet et problem som ikke burde eksistere i 2026. Bitly belaster 35 dollar i måneden for merkede korte lenker. Trettifem dollar. For en tjeneste hvis kjernefunction er erstatning av en lang URL med en kort. Den tekniske kompleksiteten til URL-forkorting er minimal. Infrastrukturkostnaden er ubetydelig. Likevel konvergerte markedet på prissetting som antar at hver bruker er en markedsføringsdepartement med et bedriftsbudsjett. Bygning av LinkHub som et kredittbasert alternativ betød at opprettelse av en kort lenke koster en brøkdel av en cent, og månedsfakturaen er nøyaktig proporsjonal med faktisk bruk.
Problemene Som Ble Tekniske
Screenshot-APIen startet med oppetidsovervåking. Sjekking av hvorvidt en nettside var oppe eller nede virker trivielt enkelt til stedet bruker JavaScript-rendering, lazy loading, eller enkel side-applikasjonarkitektur. En tradisjonell HTTP-forespørsel ser en tom side eller en ladespinner og rapporterer alt som bra, mens faktiske besøkende ser en ødelagt opplevelse. Tar en reell nettleser skjermbilde av den gjengitte siden forteller sannheten på en måte HTTP-statuskoder aldri kan. Det behovet for visuell verifisering utviklet seg til en full skjermbildeAPI med planlagte opptak, visuell diff-deteksjon, og OCR tekstekstraksjon. Fem timer uoppdaget nedetid på et klientprosjekt var den spesifikke hendelsen som startet hele greia.
Bot-deteksjon vokste fra en mer alarming oppdagelse. Sjekking av analyser på et nettprosjekt og finning av ti millioner besøk som genererte null konversjoner, null engasjement, og null scroll-dybde. Ti millioner besøk fra bots som utga seg for å være ekte nettlesere, oppblåsing av målinger, skjeve data, og gjøring av hver forretningsbeslutning basert på trafikken fundamentalt feil. De eksisterende bot-deteksjonsløsningene var bedriftsprodukter priset for selskaper med sikkerhetsbudsjetter. Bygning av en deteksjons-API som kunne identifisere bot-trafikk på forespørslesnivå, ved bruk av enhetsfingerkryptering og atferdsmessig analyse, var et direkte svar på innsikten at en betydelig prosentandel av netttrafikken er fiktiv.
Oppetidsovervåkingsverktøyet fylte gapet som screenshot-APIen avslørte. Å vite at et sted er visuelt ødelagt er nyttig, men å vite øyeblikket det brytes er essensielt. Eksisterende oppetidsmonitorer sjekket endepunkter og rapporterte HTTP-koder, som går glipp av hele kategorien feil hvor serveren responderer med en 200-statuskode men sideinnholdet er feil, manglende, eller korrupt. Kombinering av oppetidskontroller med periodiske skjermbilder skapte et overvåkingssystem som fanger feil usynlig for tradisjonelle verktøy.
Problemene Som Føltes Små Men Var Ikke
QR-kodegenerering virker som det burde være et løst problem. Tusenvis av gratis generatorer finnes på nettet. Men prøv å generere en QR-kode med et spesifikt fargeskjema, innebygd logo, tilpasset feilkorreksjonsnivå, og sporing av analyser, og de gratis verktøyene avslører sine grenser nesten umiddelbart. QR-kodegeneratoren på yeb.to finnes fordi alle gratis alternativer produserte enten en ren svart og hvit kvadrat uten tilpassing eller krevde et månedlig abonnement for funksjoner som burde koste øre per kode generert.
PDF-verktøyene kom fra friktionsarbeidsflyten. Fletning av tre PDF-er burde ikke kreve nedlasting av stationær programvare eller opplasting av sensitive dokumenter til et tilfeldig nettsted med uklar personvernpolitikk. Splitting av en PDF, komprimering, konvertering til bilder, eller tekstekstraksjon fra det burde være operasjoner så enkle som å klikke på en knapp. Hvert PDF-verktøy på plattformen finnes fordi en spesifikk dokumentoppgave var nødvendig, de tilgjengelige alternativene var utilstrekkelige, og bygning av verktøyet tok mindre tid enn fortsatte å arbeide rundt utilstrekkeligene.
GeoIP-oppslagstjenesten startet som en komponent for analyser men ble sitt eget produkt når behovet for å identifisere besøkendelokasjoner dukket opp gjentatte ganger på tvers av forskjellige prosjekter. Kommersielle GeoIP-databaser belaster årlige lisensieringgebyrer. APIen pakker fritt tilgjengelig data inn i et format som kan spørres øyeblikkelig, og kreditt-kostnaden per oppslag er lav nok til at selv høyt volum-applikasjoner kan ha råd uten å forhandle bedriftskontrakter.
WordPress-analyser plugin bandt flere av disse frustrasjionene sammen. Kjøring av WordPress-nettsteder betød behov for analyser som kunne skille ekte besøkende fra bots, identifisere geografiske opprinnelser, og oppdage enhetstypene. Google Analytics håndterer noe av dette men graver nyttige data under lag av grensesnittskompleksitet og stadig mer aggressiv datasampling. WordPress-plugin bruker tre yeb.to APIer internt, noe som i seg selv er en demonstrasjon av hvordan produkter bygget fra ekte behov naturlig forbindes til noe større enn noe enkelt verktøy.
Mønsteret Som Forbinder Alle Femten
Ser på hele listen over produkter og sporing av hver enkelt tilbake til sin opprinnelse avslører et mønster så konsistent det nesten føles formulaisk. Hvert produkt startet med en personlig møte med et problem. Ikke en markedsundersøkelsesfunn, ikke en konkurrentanalyse, ikke en trendrapport. Et ekte, spesifikt, irriterende problem som krevde en løsning. Bildeoverskrift-verktøyet finnes fordi ti euro i måneden for tre videoer føltes galt. Translatøren finnes fordi bulgarsk holdt på å bli slaktet. Vannmerkeverktøyet finnes fordi en bok ble piratkopieret. Valutakonverteren finnes fordi skjulte gebyrer holdt på å spise internasjonale overføringer. Koblingsleder finnes fordi 35 dollar for URL-forkorting er absurd.
Produkter bygget fra personlig frustrasjon har en strukturell fordel over produkter bygget fra markedsmulighet. Grunnleggeren forstår problemet på cellulærnivå fordi de levde med det. De vet hvilke funksjoner som er viktig og hvilke som er dekorasjon. De vet det nøyaktige øyeblikket når en eksisterende løsning mislykkes fordi de opplevde den feilen på første hånd. De bygger for den use-casen de vet, ikke use-casen de forestiller seg.
Ulempen er at denne tilnærmingen produserer produkter på en uforutsigbar tidsplan. Det er ingen kjøreplan drevet av kvartalvis planlegging. Et nytt produkt dukker opp når en ny frustrasjon krysser terskelen. Noen ganger dukker tre produkter opp i en enkelt kvartal. Noen ganger går seks måneder med bare raffinementer til eksisterende verktøy. Utviklingstidslinjen følger formen av ekte problemer, ikke formen av en forretningsplan.
Femten frustrasjioner ble femten produktlinjer, som utvidet til 41 APIer og 68 verktøy. Kreditt systemet binder alt sammen slik at en bruker som starter med bildeoverskrifter kan oppdage vannmerking, koblingssporing, oversettelse, og valutakonvertering uten å opprette nye kontoer eller kjøpe nye abonnementer. Økosystemet vokste organisk fordi problemene den løser er organisk forbundet. Kreatører som lager videoer trenger også undertekster. Forfattere som skriver bøker trenger også vannmerker. Bedrifter som forkorter lenker trenger også QR-koder. Forbindelsene var aldri planlagt. De ble oppdaget, en irritasjon av gangen.
Ofte Stilte Spørsmål
Er alle femten produktene bygget av én person?
Ja. Hvert API, SaaS-applikasjon, og nettbasert verktøy på yeb.to ble designet, utviklet, og vedlikeholdt av en enkelt utvikler. Tekststakken er applikasjonsrammeverket, nettleserautomatisering for rendering og AI-modeller for lydtranskribering.
Hvorfor er det så mange forskjellige produkter i stedet for ett fokusert verktøy?
Hvert produkt løser en spesifikk frustrasjon som ble personlig møtt. Variasjonen reflekterer bredden av problemer en arbeidsende utvikler og innholdslager møter på tvers av forskjellige domener. Det delte kreditt systemet og infrastrukturen betyr at vedlikehold av flere produkter er betydelig mer effektivt enn det ville være hvis hver enkelt ran på separat infrastruktur.
Bruker alle produktene det samme kreditt systemet?
Ja. En kreditt saldo fungerer på tvers av alle 41 APIer, 18 SaaS-apper, og 68 verktøy. Ti dollar kjøper hundre kreditter, og bulkkjøp reduserer per-kreditt kostnaden ytterligere. Kreditter utløper aldri og blir bare trukket når en tjeneste faktisk brukes.
Hvilket produkt var mest vanskelig å bygge?
Screenshot-APIen krevde den mest komplekse infrastrukturen fordi den kjører headless Chromium-nettlesere inne i containere. Styring av nettleserinstanser, håndtering av JavaScript-tunge sider, implementering av OCR, og bygning av visuell diff-deteksjon involverte betydelig flere bevegelige deler enn tekstbehandling eller API-wrapper-verktøy.
Kan noen bruke bare ett produkt uten å trenge de andre?
Absolutt. Hvert produkt fungerer uavhengig. Kreditt systemet er delt, men det er ikke krav om å bruke flere tjenester. Noen som bare trenger bildeoverskrifter vil aldri samhandle med vannmerke eller valutaverktøyer med mindre de velger det.
Hva skjer når en ny frustrasjon dukker opp?
Det blir et nytt produkt. Utviklingsprosessen har ikke endret seg siden det første verktøyet. Et problem blir identifisert, eksisterende løsninger blir evaluert, og hvis de kommer til kort, blir et nytt verktøy bygget. Plattformen vokser i takten med ekte problemer, ikke i takten med planlagte produktlanseringer.