Amora es la empresa de joyería que tengo con mi novia. Ella la dirige (es la CEO) y yo estoy a cargo de lo digital: web, publicidad y sistemas de gestión.
Desde hace algunos meses arrastrábamos dificultades para mantener nuestros registros actualizados debido a la evolución de nuestra operación, pero siempre las postergábamos porque tomaría tiempo que, como en cualquier negocio pequeño, es lo que más falta.
Así nació Mora, el sistema que hoy reemplaza todo lo que teníamos antes. Estas son las decisiones tomé para que el sistema sirviera al negocio y no al revés.
Habíamos rebasado Google Sheets
Amora arrancó en Google Sheets. Mientras validábamos el negocio, bastaba: comprar productos, venderlos y enviarlos era toda la operación. Luego empezamos a vender más y a producir algunos productos, y llenar a mano tablas nos generaba inconsistencias. Además, necesitábamos consultar datos desde el celular mientras estábamos fuera. Entonces migramos a AppSheet que nos dio una interfaz que podíamos usar desde una laptop y desde el celular.
AppSheet nos permitió registrar rápidamente sin saltar de archivo en archivo con una validación básica de datos, pero pronto quedó chico también. Con la meta de que el 75% de productos sean propios, aparecieron insumos que debían consumirse al crear productos, productos set que consumían otros productos, diferentes comisiones según el canal de venta: complejidades a las que una interfaz armada sobre hojas de Google Sheet no se adaptaba.
A eso se sumaron problemas técnicos. AppSheet depende excesivamente del caché lo que producía desfases entre dispositivos. Por otro lado, las operaciones complejas tardaban varios minutos: una venta con varios productos, comisiones y envío podía tardar unos 5 minutos solo en guardarse.
AppSheet nos obligaba a tener un sistema basado en la estructura de las tablas. Con Mora, nuestros modelos mentales definen la experiencia.
También teníamos problemas de fondo. Por la premura al construir las tablas, no seguíamos buenas prácticas: usábamos el último costo en lugar del costo promedio ponderado (CPPM); y los pesos, críticos en joyería, vivían en tablas aparte. Cada vez que necesitábamos una nueva capa, la agregábamos en tablas satélite para no romper nada, usando Google Forms como interfaz.
Por qué construimos en vez de comprar
Antes de escribir código tuve que decidir entre una herramienta que ya existiera o algo propio. Elegí construir por razones prácticas, no por el gusto de tener mi propio SaaS.
Primero, un cálculo de negocio simple. Contratar un plan de IA para usarlo en múltiples tareas era una decisión tomada y usarlo también para construir no representaba un costo adicional, mientras que contratar un SaaS habría significado un gasto extra.
Segundo, nos permite continuidad operativa y una curva de aprendizaje mínima. Con AppSheet habíamos tenido que adaptar nuestros procesos a la estructura de las tablas; con un sistema propio podíamos adaptar el sistema a nuestro modelo operativo. También reducía el tiempo de migración y el riesgo de pérdida de información de transformar los datos a una nueva estructura.
En el fondo, la pregunta clave fue quién se adapta a quién.
Finalmente, nos permite tener 100% control sobre la arquitectura. Nos da la flexibilidad de adaptar la plataforma a la evolución del negocio. Hace algunos años, mantener una plataforma cambiante habría sido una carga económica y operativa considerable; hoy basta con decirle a una IA qué regla de negocio queremos, pedirle que analice el impacto y proponga un plan de trabajo, e ir refinando desde ahí. Además, el sistema está pensado para que migrar a una base de datos SQL sea un cambio de conexiones, no una reconstrucción.
Claude para pensar, Codex para construir
El problema central no era entender a los usuarios (nosotros mismos), sino migrar sin perder datos ni generar reprocesos mientras seguíamos vendiendo. La planificación era clave antes mover anda y por eso usé un enfoque Spec Driven Development: un roadmap alto nivel, decisiones documentadas en specs, un backlog de tareas para construir.
A Claude le di los problemas abiertos: refinar el modelo de datos, definir la arquitectura técnica, redactar las especificaciones. Cumplió también un rol de contraparte crítica, cuestionándome y encontrando vacíos en las reglas de negocio que le iba planteando. También lo usé para investigar el stack más recomendado para el entorno de Apps Script y terminé decidiendo usar Vue, Tailwind y Typescript. A Codex le di las instrucciones cerradas: desglosaba las specs en tareas concretas y escribía el código.
Parecía un workflow sólido para el alcance, pero pronto descubrí que cuando una IA te dice cuál es la mejor práctica a seguir, no quiere decir que la vaya a seguir. Claude me proponía, en la misma conversación, el patrón correcto para resolver algo y al generar la documentación reproducía el problema que trataba de evitar. Al refinar el modelo de datos, por ejemplo, insistía en persistir una tabla cabecera para el inventario que existía solo para que AppSheet pueda mostrar una interfaz más intuitiva y que Claude definía como innecesaria en la nueva plataforma. Algo parecido pasó con el CPPM: propuso registrarlo en ‘Producto’ pese a ser dominio de ‘Inventario’ y de haberme dicho que es una mala práctica registrar campos calculados de una entidad en otra.
La IA acelera, pero puede acelerar el desorden si no eres capaz de definir con claridad a dónde quieres llegar.
El contexto debe guiar la priorización
Definimos 5 módulos para el MVP: ventas, productos, insumos, CRM y finanzas. Los inventarios embebidos en los catálogos de productos e insumos.
Cuando le pregunté a la IA por dónde empezar a construir, sugirió lo más lógico desde el punto de vista técnico: catálogos primero (productos, insumos, proveedores, etc.), registros de operación luego. No le hice caso porque no tenía sentido para nosotros. En la operación real de Amora, esas tablas cambian poco: un producto se crea una vez y después se modifica poco. Lo que sí se mueve todos los días son las ventas y gastos, y ahí teníamos cola acumulada esperando pasar a la nueva base de datos. Ahí estaba el mayor valor en el contexto del negocio que la IA no podía comprender y que tampoco valía la pena explicarle.
Por otra parte, el módulo de productos resultó ser el más complejo de todos los catálogos por las variantes, los sets, los insumos y los costos cruzados entre ellos. Resolver ahí los patrones difíciles primero significaba que después podía simplificarlos para catálogos más sencillos.
Con esas condicionantes en mente, mi novia y yo armamos el backlog y lo priorizamos en función del valor para el negocio. La primera fase del roadmap fue: ventas, finanzas y productos. Luego lo demás.
Adiós Figma, hola vibedesign
Hice un par de pruebas en Figma Make para explorar cómo se podía ver la interfaz y después no volví a abrir Figma para este proyecto. No porque Codex reemplace a un diseñador experto, sino porque el experto a cargo (o sea, yo) podía permitírselo.
Entre los años trabajando la marca y varios más construyendo interfaces de forma sistémica, decidí que podía saltarme el paso de diseñar en una herramienta visual e ir directo a vibecodear los componentes. Inicié los archivos design.md y voice.md donde fui volcando los lineamientos de marca que hasta entonces vivían entre Notion y mi memoria, y tomando las decisiones que hacían falta. La prioridad era tener algo bien estructurado (tokens, componentes y layouts, nada hardcodeado) funcionando antes que algo pulido. Sespués del primer release empecé a editar la interfaz visual ajustando jerarquía, layouts y aplicación de colores.
También hice algo que casi nunca tengo oportunidad de hacer, aunque se lo pido constantemente a mis alumnos: un mapa completo de arquitectura de la información. En un sistema con gran volumen de datos y tan interconectado, donde una venta toca productos, empaques, canales, comisiones y contabilidad al mismo tiempo, ese mapa guió a la IA en la traducción de specs técnicas a una interfaz y a mí me sirvió para identificar las necesidades de pantallas, formularios y componentes.
Todo bonito en local, hasta que hice deploy
La construcción iba razonablemente bien hasta hice el primer deploy. Falló. Después de corregir los errores, la carga inicial de apenas 360 filas del catálogo de productos tardaba más de 3 minutos.
El error fue mío: asumí que Codex sabía lo que hacía, pero sin lineamientos claros había programado múltiples llamadas a las mismas tablas para construir las vistas resumen. En local no se notaba porque usaba servicios mock tan rápidos que había tenido que introducir un retraso artificial para poder ver los estados de carga en pantalla. Para resolverlo de forma sostenible, le pedí que busque las mejores prácticas para Google Apps Script y las agregue a la documentación del proyecto para aplicarlas desde el inicio en los demás módulos.
Delegar la ejecución no debe significar delegar el criterio
Lo que cambió en la operación
El sistema entró en producción en una semana y lo fuimos refinando en la semana siguiente. Hoy reemplaza al 100% a AppSheet, a todas las hojas y formularios periféricos y, además, suma la conexión con WooCommerce que antes no existía. El dashboard sigue viviendo en Google Data Studio por ahora, y queda un backlog de mejoras esperando ser priorizado.
Las horas perdidas con el sistema anterior las habíamos medido antes de migrar para tener una línea base con la cual comparar. Este es el impacto de Mora:
56% menos errores de inventario. Antes, los cruces de inventarios de insumos y de productos eran manuales.
Registrar los empaques consumidos en cada venta tomaba 90 segundos de carga manual, uno por uno. Ahora toma 5 segundos con un spinbox en la misma pantalla de venta.
Una venta que antes tomaba 6 a 7 minutos entre registro y guardado, ahora toma segundos: las ventas de WooCommerce se registran solas, y lo único que queda es verificar y aprobar la comisión del canal.
Cada venta ya no exige transcribir datos al formulario de envío de boletas ni al sheet de seguimiento de envíos, lo que ahorra otros 2 minutos por venta que antes se iban en retrabajo.
De paso, incorporamos cosas que no teníamos: costo promedio ponderado móvil, peso promedio integrado en el inventario y un P&L devengado que se construye al instante en vez. Información que nos ayuda a planificar la producción con más precisión.
La IA puede escribir código, proponer arquitecturas y hasta explicarte las mejores prácticas, pero decidir qué modelo mental representa mejor tu negocio sigue siendo un trabajo humano.
