Portafolio / ERP operativo a la medida
El sistema operativo de una boutique omnicanal.
Curvy Boutique vende en su tienda de Bucaramanga, en la web, por WhatsApp y por Instagram. Diseñamos y construimos un ERP móvil que conecta inventario por talla y color, ventas, pedidos, clientas, producción, caja, facturación y marketing, sin duplicar la operación de WooCommerce.

01El reto
Complejidad de empresa grande, equipo de boutique.
Una boutique omnicanal pequeña tiene los problemas de una cadena: prendas que existen en seis tallas y varios colores, un mismo stock para el mostrador y la web, pagos mixtos, apartados que llegan por WhatsApp, pedidos que hay que empacar y despachar, talleres que entregan producción y una factura electrónica que la DIAN exige. Todo eso, administrado entre WordPress, hojas de cálculo y servicios sueltos.
El riesgo central era el inventario. Un segundo sistema con su propio stock habría dado dos verdades a la primera venta simultánea. Por eso no creamos otra base de existencias: WooCommerce sigue siendo la fuente de verdad y el ERP se diseñó alrededor de contratos, auditoría e idempotencia.
Lo que había que coordinar
- 01Productos variables por talla y color
- 02Stock compartido entre tienda física y web
- 03Ventas en mostrador con pagos mixtos
- 04Apartados por WhatsApp e Instagram
- 05Pedidos web, empaque y despacho
- 06Producción con talleres
- 07Caja, promociones y reportes
- 08Facturación electrónica colombiana
- 09Correos, campañas y newsletter
- 10Roles distintos para dueña y vendedora
Nuestro rol
Descubrimiento y modelado de la operación, arquitectura, diseño de producto y sistema visual, desarrollo frontend y backend, integraciones, automatizaciones, pruebas, documentación y estrategia de despliegue.
02La regla
La decisión que ordenó todo el sistema.
Un solo inventario. WooCommerce manda.
WooCommerce conserva catálogo, variaciones, precios, stock y pedidos. La base propia guarda solo lo que la tienda no modela bien: usuarias, clientas de mostrador, movimientos, auditoría, producción, caja, facturas, campañas y eventos de sincronización. El ERP registra cada movimiento, pero nunca descuenta dos veces.
Sobre esa regla, cuatro principios de producto: pensado para el piso de venta y no para un escritorio, con el vocabulario de la tienda, una sola fuente de verdad y una operación que no se detiene si falla un servicio secundario.
Móvil primeroLenguaje de tiendaUna fuente de verdadFallar bien
03Diseñar alrededor de la operación
Una herramienta de la marca, no software de bodega.
Para operar con una mano.
La navegación inferior prioriza Inicio, Productos, Vender y Pedidos. Cada objetivo táctil mide 48 px o más, los campos usan 16 px para que el iPhone no haga zoom y los recorridos críticos se prueban a 390 px.
Como habla la dueña.
Apartado, Pagado, Empacado, Enviado, Entregado. «Conté las prendas», «Entró mercancía», «Deshacer». La complejidad de los estados y metadatos de WooCommerce queda detrás de ese vocabulario.
La venta nunca espera.
Vender no depende de n8n, un correo fallido no cancela una venta, una factura rechazada queda para reintentar y la IA cae a reglas locales si no responde. Lo secundario se recupera después; el mostrador sigue.
04Flujos principales
Tres historias que pasan todos los días.

Buscar la prenda, elegir color y talla con lo que queda a la vista, revisar el carrito y cobrar repartiendo el total entre efectivo, datáfono, nequi, transferencia. Antes de cobrar, el servicio relee el stock en WooCommerce: si la talla se agotó en la web un segundo antes, la venta se detiene con un aviso, no con un descuadre.

Tocar una celda de la matriz, sumar o restar, elegir el motivo —obligatorio— y guardar. Durante unos segundos aparece «Deshacer», solo para quien hizo el cambio. Cada ajuste queda como movimiento con autor y fecha.

Lo vendido hoy por canal, los pedidos por despachar y el detalle de cada uno con sus prendas, el pago, la clienta y el siguiente paso. Un apartado retiene el inventario en WooCommerce hasta que se paga o se cancela.

