Route One

Background

The initial goal was straightforward: build an Electronic Logging Device (ELD) solution for our own fleet of approximately 150 trucks, validate it in real operations, and eventually turn it into a subscription-based product for the broader market.

The challenge was that nobody on the product, design, or engineering side had prior experience with ELD systems. We were entering a highly regulated industry where mistakes could result not only in poor user experience, but also in compliance violations, failed inspections, and operational risks for carriers.

My role

As Product & Project Lead, I was responsible for taking the product from the first concept through research, planning, design, validation, implementation, and commercial readiness.

My responsibilities included:

• domain discovery and regulatory research;
• stakeholder interviews and requirements gathering;
• product strategy and roadmap planning;
• UX/UI design for both mobile and web platforms;
• user flow design and information architecture;
• design system creation;
• sprint planning and release coordination;
• collaboration with developers, QA engineers, compliance specialists, and management;
• user testing and product validation.

I personally designed the driver application and the web-based administration platform used by dispatchers, fleet owners, safety managers, and compliance personnel.

The primary objective was to balance three often competing factors: FMCSA compliance requirements; operational needs of trucking companies; usability and safety for drivers.

Discovery and domain research

The amount of initial information was surprisingly limited.

We had access to several competitor products, FMCSA regulations, technical documentation, certification requirements, correspondence with FMCSA regarding critical compliance questions, and a handful of contacts across different departments, including drivers.

The biggest challenge was access to users.

Truck drivers are busy earning money, not participating in product interviews. Initial response rates were low, so we eventually introduced financial incentives to encourage participation in interviews, surveys, and usability testing.

Since nobody on the technical team had previous ELD experience, we started by studying FMCSA regulations, ELD technical specifications, certification requirements, inspection procedures, testing documentation, and Hours of Service (HOS) regulations.

Only after building a solid understanding of the domain did we begin mapping user journeys, defining system actors, documenting use cases, and designing workflows.

Over the following years we conducted more than 50 interviews with drivers, dispatchers, safety managers, fleet owners, and compliance personnel to better understand operational realities and edge cases.

Understanding the complexity

Very quickly it became clear that ELD was not simply a mobile application.

Even the MVP consisted of several interconnected systems:

• Driver Mobile Application (iOS)
• Driver Mobile Application (Android)
• Fleet Management Web Platform
• Vendor Telematics SDK Integrations
• FMCSA Data Transfer Infrastructure
• Compliance Monitoring Tools

The platform served multiple user groups: Drivers; Dispatchers; Fleet Owners; Safety Managers; Compliance Officers.

For someone unfamiliar with trucking, every new workflow felt like someone poured four different colors of paint into a bucket, mixed them together, and then asked you to separate them again.

The additional complexity came from the fact that this was a compliance-driven product.

In many SaaS products, temporary workarounds are acceptable. In ELD systems, especially when dealing with Hours of Service calculations, there is very little room for interpretation.

Either the calculations are correct, or the product fails compliance requirements.

Split Sleeper Berth and the real challenge

Initially, driver status management appeared to be the most difficult part of the system.

Then we encountered Split Sleeper Berth.

That was when the real challenge began.

We visited several ELD providers to understand how they approached calculations, studied real-world examples, reviewed regulations repeatedly, and spent countless hours validating edge cases.

Developers spent weeks testing timeline calculations and visual representations of HOS availability.

One particularly valuable resource was the FMCSA ELD Output File Validator.

This tool validates ELD output files and identifies compliance issues, logical inconsistencies, and formatting errors. Throughout development it became one of our primary verification mechanisms.

The experience taught us an important lesson: understanding regulations is one thing; translating them into reliable software logic is something entirely different.

Designing for multiple roles

Beyond compliance calculations, a significant portion of the work involved designing workflows for completely different user groups.

Each role interacted with the platform in different ways and had different objectives.

Drivers focused on daily operations, inspections, and logbook management.

Dispatchers required visibility into fleet activity and driver availability.

Safety managers needed compliance monitoring, violation tracking, and audit preparation.

Fleet owners wanted operational visibility and business insights.

To support these needs, we mapped end-to-end user journeys for multiple roles and designed workflows covering:

