# Building a Recurring Logistics Operations Module **Disclosure:** This case study is anonymized. The client’s identity, product branding, source code, production screenshots, internal architecture, customer information, commercial terms, and performance metrics have been excluded. * * * **Industry:** Logistics and delivery **Project type:** Fleet-management and recurring-order module **My contribution:** Frontend development and API integration **Team:** * [Shebaan Kalim](https://www.linkedin.com/in/shebaankalim/) - UI/UX Designer * [Mohammad Maheer](https://www.linkedin.com/in/mohammad-maheer/) - Backend Lead * [Abdul Rahman](https://www.linkedin.com/in/hafizabdulrahman20/) - Backend Developer * * * ## Overview An on-demand logistics platform works well when every delivery is an independent event. A company enters the pickup and destination details, requests a vehicle, receives a driver assignment, and completes the delivery. The same model used by ride-hailing applications can make occasional logistics bookings significantly easier. The model becomes less suitable when a business needs the same type of delivery repeatedly. Some customers required vehicles for recurring routes over several weeks or months. Using the existing process meant creating another booking for every delivery, entering similar information again, coordinating with newly assigned drivers, and monitoring each request independently. The underlying problem was not that the platform lacked a booking form. It was that a system designed around short-lived transactions now needed to support a long-running operational relationship. Our team developed a fixed-vehicle-order module to address that difference. My responsibility focused on implementing the frontend experience and integrating it with the backend services supporting quotations, recurring orders, driver assignments, attendance records, invoices, and operational reporting. * * * ## The existing model solved the wrong frequency of problem The platform’s original order model was suitable for variable or occasional delivery requirements. Each request could be treated as an independent transaction: 1. A customer submitted delivery information. 2. A driver was assigned. 3. The delivery was completed. 4. The order was closed. That lifecycle was understandable because the order had a clear beginning and end. Recurring delivery operations behaved differently. The customer was not purchasing one isolated journey. They were arranging an ongoing service involving repeated schedules, a vehicle and driver relationship, attendance monitoring, possible driver replacements, billing periods, and operational reports. Trying to represent that service as dozens of unrelated orders introduced avoidable work. | One-off delivery model | Recurring delivery requirement | | --- | --- | | A new request for each journey | One arrangement covering repeated journeys | | Driver assigned per request | Driver associated with the service period | | Order ends after delivery | Operational state continues over time | | Individual payment or invoice event | Period-based billing and reporting | | Limited history required | Attendance and performance history required | | Changes apply to one delivery | Changes may affect future scheduled activity | The existing model was not defective. It was designed for a different usage pattern. The engineering challenge was extending the platform without forcing a long-running service into a short-lived transaction model. * * * ![The existing order model handled isolated deliveries. Recurring operations required a longer-lived service lifecycle.](https://cdn.hashnode.com/uploads/covers/63a80bd9b1011ed9ec6d049c/6eddc646-2e4f-4438-ab15-ffdce5295b6d.png align="center") * * * ## My contribution I worked on the frontend implementation and service integration for the new module. My contribution included: * Building the screens and workflows used to create and manage recurring vehicle orders. * Translating approved product designs into responsive frontend interfaces. * Integrating quotation, order, driver, attendance, invoice, and reporting services. * Mapping backend records into understandable operational views. * Handling loading, empty, successful, and recoverable error states. * Supporting the transition between quotation, approval, activation, and ongoing management. * Coordinating API requirements and edge cases with the backend team. * Working with the product designer to align interface behaviour with operational constraints. * Keeping the new recurring-order experience consistent with the existing platform. I did not design or build the entire logistics platform independently. The backend services and domain rules were collaborative work owned by the relevant team members. My role centred on the customer-facing module and the integration boundary between operational services and the interface. * * * ## Designing around a long-running operational lifecycle The most important architectural shift was recognising that a fixed-vehicle order could not be treated like a conventional form submission. A user might begin by preparing a quotation, wait for it to move through an approval process, receive a driver assignment, monitor activity over a service period, request a replacement, and later review invoices or reports. The record remained active while its operational state changed. A representative lifecycle looked like this: 1. A company defines its recurring delivery requirements. 2. A quotation is created from the required locations, schedule, duration, and service details. 3. The quotation moves through review or approval. 4. A vehicle and driver are associated with the active service. 5. Attendance and operational activity are recorded over time. 6. Exceptions, such as a driver-change request, are handled without recreating the entire order. 7. Billing and reporting records become available for the relevant period. 8. The service is completed, renewed, changed, or closed. The frontend had to make the current state understandable while presenting only the actions appropriate at that point. A quotation awaiting approval should not expose the same controls as an active order. An active order with an assigned driver should behave differently from one awaiting assignment. A completed billing period should remain inspectable without appearing editable. This is where operational software becomes more difficult than it first appears: the interface must represent not only data, but the rules governing what can happen next. * * * ![Unlike a one-off booking, a recurring order remains active while quotations, assignments, exceptions, and billing states change.](https://cdn.hashnode.com/uploads/covers/63a80bd9b1011ed9ec6d049c/30145792-5cf0-44f1-840e-6658b93d1934.png align="center") * * * ## Turning operational records into a usable interface Backend systems often represent logistics operations as related records: quotations, orders, vehicles, drivers, schedules, attendance entries, invoices, and reports. Customers do not think in database entities. They think in questions: * Has the arrangement been approved? * Which driver is assigned? * Did the driver check in today? * Where was the check-in recorded? * Is a replacement request pending? * Which billing period does this invoice cover? * What activity occurred during the month? The frontend needed to translate related service responses into views that answered those questions. That required deciding: * Which information belonged on the order summary. * Which records needed dedicated detail views. * Which status should be most prominent. * Which actions were currently available. * How related historical information should be grouped. * What the interface should show when information had not yet been created. * How to distinguish a genuine empty state from a failed request. These decisions affected more than presentation. They determined whether users could understand the operational condition of a recurring order without asking the support team to interpret the system for them. * * * ## Maintaining consistency across connected features The module included several connected capabilities: ### Quotation management Businesses needed to describe a recurring service without recreating the same information for every delivery. The quotation flow gathered the operational details required to begin that arrangement and presented its current state as it moved through the process. ### Fixed driver assignment Once the service became active, the interface needed to show the assigned driver as part of the ongoing order rather than as a temporary detail attached to one journey. ### Driver-change requests A replacement request introduced an exception to the normal lifecycle. The frontend needed to represent the current driver, the pending change, and the eventual outcome without making the order appear to have two active assignments simultaneously. ### Attendance and check-in records Operational monitoring required more than displaying the assigned driver’s name. Attendance records needed to be associated with the correct order, date, and activity while remaining easy to review over a service period. ### Invoicing and payment status Billing information had to remain connected to the recurring arrangement while reflecting individual billing periods and payment states. ### Reports Historical activity needed to be presented in a form that supported operational review rather than forcing users to inspect every underlying event separately. Each feature had its own interface requirements, but users experienced them as parts of one service. Shared status patterns, navigation behaviour, and data presentation helped prevent the module from feeling like several unrelated tools placed beside one another. * * * ![A conceptual view of how operational screens were separated from the services and state transitions behind them.](https://cdn.hashnode.com/uploads/covers/63a80bd9b1011ed9ec6d049c/81ebc3ae-79e0-409f-b52b-f64696b14c64.png align="center") * * * ## Managing server-controlled operational state In a simple interface, the browser may be able to treat recently entered information as the current truth. That assumption is unsafe in an operational platform. A driver assignment may be changed by an administrator. A quotation may be approved by another user. Attendance may be added after the customer first opens the page. An invoice can move from unpaid to paid without the current screen initiating the change. The frontend therefore had to treat backend data as the authority for operational state. This created several implementation considerations: * Refreshing information after state-changing actions. * Avoiding stale controls after a status changed. * Preventing duplicate submissions while a request was processing. * Showing users that an operation had succeeded before reloading dependent information. * Preserving useful interface context during updates. * Handling cases where a record changed between the user opening it and attempting an action. The difficult balance was keeping the interface responsive without pretending that local browser state represented the entire operation. * * * ## Designing exception handling as part of the normal journey Recurring logistics involves exceptions. Drivers can become unavailable. Schedules may need adjustment. A quotation may require revision. Attendance may be missing. A billing record may not yet exist. These conditions should not be treated as surprising technical failures. A useful operational interface needs to distinguish between: * A system error. * A pending business process. * Information that has not yet been created. * An action that is unavailable in the current state. * An exception that requires a specific follow-up step. For example, “No driver assigned yet” communicates a different situation from “Driver information could not be loaded.” One is an operational state; the other is a technical failure. Making that distinction consistently helped the interface communicate what the system knew, what was still pending, and whether the user needed to act. * * * ![A conceptual operational view illustrating the information customers may need across a recurring service. It is not the client’s interface.](https://cdn.hashnode.com/uploads/covers/63a80bd9b1011ed9ec6d049c/7009301f-491c-4087-ad12-6f2ecd19ca23.png align="center") * * * ## Outcome The project delivered a new frontend module that allowed the platform to represent recurring logistics arrangements separately from individual delivery bookings. The completed experience supported the customer-facing management of: * Recurring service quotations. * Fixed vehicle and driver arrangements. * Driver-change requests. * Attendance and check-in records. * Period-based invoices and payment states. * Operational reporting. From an engineering perspective, the implementation produced several qualitative outcomes. ### A booking model better matched to recurring work Repeated delivery requirements could be represented as one longer-lived arrangement rather than a sequence of disconnected requests. ### Clearer operational visibility Related information about the order, driver, attendance, changes, invoices, and reports could be accessed within one connected module. ### More consistent state handling The frontend could represent quotations, assignments, pending changes, active service, and completed records through shared status and interaction patterns. ### Reduced repetitive interaction The flow was designed to avoid requiring customers to recreate the complete service arrangement for every recurring delivery. ### A foundation for additional operational workflows Separating recurring orders from variable bookings gave the product a clearer structure for future features related to scheduling, monitoring, billing, and service management. These are qualitative product and implementation outcomes. This case study does not claim measured reductions in cost, booking time, delivery delays, support workload, or customer churn because supporting analytics and publication permission are not available. * * * ## What I learned ### 1\. Frequency can change the entire product model A one-off order and a recurring service may involve similar vehicles and routes, but their software lifecycles are fundamentally different. ### 2\. Operational interfaces are state machines with buttons Most complexity comes from deciding which actions are valid, who can perform them, and how one state becomes another. ### 3\. Empty states need domain meaning “No records yet,” “waiting for assignment,” and “request failed” may all produce an empty panel, but they require different explanations and actions. ### 4\. Long-running records need server authority When several users and services can modify an operation, the browser cannot safely behave as the sole source of truth. ### 5\. Related features need one shared mental model Quotations, drivers, attendance, invoices, and reports can be implemented separately. Customers still need to understand them as one operational service. ### 6\. The best frontend abstractions follow business boundaries Reusable components help, but the more important abstraction is a clear representation of the underlying business lifecycle. * * * ## Closing reflection This project was not simply an expansion of an existing delivery form. It required the platform to support a different kind of relationship with its customers: one that continued across schedules, driver assignments, attendance records, exceptions, and billing periods. My contribution was to translate that operational model into a connected frontend experience and integrate it with the backend services responsible for each stage. The central lesson was that recurring operations cannot be managed reliably as a pile of repeated transactions. They need a product model and an interface designed around continuity. * * * ## Portfolio callout **What I demonstrated** Frontend development · API integration · Operational workflows · State modelling · Fleet-management interfaces · Error and empty-state design · Cross-functional collaboration * * * ## Publication note All accompanying diagrams and illustrations must be labelled **representative** or **conceptual**. They must not be presented as production screenshots, exact architecture diagrams, measured analytics, or reproductions of the client’s proprietary workflows.