Nadie se despierta una mañana y decide construir quince productos de software. Así no es como funciona. Lo que realmente sucede es más lento, más desorganizado y mucho menos glamoroso de lo que cualquier historia de origen de startup sugeriría. Aparece un problema. Se enquista. Las soluciones existentes resultan ser demasiado caras, poco potentes o tan atrapadas en modelos de suscripción que usar una para una tarea menor se siente como alquilar un camión de mudanza para llevar una sola lámpara. Eventualmente, la frustración cruza un umbral y la única respuesta racional es construir algo mejor. Entonces aparece otro problema. Y otro más. Quince problemas después, existe toda una plataforma, y cada producto en ella se remonta a un momento específico de verdadera molestia.

Esto no es una narrativa cuidadosamente curada diseñada para que el espíritu empresarial suene romántico. Algunas de estas frustraciones fueron minúsculas. Algunas fueron costosas. Algunas fueron lo suficientemente irritantes como para arruinar fines de semana completos. Pero cada una siguió el mismo patrón: encontrar un problema, buscar una solución, encontrar la solución inadecuada, construir una mejor. Ese patrón se repitió durante años, y el resultado es yeb.to con sus cuarenta y un API, dieciocho aplicaciones SaaS y sesenta y ocho herramientas en línea.

Las primeras cinco frustraciones que lo iniciaron todo

La herramienta de subtítulos llegó primero, y provino de la irritación más simple. Ejecutar canales de YouTube enfocados en música generada por IA significaba producir videoclips de letras con subtítulos quemados. Captions.ai cobraba diez euros al mes por este privilegio, lo que parecía razonable hasta que comenzaron a acumularse los meses con solo dos o tres videos. Pagar una suscripción plana por una herramienta que se quedaba sin usar la mayoría de las semanas fue el tipo de desperdicio que se acumula silenciosamente. La alternativa era obvia: construir una herramienta que cobre por video procesado, no por mes calendario. Los créditos reemplazaron las suscripciones y los ahorros fueron inmediatos.

La herramienta de traducción surgió de un tipo diferente de problema. Los servicios de traducción automática manejan los idiomas principales con competencia suficiente, pero en el momento en que necesitas búlgaro o serbio, la calidad se desmorona. Errores de concordancia de género. Conjugaciones verbales incorrectas. Frases que están técnicamente traducidas pero suenan como si fueran armadas por alguien que aprendió el idioma de un diccionario y nunca lo escuchó hablado. Las herramientas existentes trataban los idiomas más pequeños como adiciones pegadas a motores optimizados para inglés, español y francés. Construir un servicio de traducción que tratara cada idioma como un ciudadano de primera clase no fue una decisión comercial. Fue una respuesta a recibir demasiadas traducciones risueñamente incorrectas de oraciones perfectamente ordinarias.

La herramienta de marca de agua provino de la publicación. Escribir un libro, convertirlo a PDF y verlo aparecer en sitios de piratería días después de su lanzamiento es un tipo único de violación. Las soluciones de DRM prometían protección pero entregaban inconveniencia para lectores legítimos y cero obstáculo para piratas decididos. La realización de que lo que los autores realmente necesitan no es prevención de copia sino rastreo de copia condujo a un sistema de marca de agua que hace que cada copia distribuida sea individualmente identificable. El problema fue personal: un libro fue pirateado. La solución se convirtió en un producto.

El convertidor de divisas nació en la brecha entre los tipos de cambio anunciados y los montos realmente recibidos. Cada transferencia internacional involucraba un ritual de verificación del tipo de cambio del mercado medio, seguido de ver la cantidad recibida llegar notablemente más baja debido a tarifas ocultas, márgenes de beneficio y diferenciales de conversión que las plataformas nunca mostraban por adelantado. Construir una herramienta de divisas que mostrara la tasa real junto con lo que Wise, Revolut, PayPal y Western Union realmente cobrarían fue una respuesta directa a recibir demasiadas transferencias donde la promesa de "sin tarifa" se evaporó en un diferencial del tres por ciento.

La plataforma de gestión de enlaces abordó un problema que no debería existir en 2026. Bitly cobra treinta y cinco dólares al mes por enlaces cortos marcados. Treinta y cinco dólares. Por un servicio cuya función principal es reemplazar una URL larga con una corta. La complejidad técnica de la abreviación de URL es mínima. El costo de infraestructura es insignificante. Sin embargo, de alguna manera el mercado convergió en precios que asumen que cada usuario es un departamento de marketing con presupuesto corporativo. Construir LinkHub como alternativa basada en créditos significa que crear un enlace corto cuesta una fracción de centavo, y la factura mensual es exactamente proporcional al uso real.

