Un flujo real, no una guía teórica
Este no es un post teórico. Es mi flujo real de trabajo al construir Foodly OS — el SaaS de gestión para hostelería que estoy desarrollando ahora mismo. No es magia, es método. Y este es el mío.
Lo que más me sorprende cuando comparto este proceso con otros fundadores: esperan que sea complejo o que requiera conocimientos técnicos previos. No los requiere. Requiere claridad de negocio. Y eso es algo que cualquier fundador que conoce su mercado puede tener.
Paso 1: definir el problema de negocio, no el técnico
Antes de abrir Claude Code, escribo en papel qué problema tiene el restaurante, qué datos necesita ver, y qué acción debería poder hacer. Eso es mi brief.
No escribo "necesito una tabla con datos". Escribo: "El dueño del restaurante necesita saber, cada mañana, cuánto vendió ayer por categoría de producto, para detectar si alguna categoría bajó y tomar acción antes del servicio de mediodía."
Esa especificidad es lo que hace que el resultado de Claude Code sea preciso. La IA no adivina lo que necesitas — lo construye exactamente como se lo describes.
Paso 2: dar contexto completo
Le explico qué es Foodly OS, a quién va dirigido, qué stack usamos — Next.js + Supabase — y qué ya existe en el proyecto. Claude Code lee el proyecto entero y trabaja sobre lo que hay, no desde cero.
Esta es la diferencia más importante con otros asistentes de IA: Claude Code no genera código en el vacío. Entiende la arquitectura existente, los componentes que ya tienes, los patrones que ya usas. El resultado es código coherente con el proyecto, no código que tienes que reescribir para que encaje.
Paso 3: describir la funcionalidad como si se la explicara a una persona
"Necesito una pantalla donde el dueño del restaurante vea sus ventas del día, desglosadas por categoría de producto, con la posibilidad de filtrar por fecha." Eso es todo.
No digo qué queries SQL hacer. No digo qué componente React crear. Digo qué necesita el usuario y para qué lo necesita. Claude Code decide la implementación.
Paso 4: revisar antes de ejecutar
Claude Code me muestra el plan antes de tocar el código. Ahí es donde más aprendo: entiendo qué va a hacer y por qué. Si algo no tiene sentido para el negocio, lo corrijo antes de que escriba una línea.
Este paso es crítico y muchos lo saltan. Revisar el plan antes de ejecutar me ha salvado de implementaciones que técnicamente eran correctas pero que no resolvían el problema real del usuario.
Paso 5: probar en el navegador como usuario real
Abro localhost, uso la funcionalidad como si fuera un restaurante real y anoto qué falta o qué no encaja. Vuelvo a Claude Code con feedback concreto.
"El filtro de fecha no hace nada visible cuando lo cambio." Eso es feedback accionable. "Esto no está bien" no lo es. Cuanto más concreto el feedback, más precisa la corrección.
Dónde falla el método
Cuando el brief es vago. Si le digo "hazme un dashboard", el resultado es mediocre. Si le digo exactamente qué dato, para qué usuario y qué decisión le ayuda a tomar, el resultado es preciso.
El método no es secreto. Es el mismo que cualquier buen Product Manager usa con su equipo. La diferencia es que ahora Félix Molina puede aplicarlo solo, en tiempo real, sin depender de nadie.
Lo que este flujo ha cambiado en Foodly OS
En términos prácticos: el tiempo entre "tengo una idea de feature" y "el feature está en producción y funcionando" ha pasado de semanas a horas. No porque Claude Code sea mágico, sino porque la combinación de claridad de negocio + herramienta de IA correcta + método repetible elimina la fricción.
Foodly OS avanza hoy a una velocidad que no habría sido posible hace dos años, incluso con un equipo técnico. La ventaja no está en la tecnología — está en el método.