EkoMobility
Replacing spreadsheet-based operations with a platform for managing drivers, vehicles, KYC, credit scoring, payments, and automatic reconciliation.

Since this platform is used internally, there is no live link to view.
EkoMobility is a Tanzanian mobility and asset financing company that helps drivers obtain motorcycles and tricycles (three-wheelers) through a rent-to-own financing model. Drivers use the vehicles to earn income while making regular daily payments toward ownership.
The company ran its entire operations on Google Sheets, which worked at the beginning but quickly became painful and tedious as the company grew. More vehicles meant more drivers, which meant more payment records, and since there was no way to accept payment online, drivers had to pay via bank while staff handled manual reconciliation every day. Imagine 1,000+ daily payments being inserted manually by staff in real time.
I built software that allowed them to handle their operations, including KYC, credit scoring, and payment collection, while taking into account the data they already had in Google Sheets, which was spread across 20,000+ rows in different workbooks and sheets. We also integrated with multiple payment providers, including mobile money and banks they were already using, to streamline reconciliation.
Before writing a single line of code, my goal was to understand the business and how it worked offline. This involved learning the full process, from KYC for a driver, to vehicle assignment, to payments, and finally to ownership at the end of the financing term.
After that, I had to learn their current process in Google Sheets: how they collected data, what kind of data they collected, and how they worked together in real time.
This was important because they already had data, and the solution I was going to create needed to adapt to that data without being constrained in terms of scalability.
To do this, I worked closely with the co-founders. I did not interact much with other staff and supervisors because the co-founders already understood most of what I needed and were directly involved in day-to-day operations.
After understanding all this, I introduced a framework for how we would work so we could have a shared understanding: Agile Product Development.
We started building the software one feature at a time, end to end.
For example, take the KYC feature.
What we wanted for the feature:
We did the same for each feature, which allowed parts of the software to become usable as they were completed.
| Before | After |
|---|---|
| Operations lived entirely in Google Sheets across 20,000+ rows spread over multiple workbooks. | More than 20,000 existing rows were migrated into a single system of record for KYC, credit scoring, and payments. |
| Drivers could only pay via bank transfer, so every payment had to be matched to a driver by hand. | Payments come in through the mobile money and bank providers they already used, and the system reconciles them automatically. |
| Staff manually inserted 1,000+ daily payment records in realtime, which didn't scale as the fleet grew. | Reconciliation happens without someone sitting at a spreadsheet all day, freeing staff to focus on drivers instead of data entry. |
| KYC and credit assessment were informal, tracked wherever a sheet or a conversation left off. | KYC capture, assessor review, and score calculation are one connected flow with a clear accept/reject outcome at the end. |
The biggest pain point going in was reconciliation. With no online payment option, every driver payment meant a staff member cross-checking a bank statement against a spreadsheet, every day, by hand. That doesn't scale past a handful of drivers, and EkoMobility was well past that. Integrating directly with the mobile money and bank providers they already accepted payments through meant payments could match to a driver automatically instead of depending on someone catching it manually.
This project was the first time I had worked directly with banks and their integrations. I initially thought it would be as simple as calling an API like Paddle, but I was wrong. There are many complications, especially when you are doing it for the first time.
The biggest one was VPNs. Banks do not just hand you an API key and let you start calling endpoints. Most of them require a VPN connection before their systems will even talk to you. That meant setting up VPNs to communicate with each bank, then configuring a VPN switch on my own local machine so I could actually reach those endpoints and test the integration while building, instead of only finding out something was broken once it hit a server that had access.
Working through those VPN requirements was a major lesson. It is one of those things you do not learn in school. You only learn it by sitting down and working through a real integration.