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 conversationSee the work
Selected work
Personal projects, built end to end and still running. Every line under them was read out of the repository or the live site before it was written here.
Solo build, end to end
An invite-only photo and video library for one family, built to get cheaper the longer a file sits there. Go on Lambda in front of DynamoDB, with S3 as the only place a file actually lives - uploads are presigned and multipart, so nothing large ever passes through the API. Objects age down into Glacier tiers on a lifecycle rule, and a cold tile has to be restored before it can be opened. The restore is idempotent, because a waiting user taps it twice.
Personal site, WebGL
An earlier personal site and the one that is enjoyable to look at: a room modelled and lit in the browser with react-three-fiber rather than pre-rendered to video. It started as a follow-along of a published three.js portfolio build, and the interesting part was what came out afterwards - the template ships with invented testimonials, a client logo wall and headline statistics, and all three were removed rather than filled in. The skills grid is deliberately flat images: each 3D icon is its own WebGL context, and the page already sits near the browser limit.
Research tool
A backtester for one accumulation rule on a 3x leveraged ETF: buy on a schedule, buy harder once the trailing 252-day drawdown crosses 25 per cent, trim when a position is up 50 per cent. Every modelling choice that could quietly flatter the result is written down and configurable - which rule wins inside a single day, whether trim proceeds earn interest, what counts as money contributed. The committed run is the answer it actually produced: the strategy trails both buy-and-hold benchmarks. Publishing that is the reason to build one.
These are personal projects, which is why they can be shown at all. The work I am paid for belongs to the companies who paid for it, so none of it appears here. Alongside these there is a longer tail of public repositories - Go, Rust, Python, a lot of it plainly learning in the open - and I would rather you find it labelled honestly than dressed up as a product.
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
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.