Los problemas que se volvieron técnicos

La API de captura de pantalla comenzó con monitoreo de tiempo de actividad. Verificar si un sitio web está arriba o abajo parece trivialmente simple hasta que el sitio usa renderizado JavaScript, carga perezosa o arquitectura de aplicación de una sola página. Una solicitud HTTP tradicional ve una página en blanco o un spinner de carga e informa que todo está bien, mientras que los visitantes reales ven una experiencia rota. Tomar una captura de pantalla real del navegador de la página renderizada dice la verdad de una manera que los códigos de estado HTTP nunca pueden. Esa necesidad de verificación visual evolucionó hacia una API de captura de pantalla completa con capturas programadas, detección de diferencias visuales y extracción de texto OCR. Cinco horas de tiempo de inactividad no detectado en un proyecto de cliente fue el incidente específico que inició todo.

La detección de bots surgió de un descubrimiento más alarmante. Verificar la analítica en un proyecto web y encontrar diez millones de visitas que generaron cero conversiones, cero participación y cero profundidad de desplazamiento. Diez millones de visitas de bots haciéndose pasar por navegadores reales, inflando métricas, sesgando datos y haciendo que toda decisión comercial basada en ese tráfico sea fundamentalmente incorrecta. Las soluciones existentes de detección de bots eran productos empresariales con precios para empresas con presupuestos de seguridad. Construir una API de detección que pudiera identificar tráfico de bots a nivel de solicitud, usando huellas digitales de dispositivos y análisis de comportamiento, fue una respuesta directa a la realización de que un porcentaje significativo del tráfico web es ficticio.

La herramienta de monitoreo de tiempo de actividad llenó la brecha que reveló la API de captura de pantalla. Saber que un sitio está visualmente roto es útil, pero saber el momento en que se rompe es esencial. Los monitores de tiempo de actividad existentes verificaban puntos finales e informaban códigos HTTP, lo que pierde toda la categoría de fallos donde el servidor responde con un código de estado 200 pero el contenido de la página es incorrecto, falta o está corrupto. Combinar verificaciones de tiempo de actividad con capturas de pantalla periódicas crea un sistema de monitoreo que detecta fallos invisibles para las herramientas tradicionales.

Los problemas que parecían pequeños pero no lo eran

La generación de códigos QR parece que debería ser un problema resuelto. Miles de generadores gratuitos existen en línea. Pero intenta generar un código QR con un esquema de color específico, logotipo incrustado, nivel de corrección de errores personalizado y análisis de seguimiento, y las herramientas gratuitas revelan sus límites casi inmediatamente. El generador de código QR en yeb.to existe porque cada alternativa gratuita producía un cuadrado blanco y negro simple sin personalización o exigía una tarifa de suscripción mensual por características que deberían costar centavos por código generado.

Las herramientas PDF provienen de la fricción del flujo de trabajo de documentos. Fusionar tres PDF no debería requerir descargar software de escritorio o cargar documentos sensibles en un sitio web aleatorio con políticas de privacidad poco claras. Dividir un PDF, comprimirlo, convertirlo a imágenes o extraer texto de él deberían ser operaciones tan simples como hacer clic en un botón. Cada herramienta PDF en la plataforma existe porque se necesitaba una tarea de documento específica, las opciones disponibles eran inadecuadas y construir la herramienta tomó menos tiempo que continuar trabajando alrededor de la inadecuación.

El servicio de búsqueda de GeoIP comenzó como un componente para analítica pero se convirtió en su propio producto cuando la necesidad de identificar ubicaciones de visitantes surgió repetidamente en diferentes proyectos. Las bases de datos comerciales de GeoIP cobran tarifas de licencia anuales. La API envuelve datos disponibles gratuitamente en un formato que se puede consultar instantáneamente, y el costo de crédito por búsqueda es lo suficientemente bajo como para que incluso las aplicaciones de alto volumen puedan permitírselo sin negociar contratos empresariales.

El complemento de analítica de WordPress reunió varias de estas frustraciones. Ejecutar sitios de WordPress significaba necesitar analítica que pudiera distinguir visitantes reales de bots, identificar orígenes geográficos y detectar tipos de dispositivos. Google Analytics maneja algo de esto pero entierra los datos útiles bajo capas de complejidad de interfaz y muestreo de datos cada vez más agresivo. El complemento de WordPress usa tres API de yeb.to internamente, que es en sí una demostración de cómo los productos construidos a partir de necesidades genuinas se conectan naturalmente en algo más grande que cualquier herramienta individual.

