Cómo convertir en negocio la operación detrás de una API de capturas: ScreenshotOne

Alertas que los clientes nunca vieron

El 17 de julio de 2025, a Dmytro Krasun le llegó una alerta extraña mientras operaba ScreenshotOne. Era un aviso de que se había agotado el tiempo de espera en una comprobación que abría páginas web con un navegador real para capturar su pantalla. Los demás sistemas de monitorización no mostraban problemas y las solicitudes de los clientes se atendían con normalidad. Krasun perdió sueño durante varios días buscando un problema que no había llegado a los clientes.

Revisó el volumen de solicitudes y la carga de los servidores, revirtió el código que había modificado hacía poco e incluso comprobó las conexiones de red. Al acotar el origen, encontró que el sitio web externo que usaba como objetivo de la comprobación tenía una conexión inestable. Cuando cambió el objetivo de la captura por su propia página de presentación, todo volvió a funcionar. Aquel episodio le confirmó la necesidad de un entorno de pruebas bajo su control y lo llevó a mejorar las herramientas de diagnóstico.

El procesamiento detrás de una sola captura

ScreenshotOne, lanzado por Krasun en mayo de 2022, era una API que devolvía resultados como capturas de pantalla o archivos PDF cuando otro programa le enviaba una dirección web o código HTML. Antes de fundar la empresa, Krasun había trabajado más de diez años desarrollando servidores y sistemas para procesar grandes volúmenes de solicitudes. Eligió un mercado de capturas de pantalla en el que la gente ya pagaba y decidió hacerse cargo de los problemas que surgen al operar navegadores y generar imágenes. El cliente pedía la imagen que necesitaba para su producto y podía dejar en manos de ScreenshotOne todo lo que ocurría por detrás.

Las herramientas para que un desarrollador creara su propia función de capturas ya existían. Con Puppeteer o Playwright se podía automatizar un navegador, abrir una página web y guardar una imagen. Sin embargo, para capturar la página completa había que cargar las imágenes que aparecen después de desplazarse, y si el aviso de cookies tapaba el contenido, había que resolverlo. Entre ajustar el tamaño de la ventana y la ubicación donde se guardaba el resultado a lo que pedía cada cliente, aquel código corto del principio se convirtió en un servicio que atiende muchas condiciones distintas.

ScreenshotOne fue acumulando en su producto esa experiencia con tantas condiciones. Según la presentación oficial del producto, las reglas y los criterios que utiliza para gestionar los avisos de cookies superan los 50.000. El cliente puede ocultar anuncios o ventanas de chat y, cuando lo necesita, ajustar el estilo y el comportamiento de la página. En lugar de que cada equipo de desarrollo resolviera por su cuenta problemas parecidos, todos podían usar en conjunto los métodos que había reunido un servicio especializado.

El caso de BugSmash, una herramienta de retroalimentación para el trabajo en equipo, muestra en qué punto un equipo de desarrollo decide pagar. Cuando un usuario introduce la dirección de un sitio web que quiere revisar, BugSmash tenía que generar una imagen de vista previa para el panel y para el enlace compartido. Esa imagen la ve el usuario de inmediato, así que era importante que no quedara tapada por ventanas emergentes ni tardara en generarse. BugSmash usó ScreenshotOne para esa tarea. En cambio, para su función de evaluación de sitios web utilizaba Puppeteer y, en un caso publicado en abril de 2025, señaló que administrar servidores y procesar varias capturas a la vez le resultaba una carga.

BugSmash recurrió a otro método cuando necesitaba registrar la pantalla en el momento en que el usuario dejaba un comentario. Como tenía que incluir la posición de elementos en movimiento y las ventanas emergentes abiertas, capturaba dentro del navegador del usuario o usaba una extensión. Incluso dentro de un mismo producto, generar una imagen de vista previa y registrar la pantalla actual del usuario eran requisitos distintos. El terreno que asumió ScreenshotOne fue el de abrir páginas web una y otra vez en el servidor y producir de forma estable las imágenes que el producto necesitaba.

