Billy Okeyo

Engineer · Builder · Consultant · Technical Writer

I build software that has to work after the demo.

I'm Billy Okeyo, a software engineer and product builder in Kenya. I design systems, products, and APIs, plus the occasional AI feature that earns the electricity. Backend, web, products that have to stay honest, and the consulting call where someone wants a miracle by Friday.

Illustrated portrait of Billy Okeyo, smiling in glasses with Hola on his shirt

What I do

Engineering, products, and saying no to decorative complexity

I work where systems meet people who will retry the request, then ask if we can add AI.

Software Engineering

Reliable backends, APIs, and web apps. The unglamorous kind that still works on Monday.

Django · Python · Laravel · PHP · Go · C# · .NET · Angular · Flutter · Next.js · TypeScript · PostgreSQL · Docker · Kubernetes

Product Development

Turning a vague idea into something you can click, charge for, or regret in production.

Product architecture · MVP design · Deployment · Iteration

Applied AI

I use AI when a product needs a structured interpretation of messy human input, and I can say what it is not allowed to claim. Sparkles on a landing page do not count.

Guidance workflows · Language boundaries · AI-assisted products · Human-in-the-loop

Technical Consulting

Helping teams pick an architecture they can operate, not one that only looks clever on a slide.

System design · Architecture reviews · Product strategy · Engineering decisions

Things I will defend in a room

Products with users. Systems that have to stay honest when nobody is watching the logs.

Tijafugo preview
Live

01Live· Offline-first poultry management

Tijafugo

Poultry management for African farms: flock health, production, and profit without assuming always-on connectivity. English, Swahili, and USSD.

Django · PostgreSQL · Flutter · REST APIs · USSD

Engineering philosophy

Beyond writing code that only works once

Good software is not the thing that passed on my laptop at 1am. It should stay understandable when someone else inherits it.

My job is not to make software work once. It is to make systems that stay correct when they are retried, observed, changed, and handed to the next person.

Reliability

Software should behave when networks fail, users retry, and traffic is concurrent. The happy path is the easy part.

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.

Clear architecture

Boundaries should make the next change obvious. Mystery is a fine genre. It is a terrible system property.

Good APIs

An API is a product. It should be explicit about side effects, retries, versions, and the many ways it can fail.

Observability

If you cannot see a failure, you cannot operate the system. Logs, traces, and metrics belong in the first version, not the postmortem.

Practical product thinking

Engineering exists to move a real problem forward. The right abstraction is the one that ships and can still evolve.

Experience

Roles I can speak to in public

Company names and dates come from my resume. Some work is still sitting in a drawer.

  1. Present

    Lead Software Engineer (Consulting) · LearningDifferently

    Lead software engineering for LearningDifferently on a consulting basis, including the education product around Dora.

  2. 2021 to Present

    Software Engineer · Innova Limited

    Engineering on enterprise financial systems for investment management, unit trusts, and bancassurance products.

  3. 2023

    DevOps Engineer (Part-time) · Uamuzi

    Part-time DevOps for production systems: pipelines, containers, and faster releases.

Full experience

Teaching & mentorship

Knowledge is less useful if it stays in one head

Lecturing, mentorship, and writing. Same practice as shipping, just with more questions.

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.

Contact

Have something real to build?

If the problem is interesting and the constraints are honest, I am easier to reach than a support form.