Nairobi, EAT. Open to senior backend and full stack roles
I am the only engineer on a school platform that 112 schools run on every day
I design the engines and I design the screens people use them through. Nobody reviews my work before it reaches someone counting real money at a counter, so it has to be right the first time.
- schools in production
- 112
- learners on the system
- 50,400
- parents reachable
- 86,000
- engineer, that is the point
- 1
Three things, and everything here is evidence for one of them
01
I own systems from the engine to the screen
Not a backend engineer who tolerates the frontend, and not a frontend engineer who calls an API. The same person designs the scheduling engine and the screen a clerk uses with a queue of people waiting behind them.
02
I solve problems I have not seen before
If your stack is Vue, or Go, or something I have never touched, my framework list is not what you are buying. You are buying the loop: verify before acting, write the plan down, prove it, measure it, hand it over. It is the same loop in any language.
03
What I build keeps being used
Zero customers to over a hundred, and they stay. Software people keep using is a harder result than software that ships, and it is the one an employer is actually buying.
One problem
Three commits all claimed to fix the same bug. All three were correct. None of them worked
A site was ranking as though it were a single page. The obvious cause was missing per page canonical tags, so three separate fixes had added them. The tags were there. Nothing changed.
I stopped adding fixes and read the output instead of the source. Every page was serving two canonicals: one inherited from a shared layout, one correct. The framework merged both, and the inherited one won on document order everywhere. Three engineers had each verified their own change and each been right about it.
The fix was deleting one line. Finding it took distrusting the input and reading what the server actually sent, which is the only part of this story worth hiring for.
What this shows
Debugging under a wrong shared assumption. The previous attempts were not careless, they were reasoning from the source when the truth was in the output. That is the failure mode I look for first now.
Selected work
Each one is the problem, the constraint, the wrong turn I took first, the decision, and what happened. No client architecture, ever. The transferable part is the only part worth reading anyway.
A school platform at national scale
Sole engineer. Zero customers to 112 schools. What it takes to be the only person who can fix it, and what that forces you to design differently.
When one number has four owners
Four subsystems each computed the same financial figure and three of them disagreed. Making them agree failed. Removing their right to an opinion worked.
A scheduler that holds 10 million future jobs
Most schedulers put every pending job in Redis and fall over. Three tier time routing keeps memory flat while the table grows, at 100k executions an hour.
Screens for people under pressure
Dense operational interfaces used all day by staff with a queue in front of them. Where clarity beats beauty, and where it does not.
Writing
33 posts published, and the ones that landed hardest were the ones that admitted something. Everything here comes from work actually shipped.
Three correct fixes that all failed
A site ranked as one page. Three commits added the right tag and nothing changed, because the truth was in the output, not the source.
Why adding more workers made it slower
The work was contention bound, so concurrency bought queueing rather than throughput. Batching fixed what scaling could not.
At least once is the only honest guarantee
Nobody can sell you exactly once across a network. Make running twice harmless and you stop needing it.
If you are hiring someone to own a system, we should talk
Senior backend and full stack roles, remote, permanent. Nairobi time overlaps a full European working day and most of a US morning.