Software engineering
I build the software a business actually runs on. Multi-tenant platforms, payment and payout flows, agent tooling, and the infrastructure holding them up - the parts where being subtly wrong shows up as a support ticket, a bad invoice, or money in the wrong account.
Rodolfo RaquionStart a conversation
What I build
Products that serve many customers off one codebase without leaking between them. Tenancy drawn at the data layer rather than patched in at the handler, self-serve onboarding, roles and permissions that survive the second and third customer asking for something bespoke.
Recent shape of work: a creator platform with per-tenant isolation and self-serve setup.
Checkout, subscriptions, payouts, refunds, reconciliation. Money paths get idempotency keys, an append-only record of what happened, and webhook handling that assumes duplicates and out-of-order delivery, because both happen. The ledger is the source of truth, not the UI.
Recent shape of work: payment and payout flows for a platform paying out to third parties.
Automation that removes a real, named, repetitive job rather than demoing well. Tool-calling agents with tight boundaries, human review where a mistake is expensive, and evaluation you can run before a change ships instead of finding out in production.
Recent shape of work: agent tooling that replaced manual back-office processing.
CI that actually gates, environments that match, migrations that run without a maintenance window, and logs and alerts good enough to diagnose an incident at 3am. Handing over a system nobody else can operate is not finishing.
Client names and products are deliberately absent. Most of this work belongs to the companies who paid for it, and confidentiality is part of the service.
How I work
The money path, the tenancy boundary, the permission check. I find those first and make them correct and boringly obvious, then build outward. Most of a system tolerates a little mess; those parts do not.
One narrow path working end to end beats four layers that have never met. It also means you see real progress weekly and can change your mind while changing it is still cheap.
A test suite is documentation that fails when it lies. I test what the system promises a user, not the shape of the code underneath, so refactoring stays possible and the tests survive.
Readable logs, alerts that mean something, a written path back from failure, and a codebase the next engineer can navigate. You should be able to run this without me.
Engagements
Ongoing delivery as the engineer on a product, or alongside your team. Best when there is a roadmap and not enough hands.
A fixed-scope look at an existing system - architecture, reliability, security posture, the money path - ending in a written assessment and a prioritised plan.
Regular time with a founder or team lead on architecture and technical decisions, without hiring for a full-time seat you do not need yet.
Get in touch
A short description of the problem is enough to start. If it is not work I should take, I will say so and point you somewhere better.