My Story

There is a version of this story that starts with a clean origin — a moment of clarity, a single decision, a straight line from curiosity to competence. That version would be easier to read. It would also be a lie.

The real version starts in second year of a BSc in Information Technology at the University of Eldoret, with a laptop that struggled, a hostel room with unreliable power, and a growing suspicion that what they were teaching in class was not the whole picture.

Second year is when most IT students start to realise that knowing how to use computers and knowing how to build with them are two entirely different disciplines. The coursework covered the theory — networks, databases, operating systems, software engineering principles. But theory has a ceiling, and I kept hitting it.

So I started going around it.

I have a bad habit of building locally and never pushing. Most of what I built in those early years exists only on drives and in my head — half-finished things, experiments that worked for three days before I broke them trying to make them do something more. A login system here. A simple REST API there. Scripts that solved problems nobody asked me to solve.

That pattern — build, break, learn, rebuild — repeated itself so many times that it stopped feeling like failure and started feeling like methodology.

I joined the Google Developers Club because I wanted to be around people who were building things. I went to hackathons because I wanted to see what happened when you had forty-eight hours, a problem, and no choice but to ship something. I studied OWASP documentation not because it was on any syllabus but because I had become fascinated by a particular question: if I built this, how would someone break it?

That question turned out to be one of the most useful questions I ever asked myself.

There is a discipline in information security that treats attack and defence as the same knowledge approached from different angles. I am not a security engineer, and I have never claimed to be. But spending time understanding how systems fail — how authentication can be bypassed, how APIs can be abused, how a poorly configured network becomes an open door — changed the way I thought about building.

When you have spent time thinking about how something breaks, you build it differently. You think about what happens when the input is not what you expected. You think about what happens when the network drops mid-request. You think about what happens when someone sends the same request twice because the first one timed out and they are not sure it went through.

These are not theoretical concerns. These are the things that happen in production. These are the things that cause 2 a.m. incidents. And the engineers who handle those incidents well are almost always the ones who thought about them before they happened.

I did not know it at the time, but I was building a way of thinking that would define the kind of engineer I wanted to be.

I decided to build a rate limiter. Not because anyone asked me to. Not because it was a requirement for anything. Because I had been reading about API abuse and I wanted to understand, at the implementation level, how you actually stop it.

The first version used a fixed window counter. It worked. I was pleased with it for about a week, until I started thinking carefully about the reset boundary.

A fixed window counter tracks requests within a defined period. When the period ends, the counter resets. The problem is that the reset happens for everyone at the same moment. A client who has exhausted their limit at 11:59:58 waits two seconds, and at 12:00:01 they have a fresh window.

That is not a rate limiter. That is a rate limiter with a known exploit built into its design.

Throttlr became the project where I closed that gap. Sliding window. Every request stores a timestamp. When a new request arrives, you drop all timestamps older than the window and count what remains. The window is always measured from now. There is no reset boundary because there is no reset.

Building Throttlr taught me something I did not expect: the difference between a system that works and a system that is correct is sometimes a single design decision that nobody questions because the system appears to be functioning fine.

Authentication is one of those problems that looks solved until you look closely at how most implementations actually handle sessions.

The common pattern stores session data server-side. A session ID goes to the client. Every request has to hit the session store to verify who the user is. At small scale, this is invisible. At real scale, it becomes a bottleneck — and it means the server is stateful in a way that complicates horizontal scaling, failover, and any architecture where you want multiple instances handling requests.

Vaultkey was my attempt to do this properly. Stateless authentication. JWT-based. Nothing stored server-side after login. The token carries everything the server needs to verify the request. bcrypt for password hashing. Middleware that verifies the token on protected routes without touching a session store.

The interesting design problem was not the implementation — JWT libraries exist, bcrypt is well-documented. The interesting problem was the token lifecycle. Stateless means you cannot invalidate a token server-side without reintroducing state. So you have to think carefully about expiry, about refresh token strategy, about what happens when a user changes their password and you need their existing tokens to stop working.