El proceso de integración también se diseñó para ahorrar tiempo a los desarrolladores. La guía de inicio muestra un ejemplo en el que se envía una dirección web y una clave de acceso, y ofrece código de integración para distintos lenguajes de programación. El cliente puede cambiar opciones en la pantalla de pruebas del panel y comprobar el resultado. Cuando ocurre un error, la respuesta incluye tanto un código que el programa puede distinguir como una descripción legible para las personas, lo que facilita al equipo de desarrollo del cliente tratar la causa del fallo.

Una infraestructura que ajusta el uso y el coste

Los precios se diseñaron para empezar con un uso pequeño y ampliarlo según la necesidad real. A septiembre de 2026 ofrece 100 capturas gratuitas al mes; el plan básico, de 17 dólares al mes, incluye 2.000 capturas, y el plan de crecimiento, de 79 dólares al mes, incluye 10.000. Al superar el uso incluido, se paga un coste adicional según la tarifa de cada plan. El plan básico ya permite usar funciones como la captura de la página completa, el bloqueo de anuncios y avisos de cookies y la generación de PDF, de modo que el cliente decide su gasto en función del volumen de procesamiento que necesita.

Las reglas de cobro también contemplan los fallos y la reutilización. Las solicitudes que fallan por errores de red o del navegador no se descuentan del uso, y las respuestas de caché que devuelven un resultado ya guardado no se cuentan como una captura nueva. Con esta estructura, reducir la tasa de fallos y reutilizar las imágenes ya creadas influye a la vez en la satisfacción del cliente y en el coste del operador. Krasun tuvo que aprender esa relación durante la operación real.

Al principio enviaba las solicitudes a través de Cloudflare y guardaba en caché las capturas ya generadas para reutilizarlas. Pero cuando una imagen guardada desaparecía de la caché, había que volver a ejecutar el navegador para atender la misma solicitud. En aquel entonces, las solicitudes de caché que ofrecía gratis a sus clientes le generaban un coste real de generación de pantallas y, según explicó, estaba perdiendo dinero por esa razón. Añadió R2, un servicio de almacenamiento de archivos, como segunda capa de almacenamiento para que, aunque la imagen no estuviera en la memoria caché cercana, se pudiera buscar en el almacén y devolverla.

Después, el papel de Cloudflare Workers, que procesa las solicitudes en la primera línea, también se amplió. Comprobaba primero las solicitudes mal formadas y las claves de acceso no válidas, y verificaba si se había superado la cantidad de solicitudes permitida para que el trabajo innecesario no llegara hasta los servidores del navegador. Si el servidor principal estaba sobrecargado o fallaba al generar la pantalla, enviaba la solicitud a otro centro de datos. Mientras el cliente envía una sola dirección web, dentro del servicio se decide dónde procesar la solicitud y qué resultado reutilizar.

Una API dentro del trabajo de sus clientes

Sobre esa base, la relación con un mismo cliente podía durar varios años. RepliQ, que crea vídeos personalizados para ventas, contó en un caso publicado en julio de 2026 que había usado ScreenshotOne durante unos cuatro años. Lo empleaba para convertir el sitio web o el perfil de un cliente potencial en imágenes y GIF animados que luego ponía como fondo de sus vídeos. RepliQ explicó que pudo reducir la gestión de su propio sistema de capturas y concentrarse en la personalización de los vídeos, y mantuvo la integración mientras su servicio crecía.

Krasun también publicó cómo construir una API de capturas de pantalla por su cuenta. Su guía de desarrollo incluye la validación de solicitudes, el tratamiento de los avisos de cookies, la captura de la página completa y la carga y el despliegue en el almacenamiento. El lector ve a la vez hasta dónde puede llegar con su propia implementación y qué trabajo adicional tendría que asumir. Esta documentación explica la tecnología a los clientes potenciales y, al mismo tiempo, les da elementos para decidir si lo gestionan por su cuenta o lo dejan en manos de un servicio especializado.

