Llegué a Chile empezando de cero (algún día escribiré sobre eso). Como no hablaba español, puse la mirada en el barrio chino. Ahí entendí de verdad algo que había escuchado hace mucho: los productos no crecen en los estantes.
Después de conversar un tiempo con los comerciantes, empecé a entender cómo funcionan casi todas las tiendas de la zona: locales físicos que venden al por mayor y al detalle a la vez.
Día a día cuentan mercadería, la ordenan, la ponen en el estante, la despachan, administran la bodega y reponen. Las que aún no están consolidadas además tienen que sacar fotos, ingresar los datos de los productos, manejar los canales online y gestionar a los clientes.
Justo eso es lo que sé hacer. Así que me asocié con una tienda cuyo negocio mayorista estaba madurando, pero que no lograba abrir un canal mayorista online, y puse en marcha el proyecto neo-studio.
A continuación lo presento principalmente desde el punto de vista del producto.
S · Situación: el problema de publicar productos en una tienda de variedades
La tienda vende de todo un poco: ollas, calcetines, paraguas, perfumes, artículos de papelería… Cada envío trae un montón de productos nuevos que hay que publicar, y aquí “publicar” incluye los canales online.
Publicar es tedioso de una forma muy particular:
- Ingreso de datos: código, código de barras, nombre (uno en chino y otro en español), especificaciones y unidades por caja, producto por producto.
- Fotos: se sacan al paso sobre el mostrador, con una mesa desordenada de fondo y una luz inestable. Las fotos no se pueden mostrar tal cual a los clientes.
- Distribución: el mismo producto hay que ingresarlo en varios lugares — la tienda de WeChat (Yougou), las tiendas de Facebook / Instagram, el sitio web propio y el ERP de la tienda.
- Armado de pedidos: a veces el personal no encuentra la mercadería en la lista de picking — las fotos de la lista son diminutas y no indican la ubicación en bodega.
Ningún paso es difícil, pero juntos hacen que un solo envío tome varias horas. Los datos quedan dispersos y, después de sacar las fotos, hay que ordenarlo todo contra los datos; cambiar un precio implica editar varios lugares.
T · Tarea: los objetivos que me fijé
Lo que quería no era “una planilla mejor”, sino conectar toda la cadena:
- Ingreso rápido: el personal escanea y fotografía con su propio celular, varias personas pueden ingresar a la vez y no hace falta una pistola lectora.
- Imágenes atractivas: muchas tiendas no tienen equipo fotográfico profesional ni quien retoque. Por eso decidí usar IA para convertir fotos casuales del mostrador en imágenes de producto profesionales: fondo blanco, varios ángulos, con especificaciones y código de barras.
- Ingresar una vez, usar en todas partes: mantener los datos en un solo lugar y sincronizarlos con todas las plataformas de venta con un clic.
- Fácil de operar: con una breve capacitación, el personal debe poder usarlo en el día a día.
- Ayudar al armado de pedidos: imprimir códigos de barras en la lista de picking; cuando una foto no se ve bien, se escanea para ver la información del producto y su ubicación, y se puede ampliar para ver detalles. Cuando varias personas arman un pedido juntas, todas pueden ver qué ha encontrado ya el resto.
Además había dos restricciones reales: para ganarme la confianza del dueño, los datos tenían que quedarse en local; y el ERP que ya usaba la tienda no tiene API externa.
A · Acción: cómo lo hice
Primero, la arquitectura general. El diagrama de abajo es interactivo: haz clic en cualquier nodo para ver qué hace y qué tecnologías usa:
主工作台：产品网格、详情抽屉、AI 批量渲染与精调、排版模板编辑、订单与平台同步。任务队列和进度通过 WebSocket 实时推送。
点击节点查看细节 · 节点可以拖动
Todo el sistema se organiza en torno a tres cosas: ingreso, producción y distribución.
Ingreso: el celular es la pistola lectora
El lado del celular es una página React independiente, a la que el personal accede por HTTPS dentro de la red local de la tienda.
Al escanear un código de barras se completa solo el código del producto, las fotos se suben directamente y los nombres en chino y español, las especificaciones y las unidades por caja se llenan de una sola vez. Varias personas pueden ingresar al mismo tiempo, y los productos terminados aparecen en el PC en tiempo real.
Producción: de una foto al paso a una imagen comercial
El lado del PC se llama Neo Studio y es el espacio de trabajo principal.
Todos los productos se muestran en una cuadrícula. Los tres puntos bajo cada tarjeta indican el estado de renderizado de las vistas hero / side / detail:
Al abrir un producto se ven las fotos originales, las tres vistas generadas por IA y la imagen compuesta final.
Si una vista no convence, se puede regenerar con un clic o refinar con una instrucción de texto:
Esta es la grabación real de una “regeneración”: primero se mira la foto original y luego se regenera la vista 2; en unos diez segundos llega una imagen nueva y la composición se actualiza sola:
Las vistas generadas se combinan al final en la imagen terminada según una plantilla de diseño. La plantilla define dónde va cada vista, cómo se disponen el nombre y las especificaciones y dónde van el código de barras y el logo de la tienda.
La plantilla también se edita de forma visual:
Distintas categorías pueden usar distintas plantillas, por ejemplo esta, que agranda la vista principal y deja el detalle a la derecha:
Generar se reduce en el fondo a dos operaciones: Generate (generación nueva, sin contexto) y Refine (modificar a partir del resultado anterior).
En la interfaz, “regenerar” y “refinar” corresponden a estas dos.
Lo difícil de refinar es “recordar la vez anterior”: si solo se envía la imagen previa como una referencia cualquiera, el modelo no sabe que es lo que él mismo acaba de dibujar.
Cuando Gemini devuelve una imagen incluye una thought signature, que representa el estado interno de ese turno. Si se la devuelves junto con la conversación anterior, el modelo sabe de verdad que “esto es lo que dibujé la vez pasada y ahora lo voy a modificar”, en lugar de dibujar otra desde cero.
Cada categoría necesita prompts de generación distintos (¿el paraguas va abierto o cerrado?, ¿el perfume lleva su caja?).
Ya no ajusto estos prompts a punta de prueba y error: dejo que lo haga la IA. Escribo el prompt en la base de datos, lanzo un render, miro la imagen generada directamente con la API de Gemini, juzgo qué está mal, reescribo el prompt y repito; cuando converge, lo archivo en el código.
Es como dejar que la IA sea su propio juez. A este proceso lo llamo laag.
Su ventaja no es ahorrar tiempo, sino que, a diferencia del ajuste manual, no vas ajustando y olvidando los errores que ya cometiste.
Además, los prompts de cada categoría se convierten en un activo de datos valioso: si algún día esto se vuelve un producto SaaS, sería una barrera de datos importante.
Aquí van comparaciones antes/después de otras dos categorías. A la izquierda, la foto original del gestor de imágenes de referencia; a la derecha, el resultado compuesto automáticamente (el paraguas recibe una vista principal abierta más una vista de detalle cerrado; el utensilio de cocina suma además una escena de uso con la mano):
Distribución: un solo ingreso, sincronización con varias plataformas
Todos los datos viven en un único lugar: una base SQLite local.
Cada plataforma externa tiene su propia capa de integración en el backend: una para Yougou, una para el catálogo de productos de Meta y una para el CMS del sitio web de la tienda.
Cada capa traduce los campos locales a los de la plataforma y registra si ambos lados se han “desfasado”.
Las tres plataformas se comportan de forma totalmente distinta. Yougou no tiene API abierta, así que la integración lee y escribe directamente en su base de datos; los códigos de producto vienen de los códigos de la tienda, que no están garantizados como únicos, por lo que en caso de duplicado se agrega el ID del producto como sufijo (por ejemplo r00008_61); si no, dos productos se sobrescribirían entre sí en Yougou. Que la API del catálogo de Meta responda con éxito solo significa que recibió la solicitud: la revisión es asíncrona, y para saber si el producto realmente aparece en la tienda de Facebook / Instagram hay que consultar aparte el estado de revisión y escribirlo de vuelta. La sesión del sitio web de la tienda es un JWT que vence en una hora, y yo lo renuevo de forma proactiva en el minuto 50 en lugar de esperar a que una solicitud falle.
El ERP de la tienda no tiene interfaz pública, así que, como pidió la tienda, me conecto directamente a los datos del negocio en la máquina local, y mantuve la importación manual por Excel como respaldo: cuando la integración falla, el negocio no se detiene.
Etiquetas de dimensiones del producto
Aquí se ve la ventaja de ingresar los datos en un solo lugar: durante el ingreso el personal ya completa todos los datos que necesitamos, así que no hay que reunirlos aparte. Al etiquetar, podemos traer directamente desde la interfaz las dimensiones ya ingresadas y anotarlas rápido sobre la imagen.
P.D.: mi primer trabajo fue como ingeniero estructural, y lo que hacía sobre todo era acotar en CAD y Creo, mantener planos y sincronizar datos entre PLM y Excel. Ahora que construí yo mismo un sistema así, no puedo evitar sentirme un poco orgulloso (｡•̀ᴗ-)✧
Armado de pedidos: se acabó buscar con fotos diminutas
Los pedidos mayoristas suelen ser una larga lista de “qué producto y cuántas cajas”. La antigua lista de picking solo tenía líneas de texto y fotos muy pequeñas, y el personal muchas veces no encontraba la mercadería.
Ahora, una vez creado el pedido en el sistema, se puede imprimir con un clic una lista de picking con fotos, nombres en chino y español, código, unidades por caja y código de barras:
Lo que el personal tiene en las manos es esta hoja: la foto a la izquierda, el nombre al centro, el código de barras y la cantidad a la derecha, y una última columna para marcar:
Ante un producto cuya foto no se ve bien, el personal saca el celular y escanea el código de barras para ver la información del producto y su ubicación, y ampliar los detalles.
Cuando varias personas arman el mismo pedido, cada una toca OK o Falta en su celular y las pantallas de las demás se actualizan en sincronía, de modo que se ve claramente quién encontró qué y qué falta todavía:
Hacer que funcione en la tienda
Por último, Electron empaqueta todo el sistema en un único exe: al hacer doble clic se inicia el backend local, que a su vez sirve las páginas del PC y del celular.
El computador de la tienda no necesita ningún entorno de desarrollo (más adelante escribiré un artículo aparte sobre los problemas del empaquetado).
También le hice un servidor MCP que expone la base de productos como herramientas que una IA puede invocar: consultar productos, iniciar renderizados por lotes, refinar una vista concreta.
Para el mantenimiento rutinario, muchas cosas se pueden delegar a un LLM en lenguaje natural. Pero, dada la capacidad de pago del cliente, no he abierto esta parte para ellos; por ahora solo yo puedo usarla.
R · Resultado
Lo más evidente son las imágenes. A la izquierda, una foto casual sacada por el personal sobre el mostrador; a la derecha, la imagen terminada que el sistema genera y compone automáticamente: fondo blanco, varios ángulos, con volumen, código, código de barras y el logo de la tienda:
- El sistema ya se usa a diario en la tienda: ayudó a montar rápidamente los canales de venta online y a la vez gestiona la bodega física y la reposición.
- Publicar un envío pasó de días a minutos.
- Los datos se mantienen una sola vez y sincronizar con cada plataforma toma un clic.
- El armado de pedidos ya no depende de adivinar con fotos diminutas; con el escaneo de códigos y la sincronización entre varias personas, los productos omitidos o equivocados bajaron notablemente.
- Ayudó a la tienda a construir activos de datos (una base de productos y plantillas de generación por categoría), lo que reduce el costo de desarrollo de un eventual sitio propio o de análisis de datos.
- Gané el dinero que necesito para sobrevivir en Chile (๑•̀ㅂ•́)و✧
Menos mal que dejé una salida: el modelo de IA “caducó”
Un día la tienda avisó de que la generación de imágenes con IA había dejado de funcionar: “regenerar” fallaba siempre. Abrí el proyecto y encontré dos problemas apilados:
- Nombre del modelo: el proyecto seguía usando el nombre de vista previa de un modelo de imágenes de Gemini (terminado en
-preview). La versión estable ya había salido y los nombres de vista previa tarde o temprano se retiran, así que lo cambié todo al nombre estable y reuní el nombre del modelo en un único lugar. - Cuota: tras cambiar a una clave nueva, la API devolvió 429: el nivel gratuito de AI Studio tiene cuota 0 para los modelos de generación de imágenes. Al final pasé el backend a Vertex AI (el modo sencillo con clave de API, facturado a través de GCP).
Pasar a Vertex también destapó un problema en cadena: el proyecto subía las imágenes de producto a la File API de Gemini para tener una caché de 47 horas, y Vertex no tiene esa API. Por suerte la caché se había diseñado como opcional (cualquier fallo de caché vuelve automáticamente a incrustar las imágenes), así que solo hubo que omitir la caché bajo Vertex, sin cambiar ni una línea de la lógica de renderizado.
De la misma forma, si algún día el ERP de comercio electrónico que usa la tienda llegara a fallar, puedo usar el modo de respaldo por Excel: que exporten, desde mi sistema, un Excel con el formato que su ERP necesita y sincronicen los datos así. Solo tendría que modificar esa capa de compatibilidad.
Próximamente
Este artículo está escrito principalmente desde el punto de vista del producto y no entra en detalles técnicos. Los siguientes tratarán la parte técnica: decisiones de diseño, la base de datos, la cola de tareas y el empaquetado con Electron.