Creación de una aplicación completa de producción con Claude: Lo que realmente funcionó y lo que no

Un desarrollador backend senior con años de experiencia pero cero conocimiento en Flutter/Dart construyó y lanzó una aplicación móvil de producción completa llamada Warantly (gestión de garantías) para iOS y Android usando Claude como su herramienta de desarrollo principal. El proyecto tomó 2.5 meses de tardes después del trabajo diario.

El Stack

• Frontend: Flutter
• Backend: Laravel 12
• Infraestructura: Ansible (todo el entorno VPS codificado, reproducible desde una sola ejecución)

Cómo se usó Claude

El desarrollador manejó a Claude como un desarrollador junior capaz pero con contexto limitado. Ejecutó múltiples sesiones en paralelo, cada una enfocada en un solo tema:

• Generalmente 2-3 sesiones a la vez; en el pico, 6 simultáneas (3 backend, 2 Flutter, 1 DevOps)
• Usó git worktrees para que las sesiones pudieran trabajar en diferentes funciones sin conflictos
• Su rol: arquitecto y capa de integración — alternando entre sesiones, proporcionando contexto, tomando decisiones transversales

Lo que Claude hizo bien

Borradores rápidos y competentes de componentes bien especificados. Cualquier cosa con una especificación clara y alcance limitado volvió usable en el primer o segundo intento. Claude también fue genuinamente bueno guiando al desarrollador en territorios desconocidos: cumplimiento de tiendas, configuración de paywalls, configuración de infraestructura — cosas donde se necesitaba orientación, no solo generación de código.

Donde falló

1. Bugs de UI

El mayor modo de fallo. Claude no tiene forma de ver la pantalla. Analizaba el código, hacía una corrección, decía con confianza "esto debería resolverlo" — y no lo hacía. Múltiples rondas en el mismo bug visual porque el agente razonaba sobre lo que la UI debería hacer en lugar de ver lo que realmente hacía. Solución alternativa: declaraciones de depuración extensas, probar manualmente, alimentar a Claude con la salida exacta en tiempo de ejecución y capturas de pantalla de la UI. El ciclo de retroalimentación — instrumentar, ejecutar, informar — se convirtió en el patrón estándar para cualquier cosa visual.

2. Consistencia entre sesiones

El agente backend podía diseñar un formato de respuesta que no coincidiera con lo que el agente Flutter esperaba. Claude no sabe lo que otras sesiones decidieron. El desarrollador tuvo que ser la fuente de verdad para contratos de API, constantes compartidas, convenciones de nombres — copiándolos entre sesiones manualmente. Cuando se saltaba este paso, se encontraban desajustes durante la integración.

3. Deriva de contexto en sesiones largas

Una sesión que ha estado ejecutándose silenciosamente pierde el hilo — reintroduce patrones ya rechazados, contradice restricciones anteriores. No lo anuncia. La salida deja de ser coherente con su propio historial. Solución: mantener sesiones enfocadas y desechables. Empezar de nuevo cuando se alargan. Cargar el contexto crítico al inicio como un informe estructurado en lugar de depender del historial de conversación.

Qué hizo que funcionara

El desarrollador impuso pruebas y análisis estático desde el día uno. No podía revisar código Dart/Flutter con ojos expertos, pero las comprobaciones automáticas actuaron como control de calidad. Sin ello, no habría tenido la confianza para lanzar. "La parte más difícil no fue técnica — fue ceder el control. Soy un desarrollador experimentado y este fue el primer proyecto donde no revisaba el código línea por línea. Confiar en el proceso (pruebas pasan, linter limpio, comportamiento correcto) sobre leer cada función fue un verdadero ajuste."

La App

Warantly — gestión de garantías. Rastrea compras, almacena fotos de recibos, recibe recordatorios de vencimiento, escaneo de recibos con IA, alertas de retiro de productos. Gratis con garantías ilimitadas. Pro añade escaneo con IA, alertas de retiro y programas de mantenimiento. Disponible en warantly.app.