Quick Summary: In this case study a 14 week application was built in Laravel to support a logistics and delivery company that utilized Laravel (with Vue.js / Inertia.js) as its front-end application framework and Flutter as the front end for the drivers mobile application. Prior to building the application, multiple applications were being used by the logistics and delivery company to manage orders, manually dispatching trucks to deliver packages, manually track packages and report on operations. All these systems were maintained through spread sheets. The new application provided a central location to unify all of these processes. Lessons learned included; the importance of conducting a full discovery prior to development, developing an architecture for real time capabilities from day one, and continuing to develop after launch using actual user data.
Custom applications are always built to meet needs of their own. The steps in this case study describe how we went about building a complex Laravel application — from figuring out what the client needed through developing an overall technical strategy for the product to its final deployment into production.
The Challenge
Our client’s operations revolved around logistics and delivery; they had developed an extensive network of drivers, and a large number of customers along with increasing operational complexities that their current technology solutions (a combination of spreadsheets, generic SaaS platforms, and manual methods) could no longer accommodate.
Their main problems were clearly defined. Customer orders were spread across different systems as there wasn’t one common reference point to utilize. The company assigned drivers manually which took considerable amounts of time and was prone to errors when assigning drivers at peak times. Their customers didn’t have access to view the status of deliveries in real-time. Therefore, it was necessary for customers to call the company directly to receive information about the status of their delivery.
It also took the company many hours each week to compile data by hand for reports. As the company continued to grow its operations faster than its makeshift systems allowed, they desperately needed a new, unified platform: One integrated software solution for all aspects of their operations including customer order management, driver management, real-time tracking, automated dispatching, and operational reporting.
The Solution: Technical Approach
As part of our comprehensive discovery process, we selected Laravel as our back-end framework. We made this selection based on a number of criteria; i.e., the application needed to perform complex business logic (i.e., automated dispatch rules, price adjustment based upon time-of-day/seasonal considerations etc.), had multiple end-user groups each having their own interface (customer, driver, dispatcher, administrator) and had to be able to support a large amount of data exchange via an Application Programming Interface (“API”) for use in the mobile driver application. Additionally, the application would have to support real-time event processing (e.g., updating customer orders in near-real time as they are fulfilled, updating the physical locations of drivers, changing order status).
Our front-end application was developed utilizing Vue.js with Inertia.js providing a “single page” like user-experience to the web-based application that still leveraged the simplicity of Laravel’s back-end server-side routing. By doing so we were able to eliminate the need for an additional “API-layer” supporting our web-application thereby greatly simplifying our development efforts.
Database design was very important. We created a Relational Normalized Database that was optimized for the most commonly queried items; such as; Order Lookups By Status, Driver Availability By Zone, Time-Range Reporting. The query performance was tested during our development phase and not as an after-thought.
The dispatch system utilized Laravel’s Queue System for background processing. Once a new Order came into the System, we would evaluate which Drivers were Available, calculate the best possible assignment for the Driver based upon their Location and Current Load, send Push Notifications to each Assigned Driver and update All Connected Dashboards in Real-Time using Laravel’s Broadcasting Events.
The customer-facing interface was designed to be extremely easy for customers. They can create an order, see their delivery status in real time on a map, review their past orders and manage their accounts. All screens are first for mobile devices, as all customer interaction is done by phone.
The driver app was developed using Flutter and communicates to the back end (Laravel) via a RESTful API. When a driver receives an order notification they have the option to either Accept/Decline the assignment; update their status of where they are at with respect to completing the job; and get a running total of what they will earn today. The app ran flawlessly on both iOS and android from a single code base.
The admin dashboard provides Dispatchers and Managers with complete visibility into how operations are working: current status of all orders; exact location of drivers on a map; metrics for performance; reports for finance; and ability to configure the system. Reporting functionality which previously would take hours to generate now takes seconds.
The Build Process
The project followed a phased approach over 14 weeks.
Weeks 1–2: Discovery and architecture. All business needs were detailed. A database schema design was created and examined. API contracts were agreed to among the web application, admin dashboard, and mobile app.
Weeks 3-4 Building out the core back-end. User authentication/role mgmt., order management CRUD, driver mgt., and the framework for the dispatch system were written/tested.
Weeks 5–8: Feature development. The dispatch algorithm, live tracking, notifications, and the reporting engine were all built incrementally. Then each feature was tested individually and rolled up into the overall system.
Weeks 9–10: Frontend and mobile development. The Customer Interface (Admin Dashboard and Driver Flutter App) were built using the backend API which has been tested.
Weeks 11–12: Integration testing and QA. End-to-End workflow testing of the entire system, Performance testing to simulate heavy loads, Security Audit of the System and Bug Fixing.
Weeks 13–14: Staging deployment and launch. The Application was Deployed to Staging Environment for Client Testing. Final Adjustments Were Made as per Clients Feedback.
The Results
The launch occurred right on time. It processed its target number of transactions from Day One. Processing times for orders went down significantly when it removed all manual processes. Automated Dispatching System dispatched drivers much quicker and in a much better way then Manual Dispatching. The ability for customers to see their shipment location through tracking gave them much greater satisfaction. Hours spent producing weekly reports which required significant amounts of work are now simply clicking a button.
The fact that it is built using a Modular Architecture allowed new features (a new pricing model, additional delivery zones, integration into an accounting system) to be added after the initial launch without having to recode the main application.
Key Takeaways
You cannot avoid Discovery. The two week discovery process, allowed us to save weeks on future development rework. By understanding all aspects of how the business operates (business rules), what users will do when they encounter an error or edge case, and how the workflow for each use case works in advance of starting to write code; we were able to complete the initial version of our application as close to “final” as possible — not as a rough draft needing extensive editing/revision.
Laravel with Inertia.js is a productive stack. We were able to greatly reduce the amount of time it takes to develop an application by utilizing a server side routing strategy with the ability to have SPA-like frontend experience. This eliminated much of the complex nature of developing both backend API’s and separate frontends. Since everything existed within a single project structure, developers did not need to manage multiple projects simultaneously.
Real-time features require architectural planning. Incorporating real time functionality into a system that wasn’t built with this feature can be very expensive. Since the architectural design included the concept of streaming (broadcasting), web sockets, and a process to run in the background, it made sense when we needed to include real time functionality as opposed to adding it after the fact.
Launch is the beginning, not the end. Some of the best information we received were based upon how users used our product. As a result of post launch iterations, which were influenced by actual user behavior data, i found some of my most successful changes to be much more effective than any pre-launch plan would have indicated.
Need a custom application built? We bring the same disciplined approach to every project. Discuss your project with us →
For the technology overview, read our Web Development Technology Stack Guide.
