About the project
Trans.eu is one of the largest freight exchanges in Europe, connecting thousands of freight forwarders, shippers, and carriers every day.
For years, Trans.eu maintained its own in-house integration module with more than 120 telematics providers, embedded within its fleet management module. Carriers configured their vehicles and connected GPS devices there to share real-time location data for use within the freight exchange. However, adoption of this solution was limited by structural rather than technical factors. Full visibility into operational data—such as vehicle downtime, breakdowns, and actual route progress—was not always aligned with the interests of carriers. For many of them, the perceived complexity of the integration process served as a convenient justification for avoiding data sharing.
The answer to this adoption challenge was CO³, a Polish telematics aggregator integrating dozens of GPS providers and exposing vehicle location data based on license plate numbers. This model removed carriers from the integration process entirely. Vehicle identification was performed using information provided by the shipper, eliminating the need for any configuration on the carrier's side. As a result, the argument that telematics integration was too complex was no longer valid.
CO³'s main limitation, however, was fleet coverage. As a niche domestic provider, it covered only a relatively small percentage of the vehicles operating within the Trans.eu ecosystem. The next stage of the platform's evolution was the implementation of Project44—a global telematics aggregator with significantly broader international coverage and a modern event-driven architecture based on webhooks. The integration with Project44 introduced a push-based communication model and ultimately led to the decision to decommission the internal telematics module, whose continued maintenance was no longer economically justified.
fireup.pro participated in this nearly five-year transformation at every stage - from developing the original in-house telematics system, through integrating CO³ and Project44, to the final decommissioning of the legacy telematics module.
Business
Technological
Customer experience
The fireup.pro team executed the project with great efficiency and professionalism. Thanks to their commitment, we are able to further expand the use of data across our organization.
Piotr Sobala
Product Owner Trans.eu
From challenge
Key Challenges
An adoption barrier driven by conflicting stakeholder incentives
An adoption barrier driven by conflicting stakeholder incentives
The in-house telematics system required carriers to actively configure their fleets, providing full visibility into their operational data. For some carriers, the perceived complexity of the integration process served as a justification for not adopting the solution. The new approach had to eliminate the possibility of using this argument altogether, rather than merely reducing the effort required for integration.
Insufficient fleet coverage as a scaling bottleneck
Insufficient fleet coverage as a scaling bottleneck
The integration with CO³ was technically sound, but its impact was limited by the provider's relatively small fleet coverage. Even a well-designed data model could not deliver meaningful business value without sufficient fleet coverage at scale.
Negotiating power asymmetry driven by the scale of the integration partner
Negotiating power asymmetry driven by the scale of the integration partner
With CO³ a niche provider Trans.eu defined the integration specification. In contrast, integrating with Project44, a provider with comparable or greater market scale, required a collaborative, partnership-based approach. The solution was co-designed through regular roadmap alignment and recurring technical workshops involving engineering teams from both organizations.
A phased migration from a synchronous model to an event-driven architecture
A phased migration from a synchronous model to an event-driven architecture
The in-house telematics system relied on continuous polling with a 30-second interval. The CO³ integration retained the polling model, but queries were limited to the active time window of a transport order due to a pricing model based on the number of API requests. A true event-driven architecture based on webhooks was introduced only with the Project44 integration, requiring a fundamentally different approach centered on passive processing of incoming events.
The gap between the promised and actual value of the integration framework's abstraction layer
The gap between the promised and actual value of the integration framework's abstraction layer
Enterprise integration frameworks such as Mule ESB and, later, Apache Camel were selected to reduce the marginal cost of integrating additional telematics providers by leveraging reusable integration components. In practice, however, each provider required a custom-built connector. As a result, the framework's abstraction layer remained largely unused while introducing maintenance costs that were disproportionate to the functionality it actually delivered.
Use cases beyond simple vehicle location tracking
Use cases beyond simple vehicle location tracking
Trailer tracking independent of the tractor unit, verification of driver hours-of-service compliance (tachograph data), and validation of mileage for settlement and billing purposes were all supported by the platform. However, these capabilities became practically valuable only after Project44 provided fleet coverage at a scale sufficient to make the data broadly available.
Through the solution
Through the solution
Phase 1 - the in-house telematics system
Originally implemented by Bluesoft on Mule ESB, the system was later taken over and further developed by the fireup.pro team as part of the Trans.eu engineering organization. Mule ESB proved costly to maintain due to its XML-based configuration, significant resource consumption, and limited scalability. As a result, the integration layer was migrated to Apache Camel—a framework of the same enterprise integration class that enabled integration logic to be implemented in plain Java.
The system operated as a dedicated module, communicating with the rest of the Trans.eu platform through well-defined contracts. It continuously polled more than 120 telematics providers every 30 seconds, retrieving vehicle location data in real time.
Phase 2 - CO³ integration
Designed with the goal of minimizing changes to the existing polling-based architecture. Instead of migrating to an event-driven model, the team retained the polling mechanism while limiting it to the time window associated with a specific transport order.
Phase 3 - Project44 integration and migration to an event-driven architecture
This phase introduced a true event-driven model. Instead of relying on polling, Project44 notified Trans.eu of vehicle location updates through webhooks, eliminating the need for continuous API requests.
Due to Project44's scale and market position, the integration was delivered through a collaborative engineering model. Teams from both organizations held regular technical meetings, continuously synchronized development progress, and jointly defined the integration specifications.
Reduction of technology stack complexity
With no new telematics providers being added, the Project44 integration was implemented in plain Java, bypassing Apache Camel altogether. This approach resulted in lower maintenance costs than continuing to rely on a framework whose abstraction layer was no longer delivering sufficient value.
Decommissioning the in-house telematics module
Once Project44 achieved sufficient fleet coverage, the decision was made to fully retire the remaining integrations with individual GPS providers. The functionality still required by other parts of the platform—primarily the mapping module—was migrated directly into the target systems, eliminating the need to maintain a separate telematics module. The decommissioning of the in-house telematics module marked the final stage of the project.
To the success
Technological outcomes
An event-driven architecture, introduced as part of the Project44 integration, replaced both the continuous polling model of the in-house system and the time-limited polling approach used in the CO³ integration.
Consolidation of the integration layer around a single external provider with broad fleet coverage, replacing more than 120 direct telematics integrations as well as the additional CO³ integration.
Reduction of the technology stack's complexity by replacing enterprise integration frameworks (Mule ESB → Apache Camel) with plain Java implementations in areas where the framework's abstraction layer no longer provided meaningful value.
Decommissioning of obsolete infrastructure by retiring the in-house telematics module and migrating the required functionality directly into the target systems.
Business benefits
Elimination of the carrier-side adoption barrier by enabling vehicle identification based solely on the license plate number, without requiring any configuration or involvement from the carrier.
The ability to execute a decommissioning strategy by recognizing when the original model continuous in-house fleet monitoring, no longer delivered a return on investment, and decisively retiring the unnecessary infrastructure.
Mileage verification for settlements between shippers and carriers based on telematics data rather than self-reported information.
Reduced maintenance costs by transferring responsibility for telematics integrations to a specialized external provider, eliminating the need to maintain dozens of direct integrations and a dedicated telematics module.
A significant increase in the practical value of telematics data resulting from the transition from CO³, with its limited fleet coverage, to Project44, whose coverage extended across the majority of the fleet operating on the Trans.eu platform. The business model delivered its intended value only after the integration partner reached the necessary scale.
Project team
Adam
Tech stack
Java
Python
Spark
RabbitMQ
Apache Camel
Mule ESB
MySQL
PostgreSQL
Amazon ECS
Amazon RDS
Docker
Your success is our success
See how we can build a technological advantage for your company together.
We have a team that truly knows its stuff — we'll help you find a solution that works.
Conclusions & recommendations
Adoption barriers are not always technical - they are often structural. The in-house telematics system functioned correctly from a technical perspective, but it failed to address the underlying issue: the conflict between full operational data transparency and the interests of some carriers. The solution was not to optimize the integration process, but to redesign the integration model in a way that eliminated the carrier's involvement altogether.
Enterprise integration frameworks are justified only when their abstraction layer is fully utilized. Mule ESB and Apache Camel were intended to reduce the marginal cost of integrating additional providers. In practice, however, each telematics provider required a dedicated connector implementation, limiting the value delivered by the framework relative to its maintenance cost.
The scale of an integration partner determines the nature of the technical collaboration. Integrating with a niche provider such as CO³ allowed Trans.eu to define the integration specification unilaterally. In contrast, integrating with a provider of comparable market scale such as Project44 required a partnership-based approach, with joint solution design and continuous roadmap alignment between both engineering teams.
A business model may require several iterations of implementation before delivering its intended value. The core concept—providing vehicle location data without requiring carrier involvement - remained unchanged across three successive implementations (the in-house system, CO³, and Project44). What changed was the integration provider, until the required scale was achieved to unlock the model's full business value.
Decommissioning a system is just as important as implementing one. Recognizing the point at which the original solution no longer delivers a return on investment and decisively retiring the unnecessary infrastructure is an integral part of the project lifecycle, not an afterthought.
