The Problem I Went Looking For
In early 2024, I flew to Nairobi with a laptop, a bag full of OBD-II adapters I'd ordered from Shenzhen, and a loose plan to spend three months understanding electric motorcycle fleet operations. Three months became six.
I embedded with a boda-boda cooperative that operated 40 electric motorcycles across three Nairobi neighborhoods — Kasarani, Roysambu, and part of Parklands. The fleet manager, Samuel, ran daily operations from a tiny cement-block office near the main charging shed. His management system was two laminated sheets of paper on the wall: one showing which bikes were "good," one showing which were "waiting."
The "waiting" list was supposed to be temporary. In practice, four to six bikes sat there at any given time, some for days, because nobody knew when a battery swap would actually fix the problem versus when the pack itself was too far gone.
Week Three: The Battery That Lied
On a Tuesday morning in week three, a driver named Peter came in early. His bike had cut out twice during his evening shift the previous day. The charge indicator showed 40% when it failed, which should have been plenty for a short neighborhood run. Samuel's team swapped the pack with a fully charged spare. Peter went back out. The replacement pack cut out at 38% that same afternoon.
The problem wasn't charge level. The problem was internal resistance. Both packs were reporting a healthy state-of-charge — the battery management system inside each one calculated SOC based on a voltage curve calibrated during manufacture. What it wasn't accounting for was the degradation that had accumulated over 18 months of Nairobi riding conditions: heat cycles, rapid charging on generators with unstable voltage, and occasional deep discharges when drivers worked late.
The pack's own BMS had no way to know it was lying. It reported what it could measure. I started thinking about what a system could do if it observed the full discharge curve over time instead of just the current voltage snapshot.
The First Build: Uglier Than You Think
By week five I had a working prototype. The hardware was a Raspberry Pi Zero W — about $35 at the time — stuffed into a waterproof project box from a hardware store on Tom Mboya Street. I connected it to the bike's OBD-II port via a cheap ELM327 Bluetooth dongle. A Python script polled voltage, current, and temperature every 60 seconds and wrote the data to a SQLite file locally.
When the bike returned to the shed and came within range of the Wi-Fi I'd set up (a TP-Link router zip-tied to a rafter), the Pi synced its SQLite file to a $5/month DigitalOcean droplet. A cron job ran a simple linear regression on the last 30 discharge events and posted a Telegram message if the degradation coefficient had crossed a threshold.
Samuel's message on the first morning he received an alert: "How does it know?" His bike number 17 had been flagged as the most likely to fail in the next seven days. He pulled that pack and tested it with the load tester he used for maintenance. It failed at 60% of rated capacity. He said it was the first time he'd caught a bad pack before it stranded a driver.
He asked me to put it on all 40 bikes. That request was the beginning of everything.
The Real Constraint: Mobile Data, Not Processing Power
The Wi-Fi sync worked fine for bikes that returned to the main shed. It didn't work for the six bikes that lived across town with drivers who charged at home. Those drivers had mobile data — sometimes. The sync approach failed completely on the days Safaricom's 3G coverage in their areas was spotty.
I tried a Hologram SIM in the Pi and a MQTT broker on the droplet. The connection dropped constantly — not because the signal was absent, but because the protocol expected reliable delivery guarantees that a 2G-grade connection couldn't provide. Every dropped packet triggered a retry storm that saturated the slim bandwidth available.
The fix was philosophically opposite to how most IoT systems work: stop trying to maintain a persistent connection. Buffer everything locally for up to 72 hours. When connectivity is available, send a batch. Design the data pipeline to be idempotent — receiving the same reading twice is harmless. This offline-first approach became the architectural foundation that Stima still runs on today.
The second lesson Nairobi taught us: reliable cloud connectivity is a product of infrastructure investment. Most EV fleet software is written by engineers in cities where that investment has already happened. We were building for the cities that come next.
From Cooperative to Company
By month four, Samuel's cooperative had the system on all 40 bikes. Unplanned downtime due to battery failure dropped from roughly 3 events per week to less than one. The drivers started trusting the alerts — which mattered because a driver who ignores an alert costs the cooperative a swap plus a tow plus a lost shift.
Samuel connected me with two other cooperative managers through a WhatsApp group he ran for Nairobi EV fleet operators. Both had exactly the same complaint: they were running blind on battery health and losing revenue to failures they couldn't predict. One was operating a mixed fleet — some Ecobodas, some Ampere Zeal bikes, some units sourced directly from a Shenzhen exporter. Three different battery chemistries. Three different BMS protocols. The same invisible degradation problem.
I came back to Paris in October 2024 with 14 gigabytes of discharge cycle data from three cooperatives, a dense notebook, and a clear problem statement. The software needed to be rebuilt from scratch — the Pi prototype was held together with duct tape and cron jobs. But the core insight was correct, and it had been validated in real conditions with real operators who had real money at stake.
Stima was incorporated in November 2024. The SEM-1 hardware module entered design review in January 2025. The Renew Capital term sheet came in September 2025.
What the €2.2M Is For
The seed round covers three things. First, manufacturing a proper run of SEM-1 units — not Raspberry Pi Zeros in project boxes, but purpose-built hardware with an ARM Cortex-M4 MCU, a proper Quectel EC21 modem, and a conformal-coated PCB that can handle the thermal environment inside a parked EV in Lagos in July. Second, expanding the ML training dataset. The current degradation models were trained on 18,000 discharge cycles from African EV motorcycles. We need 5x that volume, and we need Southeast Asian data because the temperature profiles in Jakarta and Bangkok are different from Nairobi's.
Third, the team. I've been doing too much myself. We're hiring two firmware engineers and a data engineer who understands time-series telemetry at scale. The platform currently handles 200 vehicles. The architecture is designed for 50,000. Closing that gap requires people who've done it before.
If you're building in the EV infrastructure space and you think the emerging market problem is the interesting one — it is — reach out at jason@stimaboda.org.
Filed under: Founding Story, Company News · Back to Blog