De software is pas klaar als het slot echt opengaat.
Bij veel softwareprojecten eindigt de verantwoordelijkheid bij een API of scherm. Bij ParkMyBike begint daar juist een belangrijk deel van het probleem. Een fietser reserveert een plek in de app, staat vervolgens fysiek voor een kluis en verwacht dat precies het juiste slot opent. Daarvoor moeten app, backend, rechten, reservering, netwerkverbinding, controller en hardware allemaal hetzelfde verhaal vertellen.
Case in het kort
App, dashboard, backend én hardware
BLE, IoT en verschillende slotsystemen
23 nieuwe locaties en 122 parkeerplekken
900 nieuwe gebruikers in diezelfde uitbreiding
Waarom is software + hardware lastig?
In de ideale wereld stuurt de app een commando en gaat een slot open. In de echte wereld zijn er Bluetooth-permissies, slechte verbindingen, verschillende controllers, batterijen, externe leveranciers, timeouts, verouderde statusinformatie en gebruikers die letterlijk voor een dichte deur staan.
Bekijk de aanpakNiet iedere locatie gebruikt dezelfde hardware
ParkMyBike ondersteunt verschillende typen sloten, controllers en IoT-opstellingen. Sommige sloten worden via een cloudverbinding aangestuurd, andere rechtstreeks via Bluetooth of een externe toegangsoplossing. De software moet die verschillen kunnen opvangen zonder voor iedere installatie een nieuw product te worden.
Digitale status en fysieke werkelijkheid kunnen uit elkaar lopen
Dat een backend denkt dat een commando succesvol is verstuurd, betekent nog niet automatisch dat een mechanisch slot daadwerkelijk heeft bewogen. Daarom registreren we acties, hardwarestatus, verbindingen en lock events en behandelen we fouten expliciet door de hele keten.
Problemen gebeuren buiten
Slechte dekking, Bluetooth dat uitstaat, een lege batterij, een verkeerde poortconfiguratie of een controller die niet reageert: dit zijn productieproblemen die je niet tegenkomt in een nette lokale developmentomgeving.
Hoe hebben we het aangepakt?
- 01
Eén domein voor verschillende hardware
In de backend modelleren we locaties, kluizen, sloten, poorten en IoT-devices los van het specifieke merk. Daardoor kan dezelfde reserverings- en gebruikerslogica boven verschillende technische oplossingen blijven werken.
- 02
De backend bepaalt wat er moet gebeuren
De mobiele app hoeft niet zelfstandig alle protocollen en slotlogica te kennen. Bij BLE-flows coördineert de backend de sessie en geeft hij opdrachten voor onder andere connect, read, write en disconnect. De telefoon voert het lokale Bluetoothwerk uit en stuurt resultaten terug.
- 03
Bestaande hardware koppelen waar dat slimmer is
We bouwen niet automatisch onze eigen oplossing voor alles. ParkMyBike integreert onder andere met Particle, EVVA, SAS en iLOQ en we bouwden ook een koppeling waarmee hardware van Epsilon Cities via een berichteninfrastructuur met onze backend communiceert.
- 04
Eigen hardware bouwen waar dat nodig is
Voor use cases waar bestaande hardware niet goed genoeg aansluit, ontwikkelen we ook eigen BLE-controllerfirmware. Zo kunnen software, protocol en fysieke aansturing als één systeem worden ontworpen in plaats van als losse onderdelen.
Wat hebben we gebouwd?
ParkMyBike is een keten van software en hardware die samen een fysieke dienst levert.
Apps die echte sloten bedienen
De iOS- en Android-apps ondersteunen reserveringen, abonnementen en het openen van fietskluizen. Voor BLE maakt de telefoon lokaal verbinding met het apparaat, terwijl de backend de workflow, autorisatie en protocolstappen coördineert.
Een backend voor zowel software als fysieke infrastructuur
De Elixir-backend beheert gebruikers, locaties, reserveringen, subscriptions, betalingen, kluizen, sloten, IoT-devices en poorten. Hij verwerkt bovendien realtime updates, hardware-events, onderhoudstaken en integraties met externe systemen.
Controller- en fabrikantintegraties
We hebben meerdere hardwarepaden ondersteund, van Particle-devices en BLE-controllers tot externe slotplatforms. Voor Epsilon Cities maakten we bijvoorbeeld tweerichtingscommunicatie waarbij apparaten hun status doorgeven en de backend acties naar specifieke poorten kan sturen.
Eén platform, meerdere soorten hardware
We proberen de werkelijkheid niet in één technisch model te dwingen. Verschillende installaties vragen soms om verschillende vormen van communicatie, zolang de bovenliggende productflow maar consistent blijft.
Cloud-connected controllers
Particle-hardware kan gebeurtenissen naar de backend sturen en opdrachten vanuit het platform ontvangen. Inkomende events worden eerst duurzaam gequeued voordat de verdere verwerking plaatsvindt.
Bluetooth dichtbij de gebruiker
Bij BLE zit de telefoon fysiek dicht bij het slot. De app verzorgt scanning en GATT-communicatie, terwijl de server bepaalt welke acties toegestaan zijn en welke protocolstap volgt.
Externe ecosystemen
Voor systemen zoals iLOQ en andere hardwarepartners integreren we met hun eigen toegangstechniek en infrastructuur in plaats van die opnieuw uit te vinden. ParkMyBike blijft daarbij de productlaag voor gebruiker, reservering en beheer.
Wat levert dat op?
Dezelfde software kan met verschillende fysieke oplossingen werken
Een provider hoeft niet altijd zijn complete hardwarepark te vervangen om ParkMyBike te gebruiken. Door de hardware achter een duidelijke integratielaag te zetten kunnen verschillende lockers, controllers en toegangstechnieken binnen hetzelfde platform bestaan.
Hardwareproblemen worden softwarematig beheersbaar
Status, last-seen informatie, batterijwaarschuwingen, lock events en onderhoudsflows maken zichtbaar wat er buiten gebeurt. Daardoor kan support veel gerichter bepalen of een probleem in account, reservering, app, netwerk, controller of fysiek slot zit.
Het systeem werkt op echte locaties
In 2025 breidde ParkMyBike uit met 23 locaties en 122 nieuwe parkeerplekken, onder andere in het Verenigd Koninkrijk en België. In diezelfde periode kwamen er ongeveer 900 nieuwe gebruikers bij. De techniek draait dus in echte fietsparkeerinfrastructuur, niet alleen in een lab.
De integratie stopt niet bij een API-call
Het interessante aan ParkMyBike is dat fouten niet abstract blijven. Als een integratie niet klopt, staat iemand voor een kluis die niet opengaat. Daarom zitten betrouwbaarheid, retries, state management en observability in de kern van het product.
Bekijk casesBluetooth met timeouts en retries
De mobiele BLE-flows hebben expliciete timeouts voor onder andere scanning, verbinden en commando's. Bij herstelbare fouten kunnen sessies opnieuw worden opgebouwd, waarbij oude callbacks niet een nieuwe verbinding mogen verstoren.
De fysieke handeling is onderdeel van de businessflow
Een succesvolle openactie kan een reservering van 'gereserveerd' naar 'gehuurd' zetten en realtime updates starten. Hardwaregedrag is dus onderdeel van de productlogica zelf en geen losse technische koppeling.
Hardware wordt operationeel gemonitord
IoT-devices hebben onder andere online-, offline- en low-battery-statussen. Hardware-events worden verwerkt en acties worden opgeslagen, zodat problemen onderzocht en onderhoud gericht uitgevoerd kunnen worden.
Gerelateerde AI-vraagstukken
We krijgen de oplossing niet gekoppeld aan bestaande systemen
De AI werkt op zichzelf, maar de echte waarde zit achter API's, databases en bedrijfssoftware waar de integratie vastloopt.
Bekijk vraagstukVerschillende bestaande tools vervangen door één slimme maatwerkflow
Het proces is versnipperd geraakt over meerdere tools, spreadsheets en handmatige overdrachten. Je wilt het terugbrengen naar één samenhangende workflow.
Bekijk vraagstukOns AI-prototype moet naar productie
Het prototype bewijst dat het idee werkt. Nu moet het betrouwbaar, veilig en beheersbaar genoeg worden voor echte gebruikers en echte bedrijfsprocessen.
Bekijk vraagstukBuild & Integrate
We bouwen de softwarelaag rond bestaande systemen en hardware, inclusief backend, integraties, apps, protocollen, monitoring en de foutafhandeling die nodig is om het in de praktijk betrouwbaar te laten werken.
Bekijk aanbodVaste prijs na scope
- Resultaat
- Productieklare integratie tussen software en de echte wereld
- Doorlooptijd
- Afhankelijk van scope
- Volgende stap
- Eerst brengen we systemen, hardware, protocollen en kritieke failure modes in kaart