Publicar el proceso de desarrollo con constancia también influyó en la adopción del producto. Orlando Kalossakas, cofundador del servicio de automatización de tareas con IA Toolhouse, siguió la actividad de Krasun en X y en Indie Hackers desde el principio. Contó que, cuando necesitó una función para capturar páginas web, ScreenshotOne fue lo primero que le vino a la mente y que apenas sintió la necesidad de compararlo con otros servicios. Fue el caso de alguien que no tenía motivo para comprar en ese momento, siguió los cambios del producto y lo eligió cuando su trabajo lo necesitó.

En la integración de Toolhouse, la documentación y la pantalla de pruebas volvieron a tener un papel importante. Kalossakas entregó la documentación de ScreenshotOne a una herramienta de IA para ordenar el procedimiento de implementación y probó opciones en el panel. Después de la integración, los usuarios de Toolhouse pudieron conectar su propia clave de acceso de ScreenshotOne para que un agente de IA capturara y analizara páginas web. La función de generar pantallas se amplió así a la tarea de proporcionar material visual a un servicio de IA.

Decidir hasta dónde llegar operando en solitario

Krasun analizaba el alcance del producto incluso cuando le ofrecían pagar por algo. Probó varias veces la función de comparar capturas a lo largo del tiempo, pero consideró que era difícil reducir los errores que toman diferencias sin importancia por cambios y que se parecía a un producto aparte. Tampoco añadió la función de recorrer y archivar sitios web completos, porque las necesidades de los clientes y la forma de operarla variaban. Explicó que eligió concentrarse en que las funciones existentes funcionaran bien.

En el proceso de venta, entender a los clientes le llevó más tiempo del esperado. En una entrevista de 2026, Krasun dijo que tardó dos años en comprender a quién le vendía el producto y que esa comprensión influyó en los textos de promoción, el contenido, los puntos de desarrollo y el precio. Después observó por canal de adquisición el recorrido en el que un visitante se registra y un usuario registrado se convierte en cliente de pago. Explicó que distinguir entre los casos en que faltaban visitantes y aquellos en que había visitantes pero no se registraban, y corregir desde la etapa donde aparecía el problema, ayudó a que crecieran las ventas.

Para seguir operando, también tenía que reducir su propia intervención diaria. En marzo de 2024 contó que había habilitado una tarjeta dedicada a los gastos del negocio y que había configurado el depósito automático de los cobros en la cuenta de pago de esa tarjeta. Montó un entorno que ampliaba los servidores según el volumen de solicitudes y preparó un entorno de ejecución de respaldo en otra nube. Era un trabajo de automatizar tareas repetitivas, como el pago de costes y la ampliación de servidores, para que el servicio siguiera funcionando aunque él se ausentara un tiempo.

También recurrió a ayuda externa para tareas especializadas. En su presentación oficial actual, Krasun explica que desarrolla y opera el producto por su cuenta y que colabora con especialistas en determinados proyectos. La dirección del producto y la relación con los clientes quedan en sus manos, y en el trabajo necesario suma la capacidad de otras personas. Es una forma de operar centrada en el fundador.

En la entrevista de marzo de 2026, ScreenshotOne superaba los 800 clientes de pago y su ingreso recurrente mensual (MRR) era de más de 25.000 dólares. Las cifras que publicó después, al cumplir cuatro años desde el lanzamiento, fueron más de 1.000 clientes de pago y 33.000 dólares de MRR. Las llamadas acumuladas a la API también superaron los 100 millones. A medida que la función de convertir páginas web en imágenes se incorporó al trabajo diario de varios productos, el uso recurrente de los clientes sostuvo el negocio de suscripción.

En la retrospectiva del cuarto aniversario, Krasun mencionó como un logro propio el hecho de no haberse perdido casi ningún acto importante de sus hijos. En una entrevista de ese año también dijo que quería automatizar la operación lo suficiente para irse una semana de excursión a la montaña sin conectarse a internet. En un negocio que devolvió a otros equipos de desarrollo el tiempo que dedicaban a su sistema de capturas, conseguir más tiempo para sí mismo quedaba como la siguiente tarea pendiente.