El stock de una prenda en un vistazo: agotado en rojo, una o dos unidades en ámbar, tres o más en verde. Debajo, los movimientos —cada venta, entrada o ajuste— con quién lo hizo y desde qué pedido.
05Arquitectura sin duplicar stock
Qué pasa cuando se cobra una prenda.
Arquitectura hexagonal pragmática: ninguna pantalla habla con un proveedor. Los servicios de dominio validan, revisan permisos y auditan; los puertos —comercio, facturación y correo— tienen un adaptador real y uno simulado, así que el mismo código corre contra la tienda o contra su doble.
Panel PWA
Dueña y vendedoraServicios
Reglas · permisos · auditoríaWooCommerce
Catálogo, stock y pedidosNeon
Movimientos y auditoríaSIIGO
Factura electrónican8n
Sincronizar y conciliar
- 01
La vendedora cobra
Una Server Action valida el carrito y los pagos, y comprueba que la usuaria tenga permiso para vender.
- 02
Stock fresco
El servicio relee las variantes en WooCommerce sin caché. Si una talla se agotó, devuelve un conflicto que la pantalla sabe explicar.
- 03
WooCommerce crea el pedido
La tienda crea el pedido y descuenta el stock. Es la única que lo descuenta.
- 04
El ERP registra
Movimiento por talla y color y entrada de auditoría en la base propia, con quién, cuándo y desde qué pedido.
- 05
Factura y comprobante
Si la clienta la pide, SIIGO emite con una clave de idempotencia por pedido. Si falla, la venta sigue y la factura queda para reintentar.
- 06
De noche, conciliación
A las 02:00 de Bogotá, n8n compara WooCommerce con el último movimiento y registra cualquier diferencia.
La primera conciliación real cubrió 42 productos y 463 combinaciones talla × color. Es el alcance de la sincronización, no el tamaño definitivo del catálogo.
06Diseñado para fallar bien
Lo que separa un ERP de un dashboard.
El sistema se construyó sin tocar la tienda real: una tienda WooCommerce simulada con productos, variaciones, pedidos, cupones y los mismos errores que la API de verdad, y una suite de contrato que corre igual sobre el doble y sobre la tienda.
Live empieza sin escribir.
Conectado a la tienda real, el panel arranca en modo de solo lectura: cualquier escritura se bloquea antes de salir a la red hasta que se habilita a propósito.
Reintentar no duplica.
Webhooks, facturas, correos, recepción de producción y movimientos llevan su clave: un evento repetido se reconoce y se descarta. Lo que falla se reprocesa cada 15 minutos, hasta cinco veces.
Sin pisar una venta web.
La API estándar no suma ni resta stock de forma atómica, así que construimos un mu-plugin pequeño que lo hace en WordPress. Sin él, el panel lee, verifica, escribe y reintenta una vez.
Cada cambio tiene autor.
Las escrituras relevantes dejan movimiento o auditoría, un producto se crea con todas sus variaciones o no se crea, y lo archivado se recupera: nada se borra de forma destructiva.
07El resto del día
Caja, reportes y todo lo demás.

Ventas por periodo, canal y talla, con recomendaciones estructuradas. La misma fuente analítica alimenta Inicio, Caja, Reportes y el asistente; si no hay modelo de IA disponible, las recomendaciones salen de reglas.

El día de la tienda, en hora de Bogotá, separado por medio de pago y con los pagos mixtos desglosados. El efectivo esperado contra el contado, y los cierres anteriores guardados.

