About

I start every project by asking: "How can we solve this without writing code?" Code is a liability. It requires maintenance, security patches, cognitive load. The most expensive feature is the one you built that nobody asked for.

• Start with the problem, not the stack. If a shared Google Sheet solves the coordination problem, that's the right architecture. I once convinced a team to delete 12 microservices and replace them with a cron job and an email alias.
• Constraints are design inputs. Budget, timeline, team size — these aren't blockers. They're the parameters that force the elegant solution. Given infinite resources, most engineers build infinite complexity.
• Simple systems fail in predictable ways. A paper ledger fails when someone spills coffee on it. A distributed system fails in ways that take three engineers and a postmortem to understand.

Early in my career, I spent six months architecting what I thought was the perfect microservices backend — event sourcing, CQRS, a message broker, the whole catalogue. The product hadn't found product-market fit. When the business pivoted, every single service became instant technical debt.

That was the moment I realized: shipping fast without clarity isn't agility. It's just generating waste faster. Now I optimize for decisions, not delivery.

I don't have a manifesto. I have two questions I keep coming back to:

• Why do some things scale and others shouldn't? Every week I see another startup chasing hypergrowth, building for a future user count that never arrives. Meanwhile, the informal economy in Nairobi moves billions of shillings through WhatsApp groups, M-Pesa transactions, and paper ledgers — infrastructure that is fragile by design and resilient because of it.
• What survives when the internet goes down? It's a stress test for any product decision. If your app requires a constant cloud connection to serve its core value, you've shifted the liability to your user. I'm interested in software that respects where networks actually break.

These are the territories I spend my attention on — not as hobbies, but as lenses for understanding how systems (technical, social, economic) actually work:

This is a garden of finished thoughts, not a stream of consciousness. I publish here when I have something substantive to say about the intersection of technology, business, and human behavior.

You won't find hot takes on the latest framework. You will find essays on the enduring principles of building useful things — and the courage to walk away from the ones that aren't.