Most of what I had built up to this point was request-response. A client asks, a server answers, the connection ends. HTTP is clean that way. The server does not have to remember anything between requests.

WebSocket broke that model entirely.

Echospace is a real-time messaging system with room isolation. The architecture is straightforward — a WebSocket server, a rooms map, clients assigned to rooms, messages broadcast to everyone in the same room except the sender. But the implementation surface is deceptive.

The hardest part is not the messaging. It is the disconnects.

A user closes the tab, loses signal, or their device dies. The server does not always receive a clean close event. If you do not handle this, you accumulate zombie connections — dead clients still in your rooms map, still receiving broadcast attempts, still consuming memory.

Echospace taught me that real-time systems are not just faster HTTP. They are a different responsibility model. You are not answering questions. You are maintaining relationships. And you are responsible for those relationships until they end — cleanly or otherwise.

Somewhere alongside all of this, I spent eighteen months across two organisations with exposure to fintech systems at real scale. Loan engines. KYC pipelines. Repayment processing. Collections.

I was not the architect of those systems. I want to be precise about that. But proximity to their failure modes made certain things clear in a way that no amount of reading could replicate.

The customer gets debited twice, one repayment gets recorded, the balance looks wrong, and the calls start coming in. The fix is idempotency: every transaction attempt gets a unique key, stored atomically with the payment record, so that retries return the cached result instead of running the transaction logic again. This is not an optimisation. In a financial system, it is a correctness requirement.

A rate limiter with a reset boundary is not a rate limiter. It is a rate limiter with a known exploit. Seeing that pattern in production — and understanding what it cost when someone found the boundary — made the lesson permanent.

These are the things you learn when the stakes are real. When the transaction that fails at 2 a.m. is not a test fixture but someone's actual money on the line.

I will not pretend this part does not exist, because it does — and because anyone reading this who is building things from a laptop in a city that is not a tech hub already knows what I am talking about.

There is a particular kind of doubt that comes from building in isolation. You finish something, and you look at it, and you think: is this actually good, or do I just not know enough to see what is wrong with it? You read about how engineers at large companies do things and the gap feels uncrossable. You abandon projects not because they are broken but because you have convinced yourself they are not worth finishing.

I have been in that place. I have left things half-built. I have rebuilt things that did not need rebuilding.

This doubt is not evidence of inadequacy. It is evidence of a gap between what you can do and what you can see — and that gap is exactly what experience closes.

The engineers who seem certain are not certain because they know everything. They are certain because they have been wrong enough times to know what right looks like.

I am still closing that gap. I am doing it deliberately, one system at a time.

Backend engineering attracts a certain kind of mind. Not the kind that wants to see the thing — the interface, the animation, the colour on the button. The kind that wants to understand the thing. What is actually happening when this request lands? What does the data look like at each stage? What happens when this fails?

I care about reliability. A system that works under normal conditions is not interesting. A system that degrades gracefully under abnormal conditions — that surfaces failures instead of burying them, that handles the retry correctly, that does not double-charge someone because the network was bad — that is interesting.

I care about correctness. Not as an abstract principle, but as a practical constraint. Code that is almost right is often worse than code that is obviously wrong, because almost right passes the tests and fails in production in ways that take hours to diagnose.

I care about the foundational layer. The part that has to hold regardless of what else is failing. That is where I want to work. That is what I am building towards.

I am a junior engineer. That is where I am in the work — not where I am in the thinking, and not something I need to dress up.

What I bring is years of building things because I could not stop myself from building things. A methodology shaped by breaking systems before defending them. Projects that exist because real problems needed real solutions, not because a course required them. An understanding of fintech systems that came from proximity to their consequences.

I am not the finished article. I am someone who has been serious about this since second year, who writes about what he builds, who thinks carefully about correctness, and who is looking for the environment where that compounds into something significant.

If you have read this far, you already know more about me than most people who will read my CV.

That feels like the right place to stop.