MF.
ESEN
Back to the portfolio

Case study / Business systems · Logistics

AMXpress Platform

A logistics operation, connected end to end.

A logistics platform connecting administration, customers and courier workflows through APIs, integrations and asynchronous processing.

Open AMXpress demoAMXpress website

Demo with sample data; no real customer or shipment data.

Technologies used
Angular · NestJS · TypeScript · PostgreSQL · Prisma · Redis · BullMQ · Resend · Linux

The product on screen

Application screenshots

AMXpress customer portal dashboard with statuses and period metrics.
Customer portal dashboardOpen full screenshot
AMXpress public landing page presenting its logistics services.
AMXpress public websiteOpen full screenshot
AMXpress mobile interface for delivery workflows.
Mobile workflowOpen full screenshot

The problem

Operations need to track shipments and packages, import information and coordinate customers and couriers while continuing to use a legacy system. The challenge is introducing new tools while preserving traceability and existing workflows.

My contribution

Full-stack development of NestJS APIs, PostgreSQL/Prisma models and Angular applications for different roles. I implement integrations, synchronization, imports and labels alongside independent services and operational deployment configuration.

What the product enables

Manage and track shipments

An administrative dashboard, customer portal and mobile courier workflows. Shipments, packages, statuses and operational history, with public tracking and events that refresh views.

Connect systems and customers

Mercado Libre integration, legacy synchronization and B2B APIs with tokens, scopes and auditing. JWT authentication, roles and permissions define access to information.

Process operational work

Bulk imports and PDF/ZPL labels. Import, label-batch and synchronization workers separate long-running work from HTTP requests.

How the pieces fit together

Core owns the domain and REST APIs over PostgreSQL. Angular provides role-specific views; Redis coordinates BullMQ queues and events. Sync Service adapts the legacy contract. Notification Service keeps communication responsibilities separate. The topology combines Node services, an HTTPS proxy and Docker components where appropriate; it does not assume the entire historical operation has migrated to the new Core.

MVP component relationships
  1. Admin / Portal / mobile
    REST · JWT · roles
    Core API
  2. Core API
    Prisma · shipments and packages
    PostgreSQL
  3. Core → BullMQ
    Redis · workers · events
    Sync → Legacy
  4. Core / Legacy
    Internal HTTP / scheduled queries
    Notifications → Resend

Engineering decisions

A shared Core domain, specialized services

Shipments, packages and history need a common representation across applications and APIs. I keep that domain in Core and separate legacy adaptation and notifications into dedicated services. Interfaces share rules without taking on external contracts or requiring a complete replacement of the previous system.

Access bounded by actor and customer

An administrative operation and a B2B integration require different permissions. JWT, roles and permissions protect the applications; revocable tokens, scopes and audit records bound B2B APIs. Queries are scoped to the authenticated customer, so knowing a shipment identifier does not grant access.

Integrations as recoverable processes

Imports, labels and synchronization involve long-running work and providers that can fail. I keep contracts and credentials in the backend and run the work through workers with persisted states and results. Partial errors remain visible and operations can recover without treating an accepted request as completed work.

Explore Legacy Sync

Challenges addressed

Coexisting with two operational models

Legacy and Core represent identities, states and history differently. The adapter normalizes those contracts and reconciles records while the existing operation continues through the transition. Legacy Sync explains replay guarantees and provider limitations.

Making asynchronous work visible

Queued does not mean completed. The system distinguishes job state, errors and completion; events trigger local rereads without presenting a timeout as successful synchronization.

Demonstrable capabilities

Recurring business use

Real business use without attributing the company’s historical shipment volume to the new Core.

Verifiable operations and integrations

Applications share models and access controls. Permission, synchronization, import and label tests exercise the boundaries between request, processing and result.