• HOS logging;
• inspections;
• log edits;
• violation management;
• unidentified driving events;
• device assignment;
• compliance reviews;
• roadside inspection scenarios.

A large part of the design effort focused on reducing cognitive load and minimizing the number of actions required to complete mandatory tasks.

First driver rollout

After nearly a year of research, planning, design, development, and compliance validation, we onboarded our first driver.

Although we were confident in the product, we still asked him to carry a paper logbook as a backup and prepared dedicated testing documentation to minimize potential issues during roadside inspections.

The pilot was successful.

We then expanded to five drivers and immediately discovered another reality of the trucking industry:

Identical trucks do not mean identical driver behavior.

This led directly to the implementation of Unidentified Driver Records (UDR) workflows.

We were aware of UDR requirements from FMCSA documentation, but real-world operations forced the feature onto the roadmap much sooner than expected.

Driver-safe UX

There is a common belief that an MVP should consist of three buttons and a spreadsheet-style interface.

We deliberately rejected that approach.

We already knew the market existed.

More importantly, we understood that drivers would spend hours interacting with the application in demanding environments.

Driver safety became a product requirement, not a design enhancement.

From the beginning we invested in:

• clear information hierarchy;
• readable typography;
• optimized navigation;
• accessible interactions;
• scalable design systems;
• dark mode support.

The goal was not only regulatory compliance but also reducing distraction and making daily workflows as efficient as possible.

Real-world testing

Unlike many traditional B2B SaaS products, ELD systems cannot be validated exclusively in meeting rooms.

A significant amount of learning came from real-world testing.

We conducted usability sessions, observed operational workflows, collected feedback from actual drivers, analyzed inspection scenarios, and continuously reviewed real logbook data.

Throughout the project we accumulated approximately 2,000 kilometers of road testing to better understand visibility, interaction safety, and real-world usage conditions.

Many assumptions that seemed correct during design changed completely once exposed to real operating environments.

Field testing revealed dozens of edge cases that would have been impossible to identify through office-based planning alone.

Expanding beyond compliance

Once the core ELD functionality became stable and compliant, we shifted focus toward fleet management capabilities.

The roadmap expanded to include:

• IFTA Reporting;
• Device Management;
• Current Vehicle Location;
• Location History;
• Driver Profiles;
• Operational Analytics;
• Fleet Administration Tools;
• Violation Monitoring;
• Maintenance-Related Features.

At the same time we improved platform stability, resolved critical issues, refined the user experience, expanded administrative capabilities, and launched a commercial website.

The product gradually evolved from a compliance tool into a broader fleet operations platform.

Monetization strategy

One of the most important business discussions revolved around pricing.

After analyzing the market and competitor offerings, we concluded that everything required by FMCSA should remain part of the core product.

Monetization would come from operational and analytical capabilities, including:

• IFTA tools;
• Driver History;
• Fuel Stop Analytics;
• Operational Reporting;
• Fleet Insights;
• Administrative Features.

This approach lowered adoption barriers while creating clear upgrade opportunities for commercial customers.

Why we delayed sales

One decision that often surprised people was our reluctance to aggressively monetize the platform immediately after launch.

The reason was simple.

In trucking, software reliability matters more than marketing speed.

If a social media application fails, users become annoyed.

If an ELD system fails, carriers may face compliance violations, operational disruption, and financial consequences.

Because of this, product quality took priority over subscription revenue.

Before scaling sales efforts, we wanted confidence that the system could withstand real-world operations.

Throughout development we continuously benchmarked industry leaders such as Samsara and Motive, analyzed market trends, evaluated competitor functionality, and identified opportunities where our product could provide additional value.

Many roadmap decisions were influenced by this research.

Outcome

What began as an internal compliance initiative for a fleet of 150 trucks evolved into a fully operational ELD platform used by trucking companies across the United States.

The project required deep regulatory research, extensive stakeholder interviews, complex HOS logic implementation, field testing, cross-functional collaboration, and continuous iteration.

Most importantly, it demonstrated that building successful products in regulated industries requires far more than good design or clean code. It requires a deep understanding of legislation, operational realities, user behavior, and the discipline to validate assumptions in the real world before scaling.