Technical writing
Writing drawn from the same domains as my case studies, generalised so that nothing employer-specific appears. Where a piece draws on professional work, the grounding is stated on the article itself.
Service boundaries in a payments platform are not an architectural preference, they are a correctness decision. How money, state and failure change the usual microservices advice.
A field guide to integrating banks, mobile-money operators and billers, written from the perspective that every provider will eventually behave in a way its documentation does not describe.
An API is a promise you have to keep after you have forgotten making it. What ten years of building integration surfaces teaches about versioning, errors, contracts and the clients you cannot upgrade.
Twelve pieces mapped to the engineering I have actually done: payments and integration, service architecture, delivery infrastructure, applied ML and leadership. Each planned piece lists its outline rather than a fabricated publication date.
Every topic maps to documented experience. Nothing here is a trend piece on a technology I have not shipped.
Articles describe principles and patterns. Professional work appears only in sanitised form, and is labelled as such.
The goal is writing an engineer would bookmark, not keyword pages. Search visibility is a by-product of that, not the brief.
Laravel is usually taught as a monolith framework. What it takes to run it as a fleet of services, boundaries, shared contracts, queues and the parts of the framework you stop using.
Why Spring Boot keeps showing up in payments infrastructure, and the framework-level decisions that matter when the domain is money rather than CRUD.
PropTech is listings plus tenancy plus operations plus a great deal of media. A look at where those concerns actually want to be separated, and where splitting them costs more than it saves.
A pipeline decides how often a team can safely change its mind. What belongs in one, what does not, and why the rollback path deserves more attention than the deploy path.
Containers are straightforward until they are production. Image discipline, process supervision, resource limits and the operational habits that separate a container that runs from one you can operate.
The practical companion to reliability theory, the questions to ask a new financial provider before writing a line of integration code, and the ones whose answers change your architecture.
Notes on the transition from owning code to owning outcomes: sprint planning, mentoring, technical decision-making, and the parts of leadership that are simply engineering at a different altitude.
What holds up as a React codebase grows past the point where any one person has read all of it, boundaries, data ownership, rendering strategy and the cost of the wrong default.
Putting a model behind a user-facing request is an availability problem before it is a modelling one. Serving, versioning, latency budgets and what the page does when the model is slow.
Contact
I’m open to senior and lead engineering roles internationally, backend, full-stack, architecture and platform work. The fastest route is email; LinkedIn works just as well.