# Real-Time Fleet Management Platform Built a custom fleet tracking and dispatch platform processing 50,000+ GPS events daily with sub-second response times. ## Real-Time Fleet Management Platform Built a custom fleet tracking and dispatch platform processing 50,000+ GPS events daily with sub-second response times. --- ## Our Process 1. **Operations Audit** — Spent a week riding along with drivers and shadowing dispatchers to understand the real workflow, not just the documented one. FreedomDev team members observed six complete delivery routes across different vehicle types and territories, documenting every manual process, communication pattern, and decision point. The audit revealed that drivers were using unofficial workarounds like personal smartphone apps for traffic routing because the company's official processes couldn't adapt to real-world conditions. 2. **GPS Integration Layer** — Built an adapter service to normalize telemetry data from existing GPS hardware without requiring device replacements. The integration layer polls the GPS provider's system every 15 seconds, transforms the proprietary data format into a standardized schema, and queues events for processing through RabbitMQ. This architecture decouples the unreliable third-party data source from the real-time processing pipeline, allowing the system to continue operating smoothly even during GPS provider outages by gracefully degrading to last-known positions. 3. **Real-Time Processing Engine** — Developed a WebSocket-based event processing system with geofencing, route deviation detection, and automated alerting. The engine processes incoming GPS events through a series of microservices that calculate ETAs based on current traffic conditions, evaluate geofence transitions, detect route deviations beyond configurable thresholds, and trigger notifications. FreedomDev implemented circuit breakers and exponential backoff for external service calls to prevent cascading failures when notification services experience latency. 4. **Dispatcher Dashboard** — Built a map-based React dashboard for real-time fleet visibility with route management and customer notification triggers. The dashboard includes role-based access control so dispatchers see their assigned vehicles while managers have full fleet visibility. FreedomDev conducted three rounds of usability testing with actual dispatchers, iterating on the interface design based on their feedback about which information needed to be visible at a glance versus hidden in drill-down panels. 5. **Analytics & Optimization** — Added historical route analysis and fuel consumption reporting to identify optimization opportunities across the fleet. The analytics module aggregates GPS data with fuel purchase records to calculate per-route and per-driver efficiency metrics, highlighting outliers for investigation. FreedomDev built a recommendation engine that analyzes three months of historical data to suggest recurring route optimizations, which dispatch managers review weekly and implement for the following week's schedules. --- ## About Great Lakes Logistics Great Lakes Logistics has operated as a regional freight and delivery company since 1987, when founder Robert Pearson started with three trucks serving manufacturing customers in Grand Rapids, Michigan. Over 36 years, the company has grown to a fleet of 203 vehicles ranging from cargo vans to Class 8 tractors with 53-foot trailers, employing 187 people including drivers, dispatchers, warehouse staff, and administrative personnel. The company remains family-owned, with Robert's daughter Katherine Pearson serving as CEO since 2018 and overseeing the modernization initiatives that led to the FreedomDev engagement. The company specializes in time-sensitive freight for manufacturing clients who require just-in-time delivery of components and materials. Their customer base includes 47 active accounts, with the top 10 customers representing 71% of revenue. Great Lakes differentiates itself through reliability and customer service rather than competing on price alone — a positioning that made their declining on-time performance particularly threatening to their business model. The logistics industry in the Great Lakes region is highly competitive, with both national carriers and regional specialists competing for the same manufacturing accounts. Great Lakes had pursued steady but cautious growth, reinvesting profits into fleet expansion rather than taking on significant debt. By 2022, annual revenue had reached $24 million with EBITDA margins around 11%, respectable for a regional carrier but under pressure from rising fuel costs and labor expenses. The leadership team recognized that continued growth would require operational efficiency improvements that their existing manual processes couldn't support. Katherine Pearson had championed technology investment as critical to the company's next growth phase, setting aside a $250,000 budget for fleet management system development. The company's competitive position was strong within their core Michigan-Ohio-Indiana territory, with long-standing relationships with major manufacturers like Steelcase, Whirlpool suppliers, and automotive component makers. However, several customers had begun asking for capabilities that Great Lakes couldn't provide, including customer portals for self-service shipment tracking and automated delivery notifications. Two mid-sized accounts totaling $1.7 million in annual revenue had switched to competitors in 2021 specifically citing better technology for shipment visibility. The leadership team understood that technology gaps were now directly limiting their ability to compete for new business. Great Lakes chose FreedomDev after evaluating five potential development partners over a three-month selection process. They were initially skeptical about working with a custom software development agency rather than implementing commercial fleet management software, but the hardware replacement costs and licensing fees of commercial solutions didn't make financial sense for their operation. FreedomDev's portfolio of custom B2B software projects for mid-sized Michigan companies, combined with their transparent fixed-price proposal and 14-week delivery timeline, gave Great Lakes confidence they could deliver a tailored solution without the scope creep and budget overruns they'd experienced with their previous development attempt. The relationship with FreedomDev began with a paid discovery phase in January 2023, where the development team spent two weeks embedded with Great Lakes operations to understand their workflows in depth. This discovery phase produced detailed technical requirements and user stories that became the foundation for the fixed-price development contract. Great Lakes appreciated FreedomDev's pragmatic approach focused on solving specific business problems rather than implementing unnecessary features, and their willingness to work within the company's budget constraints while still delivering a production-ready system. --- ## The Challenge Great Lakes Logistics operates a fleet of over 200 vehicles across Michigan, Ohio, and Indiana. Their dispatch team was managing routes using a patchwork of spreadsheets, two-way radios, and manual phone check-ins. Drivers had no way to report delays or route changes in real-time. The lack of visibility created cascading problems: missed deliveries, fuel waste from inefficient routing, and constant overtime from dispatchers manually coordinating schedules. Their existing GPS provider offered basic location tracking but no integration with their dispatch workflow or customer communication systems. Great Lakes needed a unified platform that could ingest GPS telemetry, optimize routes dynamically, and give both dispatchers and customers real-time visibility into every shipment — without replacing their existing GPS hardware. The dispatch team of eight full-time employees was spending an average of 47 hours per week on manual coordination tasks that should have been automated. Each dispatcher fielded between 60 and 80 phone calls daily from drivers requesting route clarification, customers asking for delivery ETAs, and management needing status updates. The constant context-switching meant dispatchers could never focus on proactive optimization — they were always reacting to the latest crisis. Fuel costs had grown 18% over the previous two years despite relatively stable fuel prices, indicating systemic inefficiency in route planning and execution. Drivers frequently took suboptimal routes because dispatchers lacked real-time traffic data and couldn't dynamically reroute vehicles already in the field. The company estimated they were burning through an extra $140,000 annually in unnecessary fuel consumption, not counting the labor costs of overtime and missed delivery penalties. Before approaching FreedomDev, Great Lakes had attempted two other solutions. They first tried implementing a commercial fleet management system from a major provider, but the $85,000 annual licensing fee and mandatory hardware replacement cost of $450 per vehicle made the total investment untenable. They then hired a local developer to build a basic tracking interface, but that project stalled after six months when the solo developer couldn't handle the complexity of real-time data processing at scale. Customer satisfaction scores had declined from 4.2 to 3.6 stars over 18 months, with most complaints centered on late deliveries and poor communication about delays. Their largest customer, a regional manufacturing company representing 23% of annual revenue, had issued a formal warning that they would seek alternative logistics providers if on-time performance didn't improve within 90 days. The situation had reached a critical point where technology limitations were directly threatening business viability. The existing GPS hardware from their provider transmitted location updates every 60 seconds but stored the data in a proprietary web portal with no API access. Dispatchers had to log into the portal, manually check each vehicle's location, then cross-reference that information against spreadsheets showing assigned routes and customer delivery windows. This manual process meant the 'real-time' GPS data was often 15-20 minutes old by the time dispatchers could act on it, rendering it nearly useless for dynamic decision-making. --- ## Development Methodology FreedomDev's approach to the Great Lakes project began with a structured discovery phase that went beyond typical requirements gathering. The two-week discovery included ethnographic observation of dispatchers and drivers, structured interviews with 15 employees across different roles, and analysis of six months of historical operational data including GPS logs, fuel receipts, and customer complaint records. This deep contextual research revealed workflow inefficiencies and pain points that Great Lakes leadership wasn't fully aware of, such as the 20+ minutes dispatchers spent each morning manually cross-referencing spreadsheets to assign routes. The discovery phase deliverables included a 42-page requirements document with user stories, technical architecture proposal, and a detailed project timeline with milestones tied to payment schedules. The development team structure reflected FreedomDev's belief that smaller, focused teams outperform larger ones for projects of this scope. The five-person team maintained clear ownership boundaries: backend developers owned the event processing pipeline and database design, the frontend developer owned the React application and user experience, and the DevOps engineer owned infrastructure, CI/CD, and production monitoring. The project lead acted as the primary interface with Great Lakes stakeholders, translating business requirements into technical specifications and managing scope boundaries. This team size allowed for high communication bandwidth without the coordination overhead that slows down larger teams. FreedomDev implemented two-week sprint cycles throughout the 14-week development timeline, delivering working software increments at the end of each sprint. Sprint planning sessions involved both the development team and Great Lakes dispatch managers, ensuring that feature prioritization reflected actual operational needs rather than assumptions. Daily standups kept the team synchronized on progress and blockers, while bi-weekly sprint reviews gave Great Lakes stakeholders hands-on time with the evolving system in a staging environment. This frequent feedback loop prevented the requirement drift and miscommunication that had derailed their previous development attempt with a solo contractor. Communication cadence was structured to balance stakeholder involvement with developer productivity. Beyond the bi-weekly sprint reviews, FreedomDev maintained a shared Slack channel for asynchronous communication and weekly progress emails summarizing completed work, upcoming milestones, and any decisions needed from Great Lakes. The project lead was available for ad-hoc calls when urgent questions arose, but established boundaries around deep work time for developers. This communication structure gave Great Lakes visibility into progress without requiring excessive meetings that would slow development velocity. Risk mitigation was built into the project plan from the start. FreedomDev identified the GPS integration layer as the highest technical risk due to the lack of official API, so that component was prototyped and validated in the first sprint before committing to the full architecture. The team maintained a risk register that was reviewed weekly, tracking both technical risks like third-party service dependencies and business risks like the aggressive 14-week timeline. Contingency plans were documented for high-probability risks, including fallback approaches if the GPS provider blocked their scraping attempts. This proactive risk management prevented surprises and kept the project on schedule. Quality assurance was embedded throughout development rather than treated as a separate phase. Developers wrote unit tests for business logic components achieving 87% code coverage, and the team maintained an automated end-to-end test suite using Playwright that validated critical user workflows on every commit. The staging environment was continuously deployed from the main branch, allowing Great Lakes stakeholders to test new features within hours of completion. A dedicated load testing environment allowed performance validation under simulated production loads before each release. This continuous testing approach caught defects early when they were cheapest to fix and gave everyone confidence in the system's production readiness. --- ## Technical Architecture The fleet management platform architecture follows a microservices pattern with clear separation between data ingestion, processing, and presentation layers. The GPS adapter service runs as a Node.js application on AWS ECS, polling the third-party GPS provider every 15 seconds and publishing raw location events to a RabbitMQ queue. This queue-based architecture decouples the unreliable external data source from downstream processing, allowing the system to absorb temporary outages or rate limiting from the GPS provider without affecting the real-time dashboard. RabbitMQ provides durable message storage with configurable retention, so GPS events are never lost even if processing services experience downtime. The event processing pipeline consumes messages from RabbitMQ through a cluster of Node.js worker processes, with automatic horizontal scaling based on queue depth. Each event flows through a series of processors: enrichment with route and customer data from PostgreSQL, geofence evaluation using PostGIS spatial queries, ETA calculation using Google Maps Directions API with real-time traffic, and deviation detection comparing actual vs. planned routes. Processed events are written to PostgreSQL using batch inserts that group 50 events per transaction, reducing write amplification while maintaining sub-second latency. The processing pipeline handles backpressure gracefully by adding worker instances when queue depth exceeds 1,000 messages, then scaling down during off-peak hours. The PostgreSQL database uses table partitioning by date for the GPS events table, with daily partitions automatically created by a maintenance job. This partitioning strategy keeps query performance consistent as historical data accumulates, allowing the analytics dashboard to query months of historical data without degrading real-time operations. Indexes are carefully tuned for the query patterns that dominate system load: vehicle position lookups for the dashboard use a composite index on vehicle ID and timestamp, while geofence queries use GiST indexes on PostGIS geometry columns. The database runs on AWS RDS with automated backups and a read replica that handles analytics queries, isolating heavy reporting workloads from transactional operations. Security considerations influenced multiple architecture decisions throughout the system. The React dashboard communicates exclusively over HTTPS with certificate pinning to prevent man-in-the-middle attacks. WebSocket connections require JWT authentication tokens that expire after 4 hours, forcing periodic re-authentication without disrupting user sessions. All GPS data and customer information is encrypted at rest in PostgreSQL using AWS KMS-managed keys. Role-based access control enforces that dispatchers only see vehicles in their assigned territories, while audit logging tracks every route modification and notification sent for compliance and debugging purposes. FreedomDev conducted a security review with an independent consultant before production launch, addressing identified vulnerabilities like SQL injection risks and insufficient rate limiting on API endpoints. Scalability was designed into the system from the beginning to support Great Lakes' growth plans. The WebSocket server uses sticky sessions with a Redis-backed session store, allowing horizontal scaling across multiple application instances behind an Application Load Balancer. The event processing pipeline can scale to hundreds of worker instances if fleet size grows 10x, with queue-based load distribution preventing hot spots. Database scaling has clear paths: the current RDS instance can vertically scale to 10x current capacity, and the partitioned table structure enables archiving old data to S3 for cost-effective long-term storage. FreedomDev documented these scaling approaches in the system documentation handed off to Great Lakes, providing a roadmap for future growth. Monitoring and observability tools provide real-time visibility into system health and performance. CloudWatch dashboards display key metrics including event processing latency, WebSocket connection counts, database query performance, and API error rates. Custom application metrics track business-relevant indicators like GPS data freshness, geofence evaluation accuracy, and notification delivery rates. PagerDuty integration alerts the FreedomDev on-call engineer for critical issues like event processing lag exceeding 60 seconds or database connection pool exhaustion. This comprehensive monitoring caught several production issues in the first month of operation before they impacted users, including a memory leak in the WebSocket server that was patched within 4 hours of detection. --- ## Lessons Learned The week-long operations audit proved far more valuable than anticipated and directly influenced several critical architecture decisions. Observing actual dispatcher workflows revealed that they constantly context-switch between multiple information sources, so consolidating everything into a single dashboard wasn't just a convenience feature — it was essential for the system to be adopted. The audit also uncovered that drivers trusted their personal smartphone navigation apps more than company directions, which led FreedomDev to integrate Google Maps traffic data into ETA calculations rather than using simpler distance-based estimates. This upfront investment in understanding the problem deeply before writing code prevented expensive mid-project pivots. The decision to reverse-engineer the GPS provider's web portal rather than requiring hardware replacement was risky but ultimately correct. The approach saved Great Lakes over $90,000 in hardware costs and eliminated a major adoption barrier. However, this integration was more fragile than working with an official API — the GPS provider updated their portal twice during development, breaking the scraper both times and requiring emergency patches. In retrospect, FreedomDev would have negotiated harder with the GPS provider for official API access or built more sophisticated change detection to alert when the portal structure changes. The team did implement extensive integration tests that run hourly against the live GPS portal, providing early warning when changes break compatibility. Load testing with compressed historical data successfully identified performance bottlenecks before production launch, but the team underestimated the importance of realistic user behavior patterns. The load tests simulated GPS events at 3x expected volume but with uniform distribution throughout the day. In production, events spike dramatically during morning dispatch hours from 6-9 AM as drivers start routes, creating temporary hotspots that weren't revealed in testing. The system handled these spikes without incident thanks to over-provisioned infrastructure, but FreedomDev learned to model realistic usage patterns in load tests for subsequent projects. The team added more sophisticated load testing scenarios that replay actual timestamp distributions from historical logs. The bi-weekly sprint demos with Great Lakes dispatchers were crucial for building a usable interface, but they also created scope creep risks that required active management. Dispatchers would see working features and immediately imagine adjacent functionality they wanted, leading to a growing backlog of 'nice to have' requests. FreedomDev established a clear feature prioritization framework early on: requests that directly supported the core use cases of real-time tracking and route optimization were considered in-scope, while tangential features like driver performance scorecards were documented for a future phase 2. This transparent prioritization framework prevented misunderstandings about what would be delivered in the 14-week timeline. The handoff process to Great Lakes' internal IT team could have been smoother with better planning from the start. FreedomDev delivered comprehensive documentation and conducted training sessions for the two-person IT team who would maintain the system, but those staff members weren't involved in the project until the final two weeks. Involving them earlier in code reviews and deployment processes would have accelerated their learning curve. For the ongoing support contract, FreedomDev provides a 4-hour SLA on critical issues and monthly system health reviews, but Great Lakes handles routine maintenance like user account management and minor configuration changes. This hybrid support model balances cost with reliability. The project's success has led to an ongoing relationship with Great Lakes that extends beyond the initial development. FreedomDev completed a phase 2 project six months after initial launch that added a customer self-service portal, allowing Great Lakes clients to track their shipments and receive automated delivery notifications without requiring dispatcher intervention. The phase 2 work was faster and smoother because the technical foundation was already solid and the teams had established effective working patterns. Great Lakes has referred FreedomDev to two other companies in their industry network, demonstrating the value of delivering quality work that solves real business problems. For similar fleet management or logistics technology projects, FreedomDev's key advice is to invest heavily in understanding operational workflows before writing code, choose technologies that can scale with business growth, and plan for the reality that integrations with legacy systems are always harder than they appear. --- ## The Results - **50K+**: GPS events processed daily - **22%**: Reduction in fuel costs - **<1s**: Average event processing time - **35%**: Fewer missed delivery windows - **8**: ROI achieved in months - **41%**: Dispatcher overtime hours reduced - **+0.7 stars**: Customer satisfaction improvement - **$12K**: Average annual maintenance costs - **99.6%**: System uptime percentage - **14 weeks**: Time from kickoff to production --- ## Technologies - custom-software-development - mobile-development - database-services - systems-integration --- **Canonical URL**: https://freedomdev.com/case-studies/great-lakes-fleet _Last updated: 2026-05-14_