Build Log

Estaba comenzando a explorar qué podía construir utilizando inteligencia artificial. En lugar de buscar una idea abstracta, pregunté qué partes del trabajo manual sentía que podían mejorar. La conversación coincidió con una preocupación concreta: la persona responsable de caja probablemente tendría que ausentarse durante algunos meses, y eso significaría que mi mamá tendría que volver a asumir personalmente una parte importante de la operación.

Gran parte de la operación todavía dependía de procesos físicos o manuales:

• —cuadernos y papelería
• —menús impresos completados a mano
• —facturas físicas
• —reportes físicos de caja
• —WhatsApp
• —inventario difícil de sistematizar

La elaboración del menú semanal. Mi mamá utilizaba una plantilla impresa y dedicaba aproximadamente 2–2½ horas de un fin de semana a prepararlo. Era una tarea necesaria, repetitiva y que no disfrutaba hacer.

No intentar digitalizar inmediatamente todo el restaurante. Empezar por una tarea frecuente, delimitada y medible.

¿Podría transformar más de dos horas de trabajo manual en una generación asistida de un clic, sin quitarle a la propietaria la decisión final?

Ahí nació la primera idea de Menú IA, que posteriormente evolucionaría hacia Menú Studio.

No necesitaba empezar con una gran idea. Necesitaba encontrar una tarea real a la que pudiera devolverle tiempo.

Convertir la conversación en una primera representación visual del producto.

Diseñé las primeras pantallas y preparé una representación navegable de cómo imaginaba Menú Studio. Todavía no existía lógica real detrás. El objetivo era comprobar si la idea se entendía cuando las personas que iban a utilizarla la tenían delante.

Días después llevé mi computadora táctil a un encuentro familiar en la playa. Cuando mi mamá vio el prototipo llamó a mi papá: “Oye, César, mira, mira esto.” Nos sentamos y le expliqué qué estábamos construyendo. Intentó interactuar con la biblioteca y apareció inmediatamente un problema: las fotografías ayudaban a identificar los platos, pero los nombres no tenían suficiente protagonismo. Su reacción fue: “No veo las letras. No sé cuál es.”

Pregunté si debíamos eliminar las fotografías. Ambos querían conservarlas. El problema no era la imagen: era la legibilidad. Decidimos mantener las fotografías y aumentar la visibilidad de los nombres.

El prototipo todavía no podía generar un menú, pero ya había producido feedback de usuarios reales antes de construir la funcionalidad.

Una interfaz puede ser evidente para quien la diseñó y no serlo para quien tendrá que utilizarla.

La ruta inicial era acelerar la parte visual y después trasladar esas pantallas hacia FlutterFlow. Pero aprender primero una herramienta de diseño y después FlutterFlow añadía tiempo. Desde el comienzo utilicé IA como interfaz de construcción, y con Figma Make pude avanzar visualmente mucho más rápido. Intentamos trasladar ese trabajo hacia FlutterFlow y no funcionó como esperábamos.

En lugar de seguir invirtiendo tiempo en una ruta que no estaba funcionando, evalué construir directamente utilizando Figma Make. La velocidad cambió radicalmente.

Hasta entonces no existía un acuerdo comercial formal sobre el desarrollo. Cuando retomé el proyecto expliqué a mis padres que llevarlo más allá del experimento inicial implicaría costos de construcción. Ambos decidieron continuar e invertir en la solución para sus operaciones.

El proyecto dejó de ser solamente un experimento personal. Los primeros usuarios decidieron asumir los costos necesarios para continuar construyendo una solución destinada a su propia operación.

No debo enamorarme de la herramienta. Debo proteger el objetivo.

Comenzamos con una biblioteca pequeña de aproximadamente cinco platos. El objetivo inicial era conseguir biblioteca → selección/arrastre → generación. Funcionó. Pero apareció el verdadero problema.

La IA podía generar un menú, pero no necesariamente respetaba la lógica real utilizada por la propietaria. La pregunta cambió: de “¿podemos generar un menú?” a “¿podemos generar el menú que esta operación realmente necesita?”.

