Every Product I Built Started With Something That Annoyed Me and Here Are All Fifteen Problems

Nobody wakes up one morning and decides to build fifteen software products. That is not how it works. What actually happens is slower, messier, and far less glamorous than any startup origin story would suggest. A problem appears. It festers. The existing solutions turn out to be overpriced, underpowered, or so locked into subscription models that using them for a minor task feels like hiring a moving truck to carry a single lamp. Eventually the frustration crosses a threshold, and the only rational response is to build something better. Then another problem appears. And another. Fifteen problems later, there is an entire platform, and every single product on it traces back to a specific moment of genuine annoyance.

This is not a carefully curated narrative designed to make entrepreneurship sound romantic. Some of these frustrations were tiny. Some were expensive. A few were infuriating enough to ruin entire weekends. But every single one followed the same pattern: encounter a problem, search for a solution, find the solution inadequate, build a better one. That pattern repeated itself for years, and the result is yeb.to with its forty one APIs, eighteen SaaS applications, and sixty eight online tools.

The First Five Frustrations That Started Everything

The caption tool came first, and it came from the simplest of irritations. Running YouTube channels focused on AI generated music meant producing lyric videos with burned in subtitles. Captions.ai charged ten euros a month for this privilege, which felt reasonable until the months with only two or three videos started piling up. Paying a flat subscription for a tool that sat unused most weeks was the kind of waste that compounds silently. The alternative was obvious: build a tool that charges per video processed, not per month of calendar time. Credits replaced subscriptions, and the savings became immediate.

The translation tool grew from a different kind of problem. Machine translation services handle major languages competently enough, but the moment you need Bulgarian or Serbian, the quality drops off a cliff. Gender agreement errors. Wrong verb conjugations. Sentences that are technically translated but sound like they were assembled by someone who learned the language from a dictionary and never heard it spoken. The existing tools treated smaller languages as afterthoughts bolted onto engines optimized for English, Spanish, and French. Building a translation service that treated every language as a first class citizen was not a business decision. It was a response to receiving one too many laughably wrong translations of perfectly ordinary sentences.

The watermark tool came from publishing. Writing a book, converting it to PDF, and watching it appear on piracy sites within days of release is a unique kind of violation. DRM solutions promised protection but delivered inconvenience for legitimate readers and zero obstacle for determined pirates. The realization that what authors actually need is not copy prevention but copy tracing led to a watermarking system that makes every distributed copy individually identifiable. The problem was personal: a book got pirated. The solution became a product.

The currency converter was born in the gap between advertised exchange rates and actual received amounts. Every international transfer involved a ritual of checking the mid market rate, then watching the received amount come in noticeably lower because of hidden fees, markup percentages, and conversion spreads that platforms never displayed upfront. Building a currency tool that shows the real rate alongside what Wise, Revolut, PayPal, and Western Union would actually charge was a direct response to receiving one too many transfers where the "fee free" promise evaporated into a three percent spread.

The link management platform addressed a problem that should not exist in 2026. Bitly charges thirty five dollars a month for branded short links. Thirty five dollars. For a service whose core function is replacing a long URL with a short one. The technical complexity of URL shortening is minimal. The infrastructure cost is negligible. Yet somehow the market converged on pricing that assumes every user is a marketing department with a corporate budget. Building LinkHub as a credit based alternative meant that creating a short link costs a fraction of a cent, and the monthly bill is exactly proportional to actual usage.

The Problems That Got Technical

The screenshot API started with uptime monitoring. Checking whether a website was up or down seems trivially simple until the site uses JavaScript rendering, lazy loading, or single page application architecture. A traditional HTTP request sees a blank page or a loading spinner and reports everything as fine, while actual visitors see a broken experience. Taking a real browser screenshot of the rendered page tells the truth in a way that HTTP status codes never can. That need for visual verification evolved into a full screenshot API with scheduled captures, visual diff detection, and OCR text extraction. Five hours of undetected downtime on a client project was the specific incident that started the entire thing.

