That's the arc. Here's how it actually unfolded — each role, and what it taught me about building software people depend on.
Started with tutorials, moved to documentation, then just started building things. Some worked. Most didn't. That gap between 'I understand this' and 'I can actually ship this' — closing it took about two years of building things nobody asked for.
Hired as the only developer at a cleaning agency in Bedford. I built their booking platform from scratch — it scaled to 300 monthly active users and eliminated 40% of their manual scheduling overhead. First time I owned a product end to end: the architecture decisions, the 2am incidents, the performance bottlenecks nobody warned you about. Bedford taught me that there's a version of 'it works' that's actually just 'it hasn't broken yet.'
Built a GDPR-compliant platform for a European grant consultancy — analytics, lead capture, the full stack. Delivered it. Then the CTO referred me directly to a SaaS engineering team in Palma. That referral said more about the work than I could.
Engineering team for Multifactu — a fiscal-compliance invoicing platform for Spanish SMEs. TypeScript monorepo, NestJS, PostgreSQL, Docker, Playwright. I work on the signed XML generation that has to satisfy Spanish tax authority standards, and the OpenAPI contracts that keep the whole stack honest. This is software that processes legally binding documents for real businesses. The bar isn't 'does it work.' The bar is 'can you prove it.'
Alongside ADP Digitek, I joined the team building Bica Driver — a real-time ride-sharing PWA with native mobile via Capacitor. I own the real-time layer: namespaced Socket.io for driver, owner, and admin roles, the payment state machine, the offline-first connectivity, Firebase push notifications. The interesting problem here isn't the features — it's that everything has to work when the network doesn't.
I'm looking for a remote full-stack or backend role at a company that ships real software to real users — ideally somewhere the engineering culture has opinions about how things should be built, not just whether they ship. If that sounds like where you work, I'd like to talk.
Owning products end to end taught me that the interesting problems are rarely the features — they're what happens when the network drops, a payment retries, or two clients race for the same state. A few principles I keep coming back to:
Complex lifecycles modelled as state machines the server owns, so no two clients can ever disagree on where things stand.
Mutation flows that survive retries, timeouts, and dropped connections without double-charging or duplicating work.
Time-sensitive data frozen the moment it's created, so a later read never drifts from what the user actually saw.
Queues and background workers isolate slow or flaky third parties, so their bad day never becomes the user's.
High-frequency writes accumulated in memory and settled in batches, so traffic spikes don't turn into write storms.
Optimistic UI, offline-tolerant state, and real-time views that stay in sync across reconnects — type-safe and sharing contracts with the API.
And I treat everything I own as production from day one — real auth, rate limiting, CI gates on type errors and tests, infrastructure that's reproducible across environments, and documentation of the architecture so the next engineer isn't guessing how it fits together. People use software in ways you never intended — the double-tap, the dropped connection, the half-finished payment — so it isn't enough that the happy path works. I build for the edges, because that's where users actually live.
When I'm not writing code, I'm usually cycling around Lagos, reading sci-fi, or taking photos of things that catch my eye — mostly architecture and street scenes. The cycling especially. Long rides are where I do my best thinking.
Street scenes and architecture, mostly. I like noticing the light other people walk past.
Long rides around Lagos. It's where I do my best thinking — most of my hardest problems get solved away from the keyboard.
Sci-fi, philosophy, and technical deep dives. Constant input keeps the output sharp.