Antes de ampliar funcionalidades necesitaba capturar mejor el conocimiento experto. Como no podía visitar constantemente el restaurante, mi mamá comenzó a enviarme notas de voz explicando cómo tomaba determinadas decisiones. También recopilé aproximadamente dos meses de menús semanales físicos, creamos inventarios de platos y utilizamos IA para ayudar a identificar patrones. Se realizó también un inventario separado de los menús de mi papá: los restaurantes se parecían, pero no eran idénticos.

Que la IA produzca una respuesta no significa que el producto esté funcionando.

Esta vez no era un prototipo: funcionaba. Le pedí a mi mamá que generara el menú y evaluara qué tan parecido era al que ella habría construido manualmente. Su evaluación fue que estaba casi como si ella misma lo hubiese hecho.

La lógica estaba suficientemente validada para avanzar. Menú Studio todavía tenía deuda visual, especialmente en la presentación final hacia el cliente, pero seguir perfeccionando esa capa habría retrasado la validación del resto de la operación.

Funcional / lógica → aprobada para continuar. Visual → deuda registrada.

No necesitaba que la IA hiciera un menú que me pareciera bueno. Necesitaba que la experta reconociera su propia lógica en el resultado.

• —caja registradora
• —fichas físicas
• —conteo
• —conciliación
• —reportes
• —limpieza y preparación de fichas para reutilizarlas

Nos sentamos mi mamá, mi tía y yo a reconstruir el proceso. Fotografié reportes físicos y utilizamos IA para ayudar a estructurar el flujo antes de construirlo en Figma Make.

Se creó una primera versión digital de caja con venta y ticket. Construir junto a quien ejecutaba el proceso permitió detectar detalles difíciles de descubrir diseñando desde fuera.

Cuando el proceso es operacional, construir cerca de quien lo ejecuta reduce suposiciones.

También existían desayuno y merienda.

Modelar tres jornadas operativas independientes: desayuno → cierre, almuerzo → cierre, merienda → cierre. Cada una necesitaba responsable, apertura, operación, horario, estado, cierre y transición correcta.

Algo que parecía un cambio de botones reveló una necesidad mucho mayor: modelar el tiempo operacional del restaurante.

El flujo está construido en gran parte, pero requiere QA integrado antes de considerarse validado.

Cuando diseño desde una sola situación real, debo comprobar qué otras variantes del mismo proceso existen.

Arroz, platos, cubiertos u otros elementos operativos. Tradicionalmente alguien puede tener que abandonar su posición, caminar hasta cocina, explicar qué falta y regresar.

Se comprobó comunicación entre pantallas para este flujo.

La automatización más valiosa a veces no elimina una gran tarea. Elimina cientos de pequeñas interrupciones.

Cambiar la unidad de QA. De “¿funciona este botón?” a “¿qué ocurre en el sistema después de esta acción?”.

• —jornadas
• —cierres
• —Dashboard
• —estados
• —persistencia
• —integración

Una función no está validada cuando responde al clic. Está validada cuando produce correctamente todas sus consecuencias.

Las operaciones esenciales no deben detenerse por una pérdida temporal de conexión. Conceptualmente: operación local → reconexión → sincronización.

Principio aprobado. Validación técnica integral pendiente.

La disponibilidad también es parte de la experiencia de usuario.

• —los valores deben coincidir con el proceso manual
• —los datos deben persistir
• —los usuarios reales deben poder completar el flujo
• —las transiciones deben ocurrir correctamente

En validación.

El producto funciona cuando el usuario puede completar su trabajo, no cuando terminamos de construir las pantallas.

Completar el día operativo y obtener los mismos valores que el proceso manual.

Operar aproximadamente un mes en paralelo: proceso manual ↔ Restaurant Operations AI.

• —horas ahorradas
• —errores
• —coincidencia de reportes
• —tareas automatizadas
• —facilidad de uso
• —incidencias
• —tiempo que los propietarios pueden permanecer fuera del restaurante
• —feedback real

No pedir confianza. Demostrarla.