#The problem nobody wanted to name
When I joined a 3PL company with operations from Ireland and the United States to the entire American continent, operations were managed like this:
A single outbound instruction — consolidating ready tickets, verifying cargo, preparing documentation — took 2 to 3 hours of manual work. Errors were frequent and costly: cargo sent to the wrong country, packages lost in the flow, miscalculated invoices.
#The decision
There was an ERP in use. Nobody used it. It was too complex for an operation that didn't need a generic ERP — it needed a tool built to measure, one that followed the company's exact flow: its nomenclature, its stages, its business rules. Not adapting the operation to the software, but the software to the operation.
I didn't look for another software. I decided to build it. What the operation needed was a tool that followed its exact workflow, simple enough for the whole team to adopt, and that put all information in one place in real time. I started designing it in November 2025. It went into production in February 2026.
#The complete flow at a glance
VertS manages the complete lifecycle of an international logistics operation: from when the client notifies incoming cargo, to when that cargo reaches the consignee and the supplier cost is recorded.
01 / 10
Client creates Pre-alert (PO)
#Core Modules: The Ecosystem
The application is structured into secure, role-based modules accessible from the main dashboard. Each module resolves a specific operational friction:
Pre-alerts, reception tickets with photos and documents, automatic PO consolidation.
Export manifests, AWB/BL, Loading Guide, ETA vs. actual delivery tracking.
Automatic engine: actual vs. volumetric weight, 11 charge concepts, PDF generation.
Warehouse invoices linked to specific shipments. Real cost traceability per operation.
XLSX, CSV, and PDF exports. Real-time operational KPI dashboard.
Differentiated roles: STAFF_3PL, CLIENTE_ADMIN, CLIENTE_VISOR. Full isolation per company.
#The technical decisions that matter
1. Database first — and done right
The biggest technical challenge wasn't the frontend. It was designing the correct data model from the start. A package can arrive in multiple partial receptions. Several packages from different clients can be consolidated into the same shipment. A shipment can be deconsolidated to send parts to different destinations. Supplier invoices can cover one or multiple shipments. Modeling that wrong at the beginning meant rewriting everything later. The result: correct relationships, 13 strategic indexes for the most frequent queries, and constraints that make it impossible to register inconsistent data.
2. Automation that eliminates human error
The most costly error in the previous system was manual intervention at every state change. In VertS, that doesn't exist. Five PostgreSQL triggers handle consistency without anyone activating them: when a ticket arrives, the trigger sums the items and updates the PO; when the PO is complete, all its tickets change to READY_TO_SHIP in an atomic operation; when deconsolidating, the trigger validates that child items don't exceed the parent. Every mutation is recorded in audit_logs with the before and after state.
3. Multi-tenant security that lives in the database
In a platform where multiple clients see their own cargo, the security question isn't 'what does the frontend show?' but 'what can the database return?'. Row Level Security on every table: an authenticated client physically cannot obtain another client's data even if they manipulate the URL, token, or HTTP request.
Profiles & Roles
Auth Users → profiles table
Integration on top of native auth. Three roles: STAFF_3PL, CLIENTE_ADMIN, CLIENTE_VISOR.
SecureRow Level Security
Policy: auth.uid() = user_id
All PostgreSQL queries filter rows natively. The frontend doesn't filter — the DB does.
UnbreakableStorage Buckets
File-level policies
Reception photos, invoices, and quotation PDFs protected in RLS buckets.
PrivateBy leveraging native PostgreSQL capabilities, the application bypasses common backend-layer vulnerabilities and scales without rewriting authorization logic every time a new module is added.
Server Action: multi-tenant isolation
The empresa_id never comes from the client — it's inferred from the authenticated profile. This makes it impossible for one tenant to insert data in another's context, even if the request is manipulated.
PostgreSQL Triggers: automatic consistency
These two triggers are the heart of the automation. update_cantidad_recibidos keeps the PO count in sync in real time. auto_sync_po_status fires the atomic consolidation when the PO is complete — without human intervention.
#The impact in numbers
Before vs. after: the same team, the same operation volume, completely different results.
#Tech Stack
#What's next
Client portal
Direct access for clients to create pre-alerts and track their cargo in real time — no more emails.
Cost analytics dashboard
Quotation vs. actual invoice comparison, expiry alerts, and financial metrics by period.
Documents & costs per shipment
Unified view of all documentation and supplier costs linked to each dispatch.
#Reflection
This project solved a real problem that the company's team faced every day. Before writing a single line of code, I studied the operation: I mapped the current state using the AS-IS / TO-BE methodology, modeled the processes in BPMN, and identified the exact friction points the system needed to eliminate. Only then did I start building.
I learned more designing VertS's data model than in any tutorial. And I confirmed what industrial engineering already teaches: understanding the process is the work — the tool comes after.
— Jaime Arias · Design, architecture and full implementation · Nov 2025 → Production Feb 2026 → Ongoing evolution