Web 3PL

Frontend Ownership for Multi-Modal Logistics Operations

Web 3PL is an internal logistics platform used to manage Third-Party Logistics (3PL) operations for Indopaket, covering shipment workflows across land (darat) and air (udara) transportation.

This project became my first deep exposure to the 3PL domain, where frontend work is tightly coupled with operational accuracy, data consistency, and system reliability. My role focused on frontend and UI ownership, translating complex logistics processes into interfaces that can be used safely in daily operations.

UX Principles Applied

Visibility of System Status (Nielsen’s Heuristic #1) Operators and logistics partners need to know where a shipment stands at all times. The dashboard shows live statistics, and each shipment exposes only the actions valid for its current state — so there’s no guessing about what step comes next.

Error Prevention (Nielsen’s Heuristic #5) The 3-step POD workflow (Arrived → Departed → Delivered) is enforced in the UI — you cannot skip or reverse steps. Date range filters are capped in the request layer (14 days for land, 30 for air), not just visually. Invalid actions are structurally unavailable, not just warned against.

Match Between System and Real World (Nielsen’s Heuristic #2) Land and air shipments behave differently in real logistics operations, and the UI reflects that directly. Air shipments expose multi-step transitions and placeholder fields for incomplete flight data. Land shipments follow a more linear flow. The UI mirrors the operational reality rather than forcing a uniform model onto different processes.

User Control and Freedom (Nielsen’s Heuristic #3) Role-based access (Darat, Udara, Admin) ensures each actor only sees what’s relevant to their responsibility. This isn’t just security — it reduces decision overhead. Operators working on land shipments aren’t distracted by air shipment actions that don’t apply to them.

Consistency and Standards (Nielsen’s Heuristic #4) Custom hooks (useShipments, useDaratAPI, usePodAPI) enforce consistent data handling patterns across features. Forms behave the same way across shipment types. Validation rules are config-driven, so they apply uniformly without UI-by-UI divergence.

---

Dashboard & Core Features

The application includes a real-time dashboard that gives operators an immediate overview of shipment statistics, helping them monitor daily operations at a glance.

Beyond shipment management, the platform supports:

• Tracking history — creating and retrieving per-AWB tracking records, supporting audit and status transparency
• CSV export — allowing operators to export shipment data for reporting and reconciliation
• DateTime range filtering with built-in business logic — 14-day limit for Darat, 30-day for Udara, enforced both in the UI and request layer

These features were designed for real operational workflows, not generic data tooling.

Understanding the Domain

Entering the 3PL Context

Working in 3PL required understanding that land and air shipments behave very differently.

Land shipments follow a more linear flow, while air shipments involve multi-step state transitions and incomplete data at early stages. These differences heavily influenced how the UI needed to present status, actions, and validation.

Rather than relying on generic dashboard patterns, the UI was shaped around real operational sequences and constraints.

Core Application Flow

The application supports role-based access and multi-modal shipment workflows:

• Users authenticate and receive role-based access (Darat, Udara, Admin)
• Menu structure adapts dynamically based on assigned roles
• Each shipment type exposes only the actions valid for its current state

For air shipments, the UI supports a three-step POD workflow:

1. Create (Arrived) with placeholder data when flight details are not yet available
2. Update Flight (Departed) once flight information is confirmed
3. Upload POD (Delivered) as the final confirmation The frontend enforces these transitions to prevent invalid actions and reduce operational error. Detailed operational paths vary by role and are intentionally abstracted in this overview.

Multi-Actor Usage Context

The platform is used by multiple operational actors, including internal teams and external logistics partners.

Access is strictly controlled through role-based permissions, ensuring each user only interacts with workflows relevant to their responsibility. This constraint influenced how navigation, actions, and validation were designed, prioritizing clarity while preventing unauthorized operations.

Frontend Architecture & Reliability

State Management via Custom React Hooks Rather than a global state library, the project uses a structured set of custom hooks — useShipments, useDaratAPI, usePodAPI, useDashboard, useTrackingAPI, and others — each scoped to a specific domain. This kept state co-located with the features that needed it and made the codebase easier to maintain as the product evolved.

Custom API Client & Error Handling

Instead of relying directly on Axios, the frontend uses a custom API client built on native fetch, allowing finer control over request behavior.

This includes:

• automatic JWT expiry checks before requests
• global handling for 401 responses with forced logout
• retry logic with exponential backoff for 502 / 503 / 504
• request timeouts using AbortController

These decisions were driven by the need for predictable behavior in unstable network conditions, common in operational environments.

Handling Backend Inconsistencies The frontend also needed to handle inconsistent field naming between API endpoints (e.g. origin vs originHub). Mapping logic was centralized to keep UI components clean and prevent leakage of backend quirks into presentation logic.

UI Design-to-Code

Operational-first Interfaces All interfaces were designed for operational users and logistics partners, not public end customers. The priority was:

• clarity over aesthetics
• safe defaults over flexibility
• explicit states over hidden behavior This resulted in data-heavy tables, form-driven workflows, and clear action boundaries based on shipment state.

Forms, Validation & Config-driven Rules Forms were implemented using React Hook Form with Zod validation, enforcing business rules consistently across the UI.

Many constraints (date ranges, time limits, forward days) are config-driven via environment variables, allowing adjustments without touching UI logic.

Testing & Maintainability

To support long-term stability, the project includes:

• unit and component tests using Vitest and Testing Library
• jsdom-based environment simulation
• linting and formatting enforced via ESLint, Prettier, and lint-staged This helped keep the codebase predictable as features evolved.

What Makes This Project Meaningful

• First hands-on experience with real 3PL logistics workflows
• Clear separation between land and air operational logic
• Frontend ownership in a data-heavy, role-sensitive system
• Emphasis on reliability over visual polish
• Practical problem-solving under real operational constraints This project reinforced that good frontend work, especially in logistics, is less about visuals and more about making complex systems behave safely and predictably every day.

Financial Reconciliation Awareness (Recon)

Beyond shipment workflows, the platform also considers downstream financial reconciliation needs tied to logistics operations.

While not all reconciliation features are exposed directly in the UI, frontend behavior is designed to support downstream finance processes, such as:

• ensuring shipment status transitions are deterministic and auditable
• preventing invalid or duplicate POD submissions
• aligning operational states with billing and settlement logic

This awareness influenced how status locking, validation rules, and user permissions were implemented, reducing the risk of mismatched operational and financial data.

Planned Enhancements – Photo-based POD & Documentation

This project is evolving. One of the planned improvements is enhancing POD and documentation handling from link-based inputs to direct photo upload and capture, especially for mobile usage.

The planned scope includes:

• direct photo capture or gallery selection on mobile devices
• automatic image compression (≤ 2MB)
• watermarking with AWB number and capture datetime
• EXIF-based timestamp extraction for audit accuracy

These enhancements aim to:

• reduce manual errors
• improve auditability for both operations and finance
• better support field usage in real delivery scenarios

The implementation details are still being finalized and may change based on operational readiness and backend alignment.

Technical details are intentionally abstracted to respect system boundaries and operational confidentiality. Specific implementation approaches may evolve based on regulatory, operational, and partner readiness considerations.