PetLog: cómo construí una app en 7 días con IA haciendo el turno de noche

Spoiler: no fue en horas. No fue mágico. Hubo un día que todo se fue al carajo. Y aun así, valió la pena.

---

Soy de los que aprenden estrellándose. No con cursos. No con tutoriales de YouTube de cuatro horas. Mi método favorito es encontrar un problema real, meterme de cabeza y aprender a los golpes. Este proyecto no fue la excepción.

Todo empezó con Nina, mi gata. La veterinaria me recomendó llevar una bitácora de sus eventos de salud, debido a que ella tiene epilepsia; algo simple que me ayudara a tener un registro claro para cuando llegara la cita médica. Busqué apps. Las que encontré eran genéricas, incómodas o de pago. Y ahí nació la pregunta que lo cambió todo: ¿y si la hago yo?

Spoiler adicional: hacía años que no desarrollaba nada serio. En mi trabajo de tiempo completo las oportunidades de programar son escasas. Y honestamente, sentía que me había quedado atrás — agentes de IA, MCPs, el nuevo ecosistema que está transformando la industria. Este proyecto fue mi forma de ponerme al día.

Día 0: de idea a producto

Lo primero que hice no fue abrir un editor de código. Fue abrir Claude.

Le conté la idea. Le pregunté si tenía sentido. Y lo que recibí no fue un simple “sí, suena bien” — fue un análisis completo: benchmarking de competidores, ventajas competitivas, líneas de monetización, arquitectura tecnológica sugerida. Claude me propuso una app empaquetable para tiendas con Capacitor, una PWA, Supabase como backend, Cloudflare para el despliegue.

En una noche, una idea personal se convirtió en un producto con norte claro.

Día 1: eligiendo las herramientas (con presupuesto cero)

Regla número uno que me impuse: no gastar dinero en herramientas de desarrollo. Así que tuve que ser creativo.

Había explorado Antigravity antes, pero me generaba una incomodidad particular: sentía que el proyecto estaba fuera de mi control. La IA hacía cosas, pero yo no entendía del todo qué ni por qué.

Entonces encontré dos cosas que cambiaron el juego:

OpenCode — un asistente de codificación con IA y una capa gratuita generosa. Suficiente para arrancar.

Get Shit Done — un framework basado en Spec-Driven Development. El nombre lo dice todo. Tomas tus requerimientos, los estructuras en milestones, y cada milestone se divide en fases pequeñas y verificables. Nada de improvisar. Nada de código espagueti.

Al cierre del día 1 ya tenía el esquema de tablas en Supabase montado y un frontend sin estilos pero con rutas de navegación funcionales. Primeros pinitos, pero pinitos reales.

Días 2 y 3: la dupla imperfecta que funcionó

El flujo que intenté fue este: Claude genera mockups detallados → OpenCode los implementa. En teoría, perfecto.

En práctica, OpenCode tenía problemas interpretando los diseños. El resultado gráfico no correspondía a lo que los mockups describían. Así que volví a Antigravity — la herramienta que había descartado — pero esta vez con un propósito específico: fidelidad visual.

Emergió una dupla no planeada: OpenCode para lógica, Antigravity para diseño. No era el plan, pero funcionó.

El problema nuevo: los tokens. OpenCode quemaba su cuota en hora y media de trabajo intenso, pero se recargaba en 6-7 horas — manejable. Antigravity se recargaba cada siete días. Después de un sprint intenso, prácticamente desapareció como opción.

Al cierre del día 3: login funcional, registro de mascotas, registro de eventos de salud, alertas. Un producto al 70%.

Día 4: todo se fue al carajo

Un cambio pequeño. Aparentemente inofensivo.

Y el core de la aplicación — el registro de eventos, la función central de todo — dejó de funcionar. Formularios apareciendo donde no debían. Componentes duplicados. Pantallas conectadas a bloques con lógicas contradictorias.

Le di el bug a OpenCode. No lo resolvió. Se liberaron algunos créditos de Antigravity. Tampoco.

Y aquí cometí el error que agravó todo: no tenía manejo de ramas ni tags en git. Sin red de seguridad. Sin punto de retorno. Solo un bug que daba vueltas y vueltas sin solución.

