Software para el transporte

// El problema

Un transportista regional organiza el tráfico por teléfono y con una hoja de cálculo compartida, así que los clientes llaman para saber el estado y la prueba de entrega llega a facturación mucho después de la descarga.

// Lo que construiríamos

Un tablero web de tráfico que planifica y asigna las cargas, con una aplicación iOS y Android para el conductor con paradas, cambios de estado, firmas y fotos, y un enlace de seguimiento que el cliente abre en lugar de llamar.

// Qué incluye

// Tecnologías

• Next.js
• React Native
• PostgreSQL con PostGIS
• API del tacógrafo electrónico y de telemática
• AWS

// El problema

Las peticiones de carga y de tarifa llegan como correos, hojas de cálculo y PDF de todos los formatos, y un coordinador vuelve a teclear cada una en el TMS antes de que nadie pueda dar precio.

// Lo que construiríamos

Un agente que lee cada petición, extrae el origen, el destino, las fechas, los pesos y las referencias, los comprueba contra las rutas del cliente y prepara la carga en el TMS para que un coordinador la apruebe. Funciona con un modelo de vanguardia a través de su API, la forma más rápida de empezar, porque las peticiones son datos comerciales rutinarios que el proveedor trata con sus condiciones empresariales.

// Qué incluye

// Tecnologías

• API de un modelo de vanguardia
• Python
• Next.js
• PostgreSQL
• API del TMS
• DigitalOcean

// El problema

El cargador, el transportista y el destinatario guardan cada uno su copia de la carta de porte y del registro de entrega, así que una reclamación por una carga incompleta o dañada se convierte en una discusión sobre qué copia es la buena.

// Lo que construiríamos

Una carta de porte electrónica anotada en un libro privado con permisos del que el cargador, el transportista y el destinatario tienen cada uno un nodo, para que la recogida, los traspasos y la entrega firmada sean un solo registro que ninguno puede cambiar por su cuenta. Si una empresa ya lleva el sistema y todos confían en ella, una base de datos compartida hace lo mismo por menos, y se lo diremos.

// Qué incluye

// Tecnologías

• Next.js
• Hyperledger Fabric (privada, con permisos)
• PostgreSQL
• Almacenamiento compatible con S3
• AWS

// El problema

Una agencia de transporte ofrece cargas a los transportistas autónomos por mensaje, gana la primera respuesta, y después nadie puede ver a quién se ofreció qué carga y cuándo.

// Lo que construiríamos

Un bot de Telegram que publica cargas para los autónomos aprobados, toma la primera aceptación confirmada, envía la confirmación de tarifa y pide fotos de la entrega en la descarga, con una pantalla de administración sencilla para la agencia.

// Qué incluye

// Tecnologías

• Telegram Bot API
• Node.js
• PostgreSQL
• DigitalOcean

// El problema

Los cargadores y los marketplaces piden el estado por correo y por teléfono, y cada cliente grande quiere un flujo en su propio formato.

// Lo que construiríamos

Una API para socios que da a cada cargador sus claves, un entorno de pruebas y los mismos datos de envío, estado y prueba de entrega que ve su equipo, con webhooks cuando una carga se mueve. Un portal para desarrolladores y dos SDK permiten que los desarrolladores del cargador se conecten sin una llamada.

// Qué incluye

// Tecnologías

• OpenAPI 3.1
• TypeScript sobre Node.js
• PostgreSQL
• Redis
• API del TMS y del tacógrafo electrónico
• DigitalOcean

// El problema

Un transportista cotiza rutas de memoria y con unas cuantas hojas de cálculo, sin saber qué rutas y clientes cubren de verdad sus costes una vez contados los kilómetros en vacío, el combustible y las esperas.

// Lo que construiríamos

Un almacén de análisis que une cada noche cargas, combustible, pago a conductores y telemática, y muestra el coste por kilómetro por ruta y cliente con los kilómetros en vacío y las esperas, la puntualidad por cargador y las rutas que dejan poco margen.

// Qué incluye

// Tecnologías

• Next.js
• PostgreSQL
• dbt
• Metabase
• DigitalOcean