Work
Each one is the problem, the constraint, the wrong turn I took first, the decision, and what happened. The wrong turns are the part that is hard to fake.
No client architecture appears anywhere on this site. Every study is written at the level of the problem and the decision, which is also the level that transfers to a different company with a different stack.
What is in a case study here
Five things, in the same order every time. The situation and the constraint that made it hard. What I tried first and why it was wrong. The decision that actually worked. What that decision cost, because every real one costs something. And what happened afterwards, measured rather than asserted.
The wrong turn is not modesty. It is the part of an engineering story that cannot be reconstructed after the fact, so it is the part that tells you whether somebody did the work or read about it. On the financial correctness study the wrong turn took weeks: I made four subsystems agree with each other, which held until it did not, and the fix was to remove three of them from the conversation entirely.
Why some of these are small
The dealership sites and the fibre provider site are not distributed systems and are not presented as though they were. They are here because a client site that is still running and still being updated by its owner years later is a different kind of result from one that shipped and rotted, and because the constraint on those projects was one I could not engineer around: the owner had to be able to run it without me.
Scale is one axis. Whether the thing survives contact with the person who has to use it is another, and it is the one more employers are actually buying.
Sole engineer on a school platform used by 112 schools
I am the only engineer on Enaton, a school management platform used daily by 112 schools across Kenya. I designed it, I ship it, I operate it, and I am the one who gets called when it breaks.
When one number has four owners, three of them are wrong
A user could ask two parts of the same system the same question in one afternoon and get two different answers. Both were defensible. That is the worst kind of bug, because nobody can tell you which one to trust.
A scheduler holding ten million future jobs on flat memory
The cron entries had multiplied to the point where nobody could say what ran overnight, whether it had finished, or what would happen if the process died in the middle of it. That is the moment a scheduler stops being a convenience.
Screens for people with a queue standing in front of them
The office had a queue every morning. Every extra click on the screen the clerk used was not a usability detail, it was another person waiting in a corridor.
A dealership platform the owner could run without me
The brief was a website. The actual requirement, which nobody said out loud, was that the owner could add a car at nine at night from a phone without calling me.
The second dealership, and what I reused rather than rebuilt
Building the same shape of product twice is the cheapest education available. The second one tells you which of your decisions were real and which were habits you had not noticed.
An internet provider site where the first question is coverage
An internet provider site is not really a marketing site. It is a single question with some marketing attached, and the question is whether the service reaches the visitor's building.
Early work, kept on the site deliberately
Most portfolios quietly delete the early work. Mine keeps it, because how somebody got from a salon booking page to running a platform is more useful information than the platform on its own.
Where to start
- The main one
- Sole engineer, zero customers to 112 schools, six years. What being the only person who can fix it forces you to design differently.
- If you want to see the reasoning
- Four subsystems computing the same number, three of them wrong. The clearest example of a first fix that was correct and still failed.
- If you want to see the scale
- Ten million future jobs on flat memory, a hundred thousand executions an hour, nothing lost.
Common questions
- Why is there no architecture diagram of any of these?
- A diagram of a live system is a map of where to attack it, and most of these are still in production with real people and real money on them. The engineering is described at the level of the problem and the decision, which is the level that is portable anyway. The generic pattern drawings are in the engine design section.
- Can you talk about any of this in more detail in an interview?
- Yes, considerably more, including the parts that are not written down. What will not change is that I do not describe a current client's internals to a third party, which is the same rule that would protect your systems later.
- Are the numbers on these pages rounded?
- No, and the arithmetic behind each one is published rather than asserted. Where a figure is derived, for example contactable parents from learners, the multiplier is stated so you can check it rather than trust it.
For the reasoning behind how any of this gets built rather than what got built, read how I work .