Freelancer desarrolla agente OpenClaw para pruebas visuales de aplicaciones, consigue 11 clientes.

Cómo comenzó: Identificando un error prevenible

Un freelancer frontend trabajaba en una aplicación de mercado de servicios para el hogar con alrededor de 890k descargas. Mientras reconstruía el flujo de búsqueda y filtros, notó tickets de soporte recurrentes sobre el sistema de reseñas que adjuntaba calificaciones al proveedor de servicios incorrecto. El error ocurría porque el envío de la reseña asociaba las calificaciones por la marca de tiempo de la reserva más reciente en lugar del ID de reserva que el usuario realmente seleccionó en la pantalla de reseñas. Esto creaba una condición de carrera cuando el orden de la lista de reservas cambiaba entre el momento en que el usuario tocaba "dejar reseña" y cuando la pantalla de reseñas se cargaba.

El ingeniero principal conocía el problema desde hacía dos meses, pero su proceso de prueba consistía en abrir la aplicación en su teléfono, tocar a través de las pantallas principales y enviar si nada parecía roto. Nunca probaron el flujo de reseñas con múltiples reservas porque solo tenían una cuenta de prueba con una reserva a la vez. El error solo aparecía cuando usuarios reales tenían reservas superpuestas en la misma semana, lo que era la mayoría de sus usuarios activos.

La solución: Construyendo un agente de pruebas visuales

Usando OpenClaw durante tres meses en su propio flujo de trabajo, el desarrollador construyó un agente que:

• Toma pasos de prueba escritos en declaraciones simples
• Se conecta a un emulador en la nube
• Ejecuta la aplicación visualmente
• Captura cada paso en el camino
• Muestra exactamente dónde algo se rompe y cómo se veía la pantalla

Después de dos semanas de práctica con pequeñas aplicaciones de amigos para dominar la escritura de pasos, ofrecieron al cliente de servicios para el hogar 5 ejecuciones de prueba gratuitas. El flujo de reseñas falló en la segunda ejecución, exponiendo el error exacto con capturas de pantalla mostrando dónde salió mal.

Modelo de negocio y adquisición de clientes

El servicio cuesta $180/mes por 26 flujos que cubren los recorridos principales del usuario. El desarrollador ejecuta el agente, mantiene el contexto, agrega flujos cuando se lanzan nuevas funciones y marca cualquier cosa que se rompa, tomando aproximadamente 2.5 horas por mes por cliente.

Los clientes iniciales llegaron a través de conexiones profesionales:

• Una aplicación de seguimiento de flotas (1.4 millones de descargas) con problemas de registro de rutas donde las rutas rastreadas mostraban huecos cuando la aplicación perdía el estado en primer plano durante viajes largos. $320/mes.
• Una aplicación de comunicación escolar (1.3 millones de descargas) con enrutamiento de notificaciones que enviaba anuncios de clase a grupos de padres incorrectos cuando los maestros estaban asignados a múltiples secciones. $200/mes.

Clientes adicionales incluyeron una aplicación de entrega de comestibles ($220/mes), una aplicación de sincronización de inventario ($130/mes) y una aplicación de reserva de salones ($140/mes). El boca a boca de clientes existentes impulsó un mayor crecimiento a través de chats grupales de fundadores, reuniones y comunidades de desarrolladores.

Un cliente potencial no funcionó: un fundador que construía una aplicación de recetas con IA vio la prueba pero planeaba una reescritura importante y decidió que probar la versión actual no tenía sentido.

Métricas actuales

11 clientes totales: 9 activos, 2 terminando la incorporación. Ingresos recurrentes totales cuando todos estén activos: $3,840/mes. El desarrollador dedica aproximadamente 22 horas por mes en todos los clientes, con un promedio de 2-3 horas de mantenimiento por cliente. Esto equivale a aproximadamente $170/hora por un trabajo que consiste principalmente en revisar informes y escribir nuevos flujos cuando se lanzan funciones.

Tarifas únicas agregaron $1,600 en total, incluyendo $500 por documentación completa de flujos en la aplicación de flotas y $450 para la aplicación escolar que necesitaba flujos separados para 6 roles de usuario diferentes.