Reliability
Software should behave when networks fail, users retry, and traffic is concurrent. The happy path is the easy part.
About
I care about what happens after the happy path.
I'm Billy Okeyo, a software engineer and product builder in Kenya. I have spent more than five years shipping systems that have to keep working when traffic is concurrent, data is inconsistent, and someone will retry the request. The demo is the easy part.
The work
Software engineering, for me, is not a stack. It is the practice of turning an unclear business problem into something a computer can do reliably, and that another engineer can still change later without swearing at me.
I build products as well as systems. Tijafugo is farm operations that cannot assume Wi-Fi. Home of Electronics is a live shop where customers buy online and collect in Nairobi. Dora is the other side of that instinct: education guidance that refuses to pretend it is medicine.
A lot of my day-to-day thinking is backend and systems work: APIs that survive retries, databases that stay consistent, and products that fail loudly instead of guessing. I also use AI where it earns its place: guidance, screening, and analysis. Not as decoration.
I write about the same things I build. The Beyond CRUD series is about reliability after the tutorial ends. Beyond the UI is about what the browser is actually doing. Frameworks are useful. They are not the whole story, no matter how confident the docs sound.
Mentoring, lecturing, and writing are not a side quest. They are how engineering knowledge stops living in one person's head. I am still learning, usually by following a production failure further than is comfortable.
How I think about software
Abstractions are tools. They become a problem when they replace understanding. I want to know what the database actually isolates, what the queue actually guarantees, and what the browser actually paints.
Maintainability
Code is read far more than it is written. If the next engineer needs a séance to find a rule, the design is unfinished.
Performance
Fast systems are usually simpler systems. Measure first, then delete the work that never needed to happen.
Security
Trust boundaries, least privilege, and careful handling of money, identity, and documents are design constraints, not a phase at the end.
That is why the writing exists. Idempotency, isolation levels, the outbox pattern, hydration: they are not trivia. They are the difference between a demo and a system you can operate.
Teaching and sharing
If a system only lives in my notes, it is unfinished. Lecturing, mentorship, and articles are how the work travels.
Lecturing
Explaining how software actually behaves, not how a framework looks in a tutorial, so people can reason about production.
Mentorship
GADS Mobile Web Mentor, 2021 to 2022. Helping engineers move from “it works on my machine” to systems that survive retries and growth.
Knowledge sharing
Google Developer Student Clubs Lead, 2020 to 2021. Community conversations that make engineering knowledge usable by more than one person.
Technical writing
Long-form pieces on reliability, databases, distributed systems, and how interfaces are actually built.
School and paper
The degree and the certificates. The interesting work still happened after class.
Education
BSc. Information Technology
Mount Kenya University · 2018 to 2021
Certifications
Google Cloud Certification
2022
Udacity Cloud DevOps Nanodegree
2022
Responsive Web Design
2019
Tools I reach for
The list is not the point. It is here so you know the materials I have used in production. The interesting work is how they are combined, and which ones I refuse to use as a personality.
Python · PHP · TypeScript · C# · Dart · Go · Django · Laravel · Angular · Flutter · .NET · Next.js · PostgreSQL · Docker · Kubernetes · AWS