El patrón que conecta los quince

Mirar la lista completa de productos y rastrear cada uno hasta su origen revela un patrón tan consistente que casi se siente formulaico. Cada producto comenzó con un encuentro personal con un problema. No un hallazgo de investigación de mercado, no un análisis de competencia, no un informe de tendencias. Un problema real, específico y frustrante que exigía una solución. La herramienta de subtítulos existe porque diez euros al mes por tres videos se sentía mal. El traductor existe porque el búlgaro sigue siendo destrozado. La herramienta de marca de agua existe porque un libro fue pirateado. El convertidor de divisas existe porque las tarifas ocultas siguen comiendo transferencias internacionales. El gestor de enlaces existe porque treinta y cinco dólares para abreviar URL es absurdo.

Los productos construidos a partir de frustración personal tienen una ventaja estructural sobre los productos construidos a partir de oportunidad de mercado. El fundador entiende el problema a un nivel celular porque lo vivió. Saben qué características importan y cuáles son decoración. Saben el momento exacto en que una solución existente falla porque experimentaron ese fracaso de primera mano. Construyen para el caso de uso que conocen, no para el caso de uso que imaginan.

La desventaja es que este enfoque produce productos en un cronograma impredecible. No hay una hoja de ruta impulsada por planificación trimestral. Un nuevo producto aparece cuando una nueva frustración cruza el umbral. A veces tres productos emergen en un solo trimestre. A veces seis meses pasan solo con refinamientos a herramientas existentes. El cronograma de desarrollo sigue la forma de problemas reales, no la forma de un plan comercial.

Quince frustraciones se convirtieron en quince líneas de productos, que se expandieron en cuarenta y un API y sesenta y ocho herramientas. El sistema de créditos une todo para que un usuario que comienza con subtítulos pueda descubrir marca de agua, seguimiento de enlaces, traducción y conversión de divisas sin crear nuevas cuentas ni comprar nuevas suscripciones. El ecosistema creció orgánicamente porque los problemas que resuelve están orgánicamente conectados. Los creadores que hacen videos también necesitan subtítulos. Los autores que escriben libros también necesitan marcas de agua. Las empresas que acortan enlaces también necesitan códigos QR. Las conexiones nunca fueron planeadas. Fueron descubiertas, una frustración a la vez.

Preguntas frecuentes

¿Todos los quince productos fueron construidos por una sola persona?

Sí. Cada API, aplicación SaaS y herramienta en línea en yeb.to fue diseñada, desarrollada y mantenida por un único desarrollador. El stack tecnológico es el marco de aplicación, automatización del navegador para renderizado y modelos de IA para transcripción de audio.

¿Por qué hay tantos productos diferentes en lugar de una herramienta enfocada?

Cada producto aborda una frustración específica que fue personalmente encontrada. La variedad refleja la amplitud de problemas que un desarrollador trabajador y un creador de contenido enfrentan en diferentes dominios. El sistema de créditos compartido e infraestructura significa que mantener múltiples productos es significativamente más eficiente de lo que sería si cada uno funcionara en infraestructura separada.

¿Todos los productos utilizan el mismo sistema de créditos?

Sí. Un saldo de crédito funciona en los cuarenta y uno API, dieciocho aplicaciones SaaS y sesenta y ocho herramientas. Diez dólares compran cien créditos, y las compras a granel reducen aún más el costo por crédito. Los créditos nunca vencen y solo se deducen cuando se utiliza realmente un servicio.

¿Cuál fue el producto más difícil de construir?

La API de captura de pantalla requería la infraestructura más compleja porque ejecuta navegadores Chromium sin cabeza dentro de contenedores. Gestionar instancias de navegador, manejar páginas pesadas en JavaScript, implementar OCR y construir detección de diferencias visuales involucraban significativamente más piezas móviles que procesamiento de texto o herramientas envolventes de API.

¿Puede alguien usar solo un producto sin necesidad de los otros?

Absolutamente. Cada producto funciona independientemente. El sistema de créditos se comparte, pero no hay requisito de usar múltiples servicios. Alguien que solo necesita subtítulos nunca interactuará con la marca de agua o herramientas de divisas a menos que elija hacerlo.

¿Qué sucede cuando aparece una nueva frustración?

Se convierte en un nuevo producto. El proceso de desarrollo no ha cambiado desde la primera herramienta. Se identifica un problema, se evalúan las soluciones existentes y, si son insuficientes, se construye una nueva herramienta. La plataforma crece al ritmo de los problemas reales, no al ritmo de lanzamientos de productos planeados.