Promociones con precio rebajado y cupones, campañas por correo según el objetivo, producción con talleres, facturación electrónica y un centro de ayuda con guías por tarea. Todo bajo «Más», sin estorbar a la venta.
08Ecosistema conectado
Cada integración, con un oficio.
La fuente de verdad.
Catálogo, variaciones, precios, stock, pedidos y cupones. El ERP es su interfaz operativa y su capa de reglas, no una réplica.
Lo que Woo no modela.
Clientas de mostrador, movimientos, auditoría, producción, caja, facturas y campañas. PGlite en local, Neon en producción.
Sincronizar sin guardar datos.
4 flujos: Woo → ERP, reintentos, conciliación nocturna y respaldo semanal privado. n8n no guarda claves de la tienda ni datos de clientas.
Factura electrónica.
Emisión manual o automática para pedidos pagados que la requieren, con cédula o NIT, IVA incluido y CUFE guardado.
Correo transaccional y campañas.
Comprobantes, apartados, envíos y campañas segmentadas por consentimiento, con dominios separados para proteger la reputación.
IA que lee, no que actúa.
Un asistente y recomendaciones con herramientas de solo lectura, cuotas diarias y datos de clientas anonimizados. No mueve stock ni cambia precios.
Sesiones y roles.
Inicio de sesión sin registro público, sesión persistente opcional y permisos distintos para dueña y vendedora.
Despliegue y respaldo.
El panel corre en Vercel, y el respaldo semanal se guarda en almacenamiento privado con doce semanas de retención.
09Seguridad y privacidad
Menos wp-admin, menos exposición.
La dueña y la vendedora ya no necesitan entrar a WordPress ni conocer una sola credencial. Las claves de la tienda, la facturación, el correo y la IA viven solo en el servidor; los permisos se revisan en cada página y en cada acción, y la vendedora no ve lo que no le corresponde.
La privacidad se diseñó como parte del producto: la autorización de tratamiento de datos es obligatoria para guardar a una clienta, el consentimiento de marketing es una decisión aparte y se respeta la baja desde cualquier correo. Lo que se envía a la IA sale sin datos personales.
El modelo
- 01Registro público deshabilitado
- 02Sesión en cookie httpOnly
- 03Bloqueo tras cinco intentos fallidos
- 04Permisos por rol en rutas y acciones
- 05Webhooks firmados e idempotentes
- 06Consentimiento de marketing separado
- 07Datos anonimizados hacia la IA
- 08Auditoría de operaciones sensibles
10Evidencia de profundidad
Alcance técnico, no resultado comercial.
Cifras contadas sobre el repositorio. Describen el tamaño de lo construido; ni ventas, ni horas ahorradas, ni adopción, que se medirán cuando el sistema lleve tiempo operando.
- 22
- tablas propias, todas con tenant_id para más de una tienda
- 18
- guías de ayuda que lee también el asistente
- 82
- componentes de interfaz
- 28
- archivos de prueba, con recorridos E2E a 390 px
- 4
- flujos de automatización en n8n
- 463
- combinaciones talla × color en la primera conciliación real
11Estado real
Construido, probado y encendiéndose por etapas.
Está construido y verificable en código: navegación, roles y PWA; catálogo, inventario, punto de venta, apartados, pedidos y clientas; producción, promociones, caja y reportes; facturación, marketing, newsletter, asistente y ayuda; webhooks, conciliación, reintentos y respaldo, con sus dobles simulados y sus pruebas.
Con la infraestructura real ya se probó la lectura del catálogo, los webhooks de la tienda pasando por n8n hasta el panel y la conciliación de 463 combinaciones. El respaldo semanal está configurado en almacenamiento privado de la tienda.
Lo que falta se activa de forma gradual, a propósito: instalar y validar el puente de stock atómico en la tienda, habilitar la escritura tras pruebas controladas, verificar los DNS del correo, validar SIIGO con la cuenta real y la contadora, el conteo físico inicial y la capacitación con la primera semana acompañada.
Pendiente
- 01Puente de stock en la tienda real
- 02Escritura sobre WooCommerce
- 03Correo live tras verificar DNS
- 04SIIGO con cuenta real y contadora
- 05Conteo físico inicial
- 06Reglas por confirmar con la dueña
- 07Capacitación y primera semana
12El resultado
Lo que cambia cuando la operación se ve.
Una base trazable para crecer.
El resultado es una plataforma que hace visible la operación completa de la boutique y permite crecer sobre una base trazable, probada y conectada con el canal de venta existente.
Un solo panel en el celular reemplaza recorridos dispersos por WordPress y herramientas separadas, y cada talla y color puede seguirse movimiento a movimiento.
VisibleTrazableConectado
beleafdesign
¿Tu operación vive entre hojas de cálculo y paneles que nadie quiere abrir?
Diseñamos sistemas a la medida que trabajan con lo que ya usas en vez de reemplazarlo. Podemos revisar cómo opera hoy tu negocio y qué debería verse en una sola pantalla.
Hablemos de tu proyecto