Un día entero perdido. El más frustrante del proyecto.

Día 5: el rescate y la lección más cara

Cansado del loop, tomé una decisión: activar un trial de Claude Pro.

Al tercer intento, Claude Code resolvió el bug. Pero la solución requirió hacer rollback completo del día 4. Todo ese trabajo, borrado.

Dolió. Pero lo que vino después valió más que ese día perdido.

Revisando el proceso con más calma, entendí dónde había fallado la metodología: los milestones 1.1 y 1.2 de Get Shit Done habían quedado mal cerrados, sin verificar. Esa deuda técnica se había ido arrastrando silenciosamente, inyectando bugs en cascada hacia todo lo que vino después.

La lección: en Spec-Driven Development, un milestone mal cerrado no es un detalle menor. Es una bomba de tiempo.

Días 6 y 7: encontrando el ritmo

Con la metodología más clara, el flujo mejoró notablemente:

Claude Code planea los milestones y define las fases → OpenCode implementa.

Pero apareció otro hallazgo interesante: los prompts de Get Shit Done parecen estar optimizados para Claude Code. Cuando intentaba usar Minimax o Nemotron en OpenCode, los modelos se perdían en los requerimientos, sobre-pensaban, perdían el hilo. Claude Code los interpretaba de manera notablemente superior.

Algunas fases seguían tomando más de una hora en cerrar. La deuda técnica acumulada de días anteriores cobraba su factura en retrocesos. Pero el ritmo era otro.

Día 7: versión estable. Desplegada en Cloudflare Pages. Compartida con los primeros usuarios para recoger feedback.

La respuesta fue unánime: sólido, funcional, impresionante para una iniciativa individual construida 100% con apoyo de IA.

Lo que aprendí (de verdad)

Sobre la IA y el desarrollo:

Los influencers que prometen apps terminadas en horas con IA me generan escepticismo. No porque la IA no sea poderosa — lo es — sino porque omiten una parte crucial: saber estructurar un proyecto es irremplazable. Mi experiencia como líder técnico, traduciendo requerimientos de producto en requerimientos técnicos, fue probablemente mi mayor ventaja. Saber pedirle bien a Claude — mockups precisos, objetivos claros, descripciones de comportamiento — marcó la diferencia entre respuestas genéricas y respuestas accionables.

La IA amplifica habilidades. No las sustituye.

Sobre Claude específicamente:

Es la solución más completa para un desarrollador solo que debe cubrir todo el ciclo — análisis de producto, arquitectura, diseño, debugging, planning. Pero es caro. La estrategia óptima es combinarlo con LLMs más económicos para las tareas rutinarias, y reservar Claude para donde realmente marca diferencia.

Sobre Spec-Driven Development:

Mucha gente lo critica diciendo que es volver a las metodologías en cascada tradicionales. Mi experiencia dice lo contrario: es exactamente lo que necesita el desarrollo asistido por IA. Sin estructura, la IA improvisa. Con estructura, ejecuta. La industria lleva 20 años romantizando la agilidad a veces hasta el punto de eliminar todo proceso — y eso, en el contexto de la IA, se paga caro.

Sobre el turno de noche:

La dinámica que hizo posible este proyecto fue simple: yo trabajaba los requerimientos en mi tiempo libre, y los asistentes de IA hacían el turno nocturno ejecutando la aplicación. Una colaboración entre turnos. Quizás eso, más que cualquier otra cosa, resume lo que está cambiando en la industria.

Lo que antes le tomaba semanas a un equipo — diseño, desarrollo, pruebas, producción — hoy con IA se convierte en días. Eso no es hype. Ya está pasando.

¿Y ahora qué?

PetLog no es un experimento terminado. Es el inicio de algo que quiero que trascienda — una herramienta real para cuidadores de mascotas que enfrentan problemas de salud o que simplemente quieren un seguimiento detallado de sus compañeros.

Seguiré evolucionándola. Seguiré aprendiendo estrellándome.

Y Nina, por su parte, ya tiene su bitácora.