Product engineer. I design and ship systems end to end, and what I build has no sector: a company's operations, an election, a cultural product, a learning platform. What interests me sits where a product decision and a technical decision turn out to be the same decision.
Over the past year: a multi-tenant SaaS platform in production for many clients, a civic platform, fourteen reference implementations for people learning to ship, and technical direction of a cultural product.
A skill platform built solo as a polyglot architecture, with a public governance layer around it. Open beta January 2027.
Lead architect on a multi-tenant ERP, CRM and HR platform in production for many clients.
A civic technology platform deployed during the 2026 Benin presidential campaign, designed and shipped end to end.
Technical direction of a cultural and tourism platform: one digital identity replacing the physical ticket for events, restaurants and tourism. Private beta, public launch in Q4 2026.
Six steps, from the first framing through to running it. They adapt to your product, whatever its domain and its size.
I identify who has the problem, what it costs them today, and the number that will say it is solved. I also note what stays out of scope. That written framing then acts as the arbiter: every request arriving mid-project is measured against it instead of reopening a debate.
I list usage volume and shape, expected availability, the nature of the data and the rules that apply to it, systems already in place, team size, budget and deadline. I then separate what is negotiable from what is not, and mark each remaining choice as reversible or not. Firm constraints rule out most architectures immediately; the marking sets how much time each remaining decision is given.
I design two or three viable solutions and compare them against the criteria set in the first step: cost, timeline, risk, effect on what already exists. I then write up the decision taken, with the options set aside and the reason for each. The document fits on one page and lives in the repository, so the team can settle neighbouring cases without me and find the reasoning again when the question comes back.
I define hierarchy, typography, rhythm and density alongside the data model, and I start from the states: empty, loading, error, insufficient rights, partial data. Those states demand fields and rules that a nominal screen never surfaces, so handling them first avoids reworking the model afterwards.
I find the riskiest assumption, the one whose failure would force a rethink, and build a thin slice that crosses it end to end, all the way to production. It ships before the easy features. If the assumption fails, it fails while there is still budget and time to change course.
I instrument from the first release and read the figures against the objective set in the first step, at a defined interval. I ship logs, alerts and recovery procedures with it, and train someone else to use them. That allows fixes based on measurements rather than impressions, and a handover that does not degrade the service.
39 pushes and 23 pull requests merged across 5 repositories since September 1.
I design and build production systems, from the architecture through to running them.
What draws me is design and solving complex problems: the point where a system has too many pieces to hold in one head, and someone has to find the division that makes it readable again.
So what I do rarely fits one box. Within the same year: a multi-tenant ERP running the operations of many companies, a civic platform delivered inside a window that would not move, a mobile application built to work without a network, and a learning platform I carry on my own.
I work on both sides at once. The same day can go from an event bus to a typographic scale, and I do not consider those two jobs. A visual hierarchy and a data model describe the same product in two different places. When they are decided separately, it shows.
I am looking for a position, and I stay open to collaborations and to contract work. What I turn down: a product nobody will be able to say worked or not, work with no access to the people using it, and a scope that widens while the date stays where it was.
Outside of it I write, I read a great deal, I play the piano and I train. I build worlds and I play chess, which accounts for two of the entries in this archive.
Read the full career
Designing a product, taking over a system that grew too fast, or carrying the technical side of a team that has none.
Write with the problem rather than with the expected solution: what does not work today, for whom, and by when. One page is enough, and a thirty minute call is usually enough to tell whether it makes sense.
I reply within two working days, and I say so when it is not for me.
Every way to reach me