#El problema que nadie quería nombrar
Cuando entré a trabajar en una empresa 3PL con operaciones desde Irlanda y Estados Unidos hacia todo el continente americano, la operación se manejaba así:
Una instrucción de salida —consolidar los tickets listos, verificar la carga, preparar la documentación— tomaba entre 2 y 3 horas de trabajo manual. Los errores eran frecuentes y costosos: carga enviada al país equivocado, paquetes perdidos en el flujo, facturas mal calculadas.
#La decisión
Había un ERP en uso. Nadie lo usaba. Era demasiado complejo para una operación que no necesitaba un ERP genérico — necesitaba una herramienta construida a medida, que siguiera el flujo exacto de la empresa: sus nomenclaturas, sus etapas, sus reglas de negocio. No adaptar la operación al software, sino el software a la operación.
No busqué otro software. Decidí construirlo. Lo que la operación necesitaba era una herramienta que siguiera exactamente su flujo, suficientemente simple para que todo el equipo la adoptara, y que pusiera toda la información en un solo lugar en tiempo real. Empecé a diseñarla en noviembre de 2025. Entró en producción en febrero de 2026.
#El flujo completo en una vista
VertS gestiona el ciclo completo de una operación logística internacional: desde que el cliente avisa que tiene carga, hasta que esa carga llega al destinatario y se registra el costo del proveedor.
01 / 10
Cliente crea Pre-alerta (PO)
#Módulos Core: El Ecosistema
La aplicación está estructurada en módulos seguros basados en roles, accesibles desde el dashboard principal. Cada módulo resuelve una fricción operativa específica:
Pre-alertas, tickets de recepción con fotos y documentos, consolidación automática de POs.
Manifiestos de exportación, AWB/BL, Loading Guide, seguimiento de ETA vs. entrega real.
Motor automático: peso real vs. volumétrico, 11 conceptos de cargo, generación de PDF.
Facturas de bodega vinculadas a salidas específicas. Trazabilidad de costo real por operación.
Exportación XLSX, CSV y PDF. Dashboard de KPIs operativos en tiempo real.
Roles diferenciados: STAFF_3PL, CLIENTE_ADMIN, CLIENTE_VISOR. Aislamiento total por empresa.
#Las decisiones técnicas que importan
1. La base de datos primero — y bien hecha
El mayor reto técnico no fue el frontend. Fue diseñar el modelo de datos correcto desde el inicio. Un paquete puede llegar en múltiples recepciones parciales. Varios paquetes de distintos clientes pueden salir consolidados en un mismo embarque. Un embarque puede desconsolidarse para enviar partes a distintos destinos. Las facturas de proveedores pueden cubrir una o múltiples salidas. Modelar eso mal al principio significaba reescribir todo después. El resultado: relaciones correctas, 13 índices estratégicos para las queries más frecuentes, y constraints que hacen imposible registrar datos inconsistentes.
2. Automatización que elimina el error humano
El error más costoso del sistema anterior era la intervención manual en cada cambio de estado. En VertS eso no existe. Cinco triggers en PostgreSQL se encargan de la consistencia sin que nadie lo active: cuando llega un ticket, el trigger suma los ítems y actualiza el PO; cuando el PO está completo, todos sus tickets cambian a LISTO_PARA_ENVIAR en una operación atómica; cuando se desconsolida, el trigger valida que los ítems hijos no excedan el padre. Cada mutación queda registrada en audit_logs con el estado antes y después.
3. Seguridad multi-tenant que vive en la base de datos
En una plataforma donde múltiples clientes ven su propia carga, la pregunta de seguridad no es '¿qué muestra el frontend?' sino '¿qué puede devolver la base de datos?'. Row Level Security en todas las tablas: un cliente autenticado físicamente no puede obtener datos de otro aunque manipule la URL, el token o la petición HTTP.
Perfiles & Roles
Auth Users → Tabla perfiles
Integración sobre la tabla auth nativa. Tres roles: STAFF_3PL, CLIENTE_ADMIN, CLIENTE_VISOR.
SeguroRow Level Security
Policy: auth.uid() = user_id
Todas las consultas PostgreSQL filtran filas nativamente. El frontend no filtra — la BD lo hace.
InquebrantableStorage Buckets
Políticas sobre archivos
Fotos de recepción, invoices y PDFs de cotización protegidos en buckets con RLS.
PrivadoAl aprovechar las herramientas nativas de PostgreSQL, la aplicación evita vulnerabilidades comunes en la capa backend tradicional y escala sin reescribir lógica de autorización cada vez que se agrega un módulo.
Server Action: aislamiento multi-tenant
El empresa_id nunca viene del cliente — se infiere del perfil autenticado. Así es imposible que un tenant inserte datos en el contexto de otro, aunque manipule la petición.
Triggers PostgreSQL: consistencia automática
Estos dos triggers son el corazón de la automatización. update_cantidad_recibidos mantiene el conteo del PO sincronizado en tiempo real. auto_sync_po_status dispara la consolidación atómica cuando el PO está completo — sin intervención humana.
#El impacto en números
Antes vs. después: el mismo equipo, el mismo volumen de operación, resultados completamente distintos.
#Stack Tecnológico
#Lo que sigue
Portal de clientes
Acceso directo para que los clientes carguen pre-alertas y vean el estado de su carga en tiempo real, sin necesidad de correos.
Dashboard de análisis de costos
Comparativa cotización vs. factura real, alertas de vencimiento y métricas financieras por período.
Documentos y costos por salida
Vista unificada de toda la documentación y los costos de proveedor vinculados a cada despacho.
#Reflexión
Este proyecto resolvió un problema real que los integrantes de la empresa vivían todos los días. Antes de escribir una sola línea de código, estudié la operación: levanté el estado actual bajo la metodología AS-IS / TO-BE, modelé los procesos en BPMN, e identifiqué los puntos de fricción exactos que el sistema debía eliminar. Solo entonces empecé a construir.
Aprendí más diseñando el modelo de datos de VertS que en cualquier tutorial. Y confirmé lo que la ingeniería industrial ya enseña: entender el proceso es el trabajo — la herramienta viene después.
— Jaime Arias · Diseño, arquitectura e implementación completa · Nov 2025 → Producción Feb 2026 → Evolución continua