Writing.
On payments architecture, fraud and security, and leading the teams that ship them. Essays live here; articles and shorter posts link to where they were first published.
Essays and talks
- Attacks will land. Design so they stay small.The attacks that reach payment products in emerging markets, and the boundary that keeps each one contained: the edge, the device, the account, the partner, the transaction, the ledger and the tenant.Essay, 8 min
- Secure coding for FX: shipping software that doesn't leak money or PIIThe secure-coding training I gave Cede's engineers and product team: the threat model for an FX product, what Nigeria's NDPA and the CBN cybersecurity framework mean in code, and the OWASP Top 10:2025 mapped to a Flutter, Node, React and AWS stack.Talk, 11 min
- Platform engineering: building internal developer platforms that pay for themselvesMy talk at Poolot for product managers, engineers and people operations: what an internal developer platform is, the ROI case leadership will accept, the five planes of a platform that works, how to staff and phase it, and the metrics that prove it.Talk, 6 min
Published elsewhere
- Latency sovereignty in African payment infrastructureWhy African payment engineers should treat latency as a resource the application controls, rather than something telecoms, ISPs or cloud providers will reliably supply, and four practices that follow.Digital Times Nigeria ↗
- Why multi-tenant mobile fintech apps cannot rely on themingWhite-label fintech is not a theming problem. A case for tenant-isolated data layers in Flutter, so one regulated brand's data, tokens and telemetry can never reach another brand's users.IT Pulse ↗
From LinkedIn
- Building fintech apps is less about features and more about trustFintech as a distributed state problem: money, identity and compliance must stay consistent across unreliable networks and async workflows, so KYC becomes a state machine and every transaction is idempotent and auditable.LinkedIn ↗
- Over-engineering is not building too muchIt's adding complexity before the problem asks for it: scale you don't need yet, flexibility that hides how a request flows, and frameworks where a module would do.LinkedIn ↗
- Improving stability and reducing cost on AWS RDSFaster mobile apps often start in the database: practical ways to cut API latency and cost through RDS configuration, caching and scaling.LinkedIn ↗