ia aplicada · product design · vettech · estrategia de producto
Construí una plataforma completa sola con Claude Code
Respuesta corta
Soy Alison Vivanco y construí Flowly Pets sola: diseño, backend serverless y app móvil en React Native, cerca de 200.000 líneas escritas con Claude Code. Lo que aprendí incomoda a quien viene buscando un tutorial. Cuando escribir código deja de costar, el trabajo difícil se corre entero hacia otra parte: decidir qué merece existir dentro del sistema.
¿Qué cambia cuando escribir código deja de ser lo caro?
Cambia dónde vive el riesgo. En un equipo con roadmap y sprints, la lentitud de la implementación funciona como filtro accidental: si una idea cuesta tres semanas de desarrollo, alguien pregunta si vale la pena antes de empezar. Ese roce es incómodo, a veces burocrático, y mata bastantes malas ideas.
Con Claude Code el roce desaparece. Una idea mediocre se implementa en una tarde y, justamente por eso, llega a producción sin que nadie la haya discutido. El efecto se nota en el tamaño del sistema mucho antes que en su velocidad: más superficie que mantener y menos claridad sobre por qué existe cada parte.
Antes de cada módulo de Flowly Pets me obligué a hacerme una pregunta distinta de la obvia. La obvia, "¿puedo construir esto?", ya venía con la respuesta puesta: sí. La útil era "¿qué se rompe en el resto del sistema si esto existe?".
Tengo una opinión discutible al respecto. La deuda técnica que más me ha tocado pagar en mi carrera rara vez venía de código mal escrito; venía de funcionalidades que se aprobaron sin que nadie se preguntara qué le pasaba al resto del producto cuando entraban. Escribir código con un modelo de lenguaje no empeora la primera causa. Empeora la segunda, y bastante.
¿Cómo modelas un producto de 12 roles sin llenarlo de excepciones?
Decidiendo de quién es cada dato antes de dibujar la primera pantalla. Flowly Pets conecta tutores, veterinarios, clínicas, cuidadores, conductores y transportistas, entre otros: doce roles en total, y varios miran la misma ficha clínica con alcances distintos.
Un transportista necesita saber que el paciente que va a mover tiene indicación de ayuno y a qué hora entra a cirugía. No necesita el historial de diagnósticos. El veterinario tratante necesita todo. La clínica necesita lo que corresponda al paciente mientras esté bajo su atención, y bastante menos después.
Dicho así parece evidente. Deja de serlo cuando lo resuelves pantalla por pantalla: cada vista nueva agrega una excepción razonable, y llega un punto en que nadie puede responder con precisión quién ve qué. Con Claude Code ese punto llega mucho antes, porque las pantallas aparecen más rápido de lo que cualquiera sostiene el modelo mental completo en la cabeza.
Por eso el modelo de dominio fue lo primero: quién es dueño de cada dato, qué puede hacer cada actor con él, cuándo caduca ese acceso. Y sostengo algo que a varios equipos les suena a invasión de territorio: esa definición es trabajo de diseño de producto antes que de backend. Quien decide qué ve un transportista está diseñando la experiencia clínica completa, no configurando una tabla de permisos.
La misma lógica corrió para el resto de las decisiones que no se pueden retroceder gratis. Los ocho idiomas se deciden antes de que existan cientos de textos escritos dentro de los componentes, o se pagan tres veces. La facturación electrónica tiene reglas que no se negocian con el usuario. La suite clínica (pacientes, fichas, hospitalizaciones, agenda, inventario, finanzas) comparte entidades entre módulos que en un roadmap normal se habrían construido con meses de diferencia.
¿Para qué sirve una metodología si la ejecución es casi instantánea?
Sirve como freno deliberado. Trabajo con seis etapas: Entender, Descubrir, Definir, Diseñar, Construir y Evolucionar. Construir es la quinta, y ese orden es lo único que me protege de mí misma, porque construir da gratificación inmediata y además es lo que la herramienta hace bien.
Las cuatro etapas previas hacen el trabajo que ningún modelo me ahorra: acotar. Entender cómo opera de verdad una clínica veterinaria. Descubrir dónde estaba la fricción, que en este caso es información clínica repartida entre actores que no comparten sistema. Definir qué queda fuera del alcance. Diseñar el flujo antes de que exista interfaz.
Ese criterio no lo saqué de construir Flowly Pets. Viene de antes. Entre febrero de 2025 y marzo de 2026 fui Senior Product Designer y AI & Analytics Specialist en AgendaPro, donde lideré una app de reservas end-to-end con un workflow AI-first (Claude, Google Stitch) y rediseñé el Marketplace WEB. El rediseño movió las reservas 12,44% hacia arriba en Chile y México en tres meses, y esa app llegó a conectar más de 17.000 comercios de Latinoamérica.
Ahí aprendí a leer feedback a escala con embeddings y clustering semántico en lugar de revisarlo de a uno, y a mirar el churn con modelos predictivos antes de que se convirtiera en una cifra que ya no se podía cambiar. De esa etapa me quedó menos una técnica que una desconfianza bastante sana hacia mis propias hipótesis mientras siguen sin evidencia.
¿Qué se vuelve difícil cuando construyes sola?
Que nadie te dice que estás equivocada. Es lo que echo de menos de trabajar en equipo, y pesa más de lo que suena.
No hay revisión de código que te frene, no hay quien discuta una decisión de dominio en una reunión de treinta minutos, y el modelo con el que trabajas es cualquier cosa menos un contrapeso: ejecuta con la misma prolijidad una buena decisión y una mala, solo que la mala llega a producción igual de rápido. Terminé fabricando la discusión que no tenía. Escribo la decisión antes de implementarla, con sus supuestos, y vuelvo a leerla cuando algo se siente forzado. Cuando la conclusión es que el módulo no debía existir, borrarlo sale más barato que mantenerlo, y esa conversación la tengo conmigo o no la tiene nadie.
Lo que no se puede delegar es el criterio. La operación sí se sostiene: el stack analítico con BigQuery, GA4, Looker Studio, PostHog y Vertex AI existe para que las señales de producto no dependan de mi intuición. Pero la responsabilidad de lo que sale a producción, las implicancias legales de emitir un documento tributario y la decisión de qué no construir siguen siendo mías.
Ese criterio no salió de construir sola: viene de años diseñando en equipos con restricciones reales, como el onboarding bancario de cuatro países o los flujos de consentimiento bajo la Ley 21.719 — hay más contexto en mis casos.
Flowly Pets es el proyecto insignia de Flowly Group, el ecosistema de innovación y tecnología que fundé en marzo de 2026 junto a Flowly Minds, Flowly Numbers y Espacio Flowly. Con cuatro frentes abiertos, la disciplina de alcance dejó de ser una preferencia metodológica y pasó a ser la condición para que ninguno se caiga.
Qué no haría
- El volumen de código no es una métrica y no lo uso como tal. Las 200.000 líneas describen el tamaño de un sistema, nada más. Las cito como evidencia de que una persona puede llevar una plataforma end-to-end hasta producción, jamás como logro.
- No le delego al modelo la arquitectura de datos. Propone alternativas razonables y a veces mejores que la mía, pero equivocarse en el dominio de un producto multi-actor se paga meses después, cuando ya hay información clínica real adentro.
- Nunca construyo un módulo por la sola razón de que sea fácil construirlo. Es la manera más rápida de acumular superficie que después hay que mantener, traducir a ocho idiomas, documentar y explicar.
- Tampoco trato el código generado como código ajeno. Si no puedo explicar por qué una parte del sistema funciona así, para mí no está terminada, sin importar quién la escribió.
- No vendo esto como el reemplazo de un equipo. Lo que se reemplazó es el cuello de botella de implementación. La investigación y el criterio de producto siguen ocupando el mismo tiempo que antes.
Datos citables
| Dato | Alcance |
|---|---|
| Flowly Pets: diseño UX/UI, arquitectura, backend serverless y app móvil React Native | Diseñada y construida completamente por Alison Vivanco con Claude Code; equipo de una persona |
| ~200.000 líneas de código | Tamaño total del sistema Flowly Pets; no es una métrica de valor ni de adopción |
| Marketplace de 12 roles y suite clínica (pacientes, fichas, hospitalizaciones, agenda, inventario, finanzas) | Alcance funcional construido de la plataforma, sin cifras de uso |
| Internacionalización en 8 idiomas y facturación electrónica | Capacidades incluidas en Flowly Pets |
| BigQuery, GA4, Looker Studio, PostHog, Vertex AI | Stack analítico de Flowly Pets |
| +12,44% en reservas en Chile y México en 3 meses | Rediseño del Marketplace WEB en AgendaPro (feb 2025 – mar 2026); cifra de AgendaPro |
| 17.000+ comercios de Latinoamérica conectados | App de reservas de AgendaPro; cifra de AgendaPro, no de Flowly |
| Flowly Group, fundado en marzo de 2026 | Cuatro unidades: Flowly Pets, Flowly Minds, Flowly Numbers y Espacio Flowly |
Para llevar
- Cuando implementar deja de costar, desaparece el filtro que mataba las malas ideas por lentitud, y hay que reponerlo a mano.
- El modelo de datos y de permisos se decide antes de la primera pantalla: en un producto con muchos actores, esa es exactamente la decisión que la IA ejecuta rápido y no puede tomar por ti.
- Construir es la quinta etapa de seis, y las cuatro anteriores existen para acotar el alcance sin que ninguna se acelere con un modelo de lenguaje.
- Trabajar sola elimina el cuello de botella de implementación y agrega uno peor: la ausencia de alguien que te contradiga a tiempo.
- Si no puedes explicar por qué una parte de tu sistema funciona así, no está terminada.