Bot detection grew from a more alarming discovery. Checking analytics on a web project and finding ten million visits that generated zero conversions, zero engagement, and zero scroll depth. Ten million visits from bots pretending to be real browsers, inflating metrics, skewing data, and making every business decision based on that traffic fundamentally wrong. The existing bot detection solutions were enterprise products priced for companies with security budgets. Building a detection API that could identify bot traffic at the request level, using device fingerprinting and behavioral analysis, was a direct response to the realization that a significant percentage of web traffic is fictional.

The uptime monitoring tool filled the gap that the screenshot API revealed. Knowing a site is visually broken is useful, but knowing the moment it breaks is essential. Existing uptime monitors checked endpoints and reported HTTP codes, which misses the entire category of failures where the server responds with a 200 status code but the page content is wrong, missing, or corrupted. Combining uptime checks with periodic screenshots created a monitoring system that catches failures invisible to traditional tools.

The Problems That Felt Small But Were Not

QR code generation seems like it should be a solved problem. Thousands of free generators exist online. But try to generate a QR code with a specific color scheme, embedded logo, custom error correction level, and tracking analytics, and the free tools reveal their limits almost immediately. The QR code generator on yeb.to exists because every free alternative produced either a plain black and white square with no customization or demanded a monthly subscription for features that should cost pennies per code generated.

The PDF tools came from document workflow friction. Merging three PDFs should not require downloading desktop software or uploading sensitive documents to a random website with unclear privacy policies. Splitting a PDF, compressing it, converting it to images, or extracting text from it should be operations as simple as clicking a button. Each PDF tool on the platform exists because a specific document task was needed, the available options were inadequate, and building the tool took less time than continuing to work around the inadequacy.

The GeoIP lookup service started as a component for analytics but became its own product when the need to identify visitor locations came up repeatedly across different projects. Commercial GeoIP databases charge annual licensing fees. The API wraps freely available data into a format that can be queried instantly, and the credit cost per lookup is low enough that even high volume applications can afford it without negotiating enterprise contracts.

The WordPress analytics plugin tied several of these frustrations together. Running WordPress sites meant needing analytics that could distinguish real visitors from bots, identify geographic origins, and detect device types. Google Analytics handles some of this but buries the useful data under layers of interface complexity and increasingly aggressive data sampling. The WordPress plugin uses three yeb.to APIs internally, which is itself a demonstration of how products built from genuine needs naturally connect into something larger than any individual tool.

The Pattern That Connects All Fifteen

Looking at the full list of products and tracing each one back to its origin reveals a pattern so consistent it almost feels formulaic. Every product began with a personal encounter with a problem. Not a market research finding, not a competitor analysis, not a trend report. A real, specific, annoying problem that demanded a solution. The caption tool exists because ten euros a month for three videos felt wrong. The translator exists because Bulgarian kept getting butchered. The watermark tool exists because a book got pirated. The currency converter exists because hidden fees kept eating international transfers. The link manager exists because thirty five dollars for URL shortening is absurd.

Products built from personal frustration have a structural advantage over products built from market opportunity. The founder understands the problem at a cellular level because they lived with it. They know which features matter and which are decoration. They know the exact moment when an existing solution fails because they experienced that failure firsthand. They build for the use case they know, not the use case they imagine.

The disadvantage is that this approach produces products on an unpredictable schedule. There is no roadmap driven by quarterly planning. A new product appears when a new frustration crosses the threshold. Sometimes three products emerge in a single quarter. Sometimes six months pass with only refinements to existing tools. The development timeline follows the shape of real problems, not the shape of a business plan.

Fifteen frustrations became fifteen product lines, which expanded into forty one APIs and sixty eight tools. The credit system ties everything together so that a user who starts with captions can discover watermarking, link tracking, translation, and currency conversion without creating new accounts or buying new subscriptions. The ecosystem grew organically because the problems it solves are organically connected. Creators who make videos also need subtitles. Authors who write books also need watermarks. Businesses that shorten links also need QR codes. The connections were never planned. They were discovered, one annoyance at a time.