I got a call on a random morning earlier this year by a potential client, we got to chat about his proposal a few days letter we agreed on the price and everything and I was officially contracted. It is the biggest project I ever undertook and would cause me literally countless nights sitting staring at the Daraja API docs. Back then I was an intermediate developer in both mobile and web development. My tech stack being React.js, React Native and express for the back-end was the most ideal for the project given that it was a mobile and web based platform. The platform is Tumalock, an escrow platform for securely doing online transactions. The web was completed a while ago and the mobile is currently in review and should be available to download in google play in a few days from when …
I got a call on a random morning earlier this year by a potential client, we got to chat about his proposal a few days letter we agreed on the price and everything and I was officially contracted. It is the biggest project I ever undertook and would cause me literally countless nights sitting staring at the Daraja API docs. Back then I was an intermediate developer in both mobile and web development. My tech stack being React.js, React Native and express for the back-end was the most ideal for the project given that it was a mobile and web based platform. The platform is Tumalock, an escrow platform for securely doing online transactions. The web was completed a while ago and the mobile is currently in review and should be available to download in google play in a few days from when I’m writing this.
The back-end was particularly difficult given that it is an escrow platform and for those who are familiar with the daraja API would definitely understand. For context there is a telegram channel where people share their daraja API horror stories. Escrow workflows are not straightforward. They are state-dependent financial transactions, and when integrating with M-Pesa, there are several complexities that must be managed carefully. From the STK push initiation, the callback handling and verification, the escrow logic layering, handling timeouts, partial failures and payment unlocks. This required careful transaction state management, idempotency safeguards and database level consistency guarantees otherwise you would risk duplicates in the database. And that is how I spent the better parts of my nights this year.
This wasn’t just a backend development, I call it financial systems engineering. I had to think far beyond making it work, I had to design a fault tolerant system. Every transaction needed to be traceable. I had to implement idempotency checks to prevent duplicate payments, secure webhooks to ensure callback authenticity, retry queues for failed network callbacks, database transactions that preserved atomicity, and audit logs to reconstruct the entire financial flow for any dispute. This was about engineering trust not just development.