Launching a shared mobility service requires more than placing bicycles across a city and connecting them to a digital platform. Each bike must remain accessible, traceable, and visible to the team managing the fleet.
ShareAScoot had invested in a substantial fleet of bicycles with the ambition of launching a shared bike service across major Bulgarian cities. Its business model depended on smart locks capable of remote unlocking and locking, GPS tracking, and battery monitoring.
During setup and assembly, however, the company encountered a critical technical barrier. The purchased locks could not be integrated through the manufacturer’s standard API, while essential battery data remained inaccessible.
Without reliable communication between the bikes, locks, and future digital platform, the fleet could not operate at scale. ShareAScoot partnered with EVLabs to investigate the hardware, reverse-engineer the communication flow, and establish the technical foundation needed to make the service operational.
Before reaching out to EVLabs, ShareAScoot had already acquired the bicycles and smart locking equipment required for its planned bike-sharing service.
However, the technical limitations of the supplied hardware placed the entire investment at risk. The locks could not communicate reliably through the expected integration method, leaving the client without the remote fleet-management capabilities the business depended on.
The manufacturer-provided API did not support the intended integration.
As a result, the client could not reliably manage core functions such as remote locking and unlocking, GPS coordination, or communication with the future platform.
The system provided no usable way to retrieve battery levels from the installed locks.
For a shared mobility operator, this information is essential. Without battery visibility, the operations team could not identify devices requiring charging, replacement, inspection, or maintenance.
The available manufacturer documentation was not sufficient to resolve the issue through standard software development alone.
The team needed to investigate the physical modules, electrical connections, wiring, sockets, and data signals inside the bicycles and locks.
The fleet included different bicycle models and lock types, increasing the complexity of the integration.
Each configuration had to be examined and tested to determine how power and data were transferred and whether a consistent communication method could be established across the fleet.
The issue could not be isolated to a single API, server, or physical component.
Resolving it required coordinated investigation across embedded hardware, electrical connections, networking protocols, cloud infrastructure, and application-level communication.
Without functioning smart lock connectivity, ShareAScoot could not operate its planned service.
The bicycles had already been purchased, but their commercial value depended on reliable remote control and operational telemetry
The completed integration established the connected foundation required for ShareAScoot’s bike-sharing model.
The solution enabled:
By combining hardware investigation with custom cloud development, EVLabs transformed previously incompatible equipment into a manageable IoT ecosystem suitable for shared mobility operations.
EVLabs developed a custom hardware and software integration that established stable, bidirectional communication between the bicycles, smart locks, and cloud infrastructure.
Instead of relying on the manufacturer’s standard API, the team investigated how the devices communicated at both physical and network levels. This made it possible to identify the source of the incompatibility and build an alternative communication layer capable of processing lock data in real time.
Several bicycle models and lock types were brought into the EVLabs office, where the team created a dedicated R&D testing environment.
The physical modules were disassembled and examined, including:
This allowed the team to understand how power and information moved between the components despite the limited factory documentation.
The team mapped the physical connections and analyzed the data signals generated by the locks.
By examining the hardware directly, EVLabs identified communication patterns and isolated the points where data transfer was failing.
Where necessary, physical socket and wiring configurations were adjusted to support reliable communication between the bicycles and locking equipment.
A custom integration was developed to replace the unusable standard API connection.
The new communication layer enabled bidirectional data exchange through TCP/IP, allowing the system to send commands and receive device information.
This supported the core operational functions required by the business:
A key technical achievement was gaining reliable access to the locks’ battery levels.
Before the integration, battery telemetry could not be retrieved from the purchased hardware. EVLabs identified how the data was transmitted and made it available through the new system.
This created the operational foundation for charging, maintenance, inspections, and future battery-swapping activities.
EVLabs designed and deployed a custom web server to manage communication with the connected locks.
The cloud environment receives device messages, processes the relevant data, and returns commands in real time. It serves as the central communication point between the physical fleet and the wider software ecosystem.
The infrastructure was designed to provide a stable foundation that could support the fleet as the business expanded.
The completed solution enabled information to flow in both directions.
The platform could send instructions to individual locks while receiving GPS data, device status, and battery telemetry from the bicycles. This transformed the locks from isolated hardware components into remotely manageable IoT devices.
EVLabs followed an intensive engineering process combining physical inspection, iterative prototyping, network analysis, and cloud development.
The engagement began with a detailed inspection of the bicycles and smart locks. The team examined the sockets, wiring, cables, power lines, and internal lock connections to understand how the hardware had been assembled and how information was expected to move between components. This established an accurate technical picture before the software integration was redesigned.
With limited official documentation available, the team analyzed the hardware directly. Data signals, power flows, and communication patterns were mapped across the different bicycle and lock combinations. This helped the engineers identify inconsistencies and understand why the standard integration approach was failing.
The team carried out dozens of hands-on communication tests inside the EVLabs office. Different lock models and bicycles were connected, adjusted, and retested to isolate packet-transfer errors and identify the most reliable communication method. Each technical assumption was validated against the physical equipment.
Once a stable communication method had been established, the team developed the cloud-hosted server responsible for processing lock messages and remote commands. The custom infrastructure created a central layer through which the fleet could communicate with the future ShareAScoot platform.
The final stage focused on validating the complete communication flow. The team tested remote locking and unlocking, GPS coordination, incoming telemetry, battery-data retrieval, and server responses across the available hardware configurations. This confirmed that the solution worked as a connected system rather than a collection of isolated components.
A step-by-step overview of the key milestones, challenges, and progress throughout the project.
The project began with the bicycles and lock models being brought into the EVLabs office for direct investigation.
The team disassembled the relevant modules, examined the wiring and battery connections, and mapped the physical communication pathways between components.
During the second phase, EVLabs carried out repeated communication tests across the different hardware configurations.
The objective was to understand how the locks exchanged information, isolate data-packet errors, and develop a stable alternative to the manufacturer-provided API.
The final phase focused on developing and deploying the custom cloud web server.
The team connected the locks to the cloud environment, validated bidirectional communication, enabled remote fleet-control functions, and confirmed access to real-time battery telemetry.
Python Amazon Web Services AWS EC2 AWS IoT Core Custom Web Server Infrastructure
TCP/IP communication Custom API integration GPS APIs Telemetry APIs Bidirectional IoT communication
