There is a particular kind of frustration that comes from understanding a problem completely but lacking the tools to solve it yourself. I have felt it many times — sitting across from a developer, explaining exactly what a financial dashboard needed to do, watching them nod, waiting weeks for a version that was almost right but not quite. The knowledge was mine. The execution was not.

I have spent over six years working at the intersection of finance and technology. First at Heri Water, where I built the finance department from nothing and helped grow the business to over 140 franchises. Then at Kokotech, where I co-developed two fintech platforms — Kokosend and Kokopay — and managed the financial and operational backbone that kept them running day to day. I understand how these systems work. I understand what they need. What I did not understand, for a long time, was how to build them.

"The best digital tools are built by people who understand both the human problem and the technical solution. I had spent years mastering one side. It was time to learn the other."

The Moment It Became Obvious

It was not a single moment. It was an accumulation. Every time a reconciliation process that should have taken ten minutes took three hours because the tool was not built for our specific data structure. Every time I described a report to a developer and received something technically correct but practically useless. Every time I watched a small inefficiency compound itself across hundreds of transactions, knowing exactly how to fix it and having no way to do so without depending on someone else's time and interpretation.

The fintech world moves fast. Crypto markets do not wait for sprint cycles. When something breaks at 11pm on a Friday — and in fintech, things do break at 11pm on a Friday — the person who can diagnose it, patch it, or at minimum understand what is happening at a code level is worth more than any process document. I wanted to be that person.

What Finance Taught Me About Code

Here is something I did not expect: my finance background is not a disadvantage in learning to code. It is an asset. Finance is fundamentally about systems — inputs, outputs, rules, exceptions, edge cases, and reconciliation. Every accounting entry has a debit and a credit. Every process has a beginning, a middle, and an end. Every report tells a story if you know how to read it.

That is also, it turns out, how software works. Functions receive inputs and return outputs. Logic flows through conditions. Data needs to be validated, transformed, and reconciled. The vocabulary is different. The underlying thinking is not.

I am currently working through FreeCodeCamp's curriculum — Python first, alongside Responsive Web Design. Python because it is the language closest to the kind of work I already do: data, automation, financial logic. Web design because I want to see what I am building, to make things real and visible rather than abstract.

Building While Learning

One of the best decisions I made early in this journey was to start building before I felt ready. This very website — which you are reading right now — was built before I had completed a single certification. Not by writing every line from scratch, but by working collaboratively with AI tools, reading the code, tweaking it, breaking it, and learning from every mistake.

I uploaded my first HTML file to GitHub. I connected a custom domain. I configured DNS records and debugged HTTPS certificate errors and renamed files in repositories to fix broken deployments. None of that was in any tutorial. All of it was real. And all of it taught me more in an afternoon than a week of reading documentation would have.

The welfare association I lead also taught me something important about why this matters beyond personal ambition. Community groups across Kenya — savings groups, welfare associations, investment clubs — are running on WhatsApp messages and Excel sheets. The financial intelligence is there. The operational discipline is there. What is missing is the technology to formalise it, scale it, and make it resilient. I intend to build that. Not eventually. Soon.

What I Am Moving Toward

My ambition is not to become a developer in the narrow sense — someone who writes code for its own sake. It is to become a builder in the full sense: someone who understands a problem deeply, can design a solution thoughtfully, and has the technical capability to bring it to life without always depending on an intermediary.

Finance gave me the problem. Fintech showed me the scale. Code is the last tool I need.

The gap is closing.

Every working day at Kokotech, transactions flow across two platforms — Kokosend for fiat exchange and Kokopay for crypto. Money moves. Records are created. And every morning, someone has to reconcile those records: confirming that what the platform says happened matches what the payment providers say happened, to the last shilling.

For a long time, that someone was me. Armed with Excel, a series of VLOOKUP formulas I had refined over months, and a methodical patience that I suspect comes from years of accounting work, I would work through the morning reconciliation manually. It was accurate. It was thorough. And it took far too long.

"The process was not broken. It was just slow. And in fintech, slow is a kind of broken."

The Problem with Manual Reconciliation

The challenge with financial reconciliation is not that it is intellectually difficult. Once you understand the logic — match transaction IDs, flag discrepancies, investigate exceptions, confirm totals — it becomes almost mechanical. The problem is that mechanical work does not scale. As transaction volumes grew, the reconciliation window grew with them. What took forty minutes became ninety. What was a morning task began creeping into the afternoon.

There was also the question of human error. Not carelessness — I am a CPA finalist with six years of financial controls experience. But sustained, repetitive attention on large datasets is where even careful people make mistakes. A missed row. A mismatched date format. A figure that looks right but sits in the wrong column. Reconciliation errors in fintech are not abstract — they affect real money, real customers, and real trust.

What I Built — and How

I did not sit down one day and decide to build a reconciliation tool. It happened more gradually than that. I had been exploring AI tools seriously for several months, and I noticed that the same reasoning I applied to reconciliation — compare this to that, flag this pattern, surface these exceptions — could potentially be expressed as a set of instructions to an AI system.

Working with Claude, I built what we now call a reconciliation skill: a structured set of instructions that takes our admin exports from Kokosend and Kokopay and compares them against statements from our payment partners — SasaPay, Fingo, Nomba, Moniepoint, and Squad. The skill handles multiple currencies: KES, NGN, and ZAR. It runs deposit reconciliation and payout reconciliation. It applies a Monday rule that automatically covers the Friday-Saturday-Sunday period. It flags discrepancies, surfaces missing transactions, and produces a clean summary.

What took me ninety minutes now takes minutes. What required sustained manual attention now runs systematically. And because the logic is explicit and documented, anyone on the team can run it — not just the person who built it.

What This Taught Me About Building

The most surprising thing about building this tool was how much the process felt like accounting. In accounting, you define the rules first: what constitutes a match, what constitutes an exception, what tolerance is acceptable. Then you apply those rules consistently across every transaction. There is no room for intuition or approximation — the numbers either reconcile or they do not.

Building the reconciliation skill required exactly the same discipline. I had to articulate rules I had previously held intuitively. I had to think about edge cases — what happens when a transaction appears in one system but not the other? What happens when amounts match but dates differ? What happens on public holidays? Expressing those rules precisely, in a form that a system could follow, was one of the most clarifying exercises I have ever done as a finance professional.

It also showed me something important about the relationship between domain expertise and technical capability. The reconciliation skill works not because the technology is impressive — it is, but that is not the point — but because the financial logic behind it is sound. A developer who did not understand fintech reconciliation could not have built this. The knowledge had to come first.

Where This Is Going

The reconciliation skill is one tool solving one problem. But the pattern it represents — taking deep domain knowledge and expressing it as a systematic, automatable process — is one I intend to apply much more broadly.

I lead a welfare association where contributions, savings, loans, and welfare payments are still tracked manually. I know exactly what the financial logic of that system looks like. I know every edge case, every exception, every rule that governs how money moves in that community. What I am building now — through my FreeCodeCamp studies and hands-on projects like this one — is the technical capability to turn that knowledge into a platform.

The reconciliation tool was proof of concept. Not just for the technology, but for a way of working: understand the problem completely, express the logic precisely, build deliberately.

That approach will not change as the tools get more complex. It will only become more valuable.