The software is only done when the lock actually opens.
In many software projects, responsibility ends at an API or screen. At ParkMyBike, that is exactly where an important part of the problem begins. A cyclist reserves a spot in the app, then stands physically in front of a locker and expects exactly the right lock to open. For that, app, backend, permissions, reservation, network connection, controller and hardware all have to tell the same story.
The case in brief
App, dashboard, backend and hardware
BLE, IoT and different lock systems
23 new locations and 122 parking spaces
900 new users in that same expansion
Why is software + hardware hard?
In an ideal world, the app sends a command and a lock opens. In the real world there are Bluetooth permissions, poor connections, different controllers, batteries, external suppliers, timeouts, outdated status information and users literally standing in front of a closed door.
See the approachNot every location uses the same hardware
ParkMyBike supports different types of locks, controllers and IoT setups. Some locks are controlled through a cloud connection, others directly via Bluetooth or an external access solution. The software has to absorb those differences without becoming a new product for every installation.
Digital status and physical reality can diverge
A backend thinking a command was sent successfully does not automatically mean a mechanical lock actually moved. That is why we record actions, hardware status, connections and lock events and handle errors explicitly throughout the chain.
Problems happen outdoors
Poor coverage, Bluetooth switched off, a flat battery, a wrong port configuration or a controller that does not respond: these are production problems you do not encounter in a tidy local development environment.
How did we approach it?
- 01
One domain for different hardware
In the backend we model locations, lockers, locks, ports and IoT devices independently of the specific brand. That way the same reservation and user logic keeps working on top of different technical solutions.
- 02
The backend decides what has to happen
The mobile app does not need to know all protocols and lock logic on its own. In BLE flows, the backend coordinates the session and issues commands for, among other things, connect, read, write and disconnect. The phone does the local Bluetooth work and sends the results back.
- 03
Connect existing hardware where that is smarter
We do not automatically build our own solution for everything. ParkMyBike integrates with, among others, Particle, EVVA, SAS and iLOQ, and we also built an integration through which Epsilon Cities hardware communicates with our backend via a messaging infrastructure.
- 04
Build our own hardware where needed
For use cases where existing hardware does not fit well enough, we also develop our own BLE controller firmware. That way software, protocol and physical control can be designed as one system instead of as separate parts.
What did we build?
ParkMyBike is a chain of software and hardware that together deliver a physical service.
Apps that operate real locks
The iOS and Android apps support reservations, subscriptions and opening bike lockers. For BLE, the phone connects locally to the device, while the backend coordinates the workflow, authorisation and protocol steps.
A backend for both software and physical infrastructure
The Elixir backend manages users, locations, reservations, subscriptions, payments, lockers, locks, IoT devices and ports. It also processes real-time updates, hardware events, maintenance tasks and integrations with external systems.
Controller and manufacturer integrations
We have supported several hardware paths, from Particle devices and BLE controllers to external lock platforms. For Epsilon Cities, for example, we built two-way communication in which devices report their status and the backend can send actions to specific ports.
One platform, several kinds of hardware
We do not try to force reality into one technical model. Different installations sometimes call for different forms of communication, as long as the product flow on top stays consistent.
Cloud-connected controllers
Particle hardware can send events to the backend and receive commands from the platform. Incoming events are first queued durably before further processing takes place.
Bluetooth close to the user
With BLE, the phone is physically close to the lock. The app handles scanning and GATT communication, while the server decides which actions are allowed and which protocol step comes next.
External ecosystems
For systems such as iLOQ and other hardware partners, we integrate with their own access technology and infrastructure instead of reinventing it. ParkMyBike remains the product layer for the user, reservation and management.
What does that deliver?
The same software can work with different physical solutions
A provider does not always have to replace its entire hardware fleet to use ParkMyBike. By putting the hardware behind a clear integration layer, different lockers, controllers and access technologies can coexist within the same platform.
Hardware problems become manageable in software
Status, last-seen information, battery warnings, lock events and maintenance flows make visible what happens outdoors. This lets support determine much more precisely whether a problem lies in the account, reservation, app, network, controller or physical lock.
The system works at real locations
In 2025, ParkMyBike expanded with 23 locations and 122 new parking spaces, including in the United Kingdom and Belgium. In the same period, about 900 new users joined. So the technology does not just run in a lab, but in real bicycle parking infrastructure.
The integration does not stop at an API call
What makes ParkMyBike interesting is that errors do not stay abstract. If an integration is wrong, someone is standing in front of a locker that does not open. That is why reliability, retries, state management and observability are at the core of the product.
View casesBluetooth with timeouts and retries
The mobile BLE flows have explicit timeouts for, among other things, scanning, connecting and commands. For recoverable errors, sessions can be rebuilt, while old callbacks must not disturb a new connection.
The physical action is part of the business flow
A successful open action can move a reservation from 'reserved' to 'rented' and start real-time updates. Hardware behaviour is therefore part of the product logic itself and not a separate technical integration.
Hardware is monitored operationally
IoT devices have, among others, online, offline and low-battery statuses. Hardware events are processed and actions are stored, so problems can be investigated and maintenance carried out in a targeted way.
Related AI challenges
We can't get the solution connected to existing systems
The AI works on its own, but the real value sits behind APIs, databases and business software where the integration gets stuck.
View use caseReplace several existing tools with one smart custom workflow
The process has become fragmented across several tools, spreadsheets and manual handoffs. You want to bring it back to one coherent workflow.
View use caseOur AI prototype has to go to production
The prototype proves the idea works. Now it has to become reliable, secure and manageable enough for real users and real business processes.
View use caseBuild & Integrate
We build the software layer around existing systems and hardware, including backend, integrations, apps, protocols, monitoring and the error handling needed to make it work reliably in practice.
View offerFixed price after scoping
- Result
- Production-ready integration between software and the real world
- Duration
- Depends on scope
- Next step
- First we map systems, hardware, protocols and critical failure modes