About Me

👔 Business: Deel is the all-in-one platform for global work: companies use it to hire, pay, and manage teams in 150+ countries without setting up local entities. Payroll and compliance are the front door, my teams live behind it, on Deel's fintech side. Once a contractor earns money on Deel, we own what happens next: withdrawing it through local payout rails, spending it directly with the Deel Card, accessing earnings early through Deel Advance, or unlocking premium perks with contractor subscriptions. In practice, we're building financial services for the world's independent workforce, embedded right where they already get paid, and for many of our users in emerging markets, that's their primary financial relationship.

⏱️ Challenge: Everything we ship moves real money for real people, so the correctness bar is unforgiving: a bug isn't a broken button, it's someone's salary. That shapes every technical decision, operations must be idempotent and atomic, integrations reconciled, and rollouts staged behind feature flags with dry-run and canary modes before they touch a single user. On top of that, we operate a multi-provider card platform where each issuer and banking partner brings its own APIs, webhooks, and quirks, and we face adversaries too: fraud patterns against our products like Deel Advance evolve constantly, so eligibility and risk controls are never "done". As Tech Lead of two teams, my personal challenge is balance and driving the roadmap while owning production, being the first responder on escalations without becoming the bottleneck, and growing the team so speed never turns into recklessness.

⚙️ Tech: Our stack is TypeScript and NestJS on PostgreSQL, event-driven under the hood, and we're mid-flight on migrating a large monolith into a modular monorepo of domain packages, which means we get to redesign core money flows with today's standards rather than patch yesterday's. The coolest piece in my teams is the provider-agnostic card platform: a canonical domain layer that translates each card issuer's webhooks and APIs into one internal model, so adding a new provider is an adapter, not a rewrite. Around it we build the machinery serious fintech needs, idempotent-by-design operations, reconciliation crons, audit trails, and observability on every silent failure path. And we're aggressive adopters of AI in engineering: agentic tooling for incident triage, log analysis, and eligibility experiments is part of our daily workflow, and it has measurably cut our support load.

🤼 Team: I'm Tech Lead of two squads that share one mission from different angles: Contractor Experience owns the contractor-facing money products: Deel Advance, withdrawals and payouts, the Deel Card experience, and subscriptions, while Card Service & Integrations owns the card-issuing platform and its provider integrations. Both are cross-functional (backend, frontend, mobile, QA, product) and fully remote, spread from Barcelona and Berlin to Bucharest and Melbourne, so we run async-first: mornings are protected focus time, meetings compress into a short daily overlap window, and the cadence is lightweight, a short daily standup per squad, weekly grooming, sprint planning, and a monthly retro. We work closely with Credit Risk, Finance, and our card providers directly. As Tech Lead I stay deliberately hands-on: I code and review daily, and lead through architecture, planning, 1:1s, and mentoring rather than from a distance.

⚡ Impact: The impact is very tangible: our rails move contractors' earnings in 150+ countries, with millions of dollars flowing through the Deel Card every month, and for independent workers in markets with limited banking access, we're often how they actually receive and use their income. The leverage of the role shows in single changes: one eligibility check we shipped in two days is projected to prevent seven figures of annual fraud loss, one query fix took a critical admin view from 38 seconds to about one second, and hardening a single admin surface closed a whole class of abuse vectors on money-moving endpoints. As Tech Lead I multiply beyond my own commits, turning one-off escalations into durable self-serve capabilities, planning multi-quarter migration programs the team executes in parallel, onboarding and mentoring engineers, and building AI tooling that other teams across Deel now reuse.

👔 Business: Thunes is a B2B company that powers payments for the world’s fastest-growing businesses; from Southeast Asia's super app Grab and Gig Economy giants, to Fintech leaders such as PayPal and Remitly. With a single, simple connection, your business and customers can send payments to and get paid in every corner of the world. Instantly. We support 79+ currencies, enable payments to 130 countries, and help you accept 300+ payment methods.

⏱️ Challenge: The global accounts team provide the global accounts solution allowing our partners to collect money abroad using a regular bank account. Our solution provides all required security checks as sanction list screening (SLS), transaction monitoring, safeguarding, etc.

⚙️ Tech: We developed web services using Go and following hexagonal architecture and event-driven architecture. The second allowed us to prevent data inconsistencies while dealing with complex money and data flows. We also owned our internal UI tool which used VueJS.

🤼 Team: The team was formed by one tech lead, one software engineer and myself as senior software engineer.

💵 Impact: Our team impact was mainly in money and data flows. Providing a solution that was compliant with any regulation in the country where we integrated.

👔 Business: Wallbox makes electric vehicle (EV) smart chargers that can be remotely controlled from the MyWallbox site and Wallbox mobile app. Also, the chargers can take energy from the EV using them as a power source for the building.

⏱️ Challenge: Wallbox is growing super fast which makes us go the extra mile every day so we are ready to manage the active users increase. Also, the team is growing fast too so this challenges how everything is organized.

⚙️ Tech: We created and maintained services mostly based on Go and PHP. We also had some old NodeJS services just to maintain where we didn't add new features. We were creating more new isolated services that came from a big legacy monolith. We went for an event-driven communication fully asynchronous that gave us reliability enough to deal with problems we might have faced in one of the services. We applied Hexagonal Architecture, DDD and Clean Code because we felt that was the way to have a good codebase that was easy to extend and to understand.

🤼 Team: I was on the platform team. A one that was growing fast having already 12 members which 10 of them were backends. Our main purpose was maintaining the legacy monolith doing big refactors so got easy to add new features, splitting part of it on new services, helping the TechOps team deal with our infrastructure, having proper monitoring and alerting in place so we caught any problem before our users.

⚡ Impact: From the backend team we had a huge impact on the company since any business logic of the chargers was inside our services ecosystem: remote charger actions, authorization, authentication, group of users management, charging metrics, user notifications, payments... I also had an impact on our team members mentoring some of them for the new architecture we were implementing.

I was maintaining and developing new features for all payment (micro)services of Letgo which includes Bump Ups, Subscriptions (We created this (micro)service when I was on Verticals squad), and payments (Apple, Google Play Store, and Stripe).

All the services were developed using PHP 7 and Symfony, most of them used No-SQL databases over DynamoDB, a few though had some RDS database with MariaDB.
We also had several Golang lambdas to handle some scheduled jobs and to react to events. Also, for the sake of speeding up some features, we implemented some features on other team projects made with Scala.

Apart from the main projects, I created and maintained a Golang CLI tool to help us with some fixes and maintenance that needed to be applied to a big volume of data.
Also, I was in charge of migrating two of our main services to Kubernetes: payments and bumps.

The devs in the squad were also handling part of our Terraform setup, so we could create and modify SQS queues, SNS subscriptions and filters... in a faster way.

The squad used scrum and was formed by backends, sysadmins, iOS developers, Android developers, QAs, TPM, POs, and BIs.

I joined one of the squads in charge of preparing the app to be able to sell new kind of products and to handle the new subscriptions system that works with Google and Apple purchases.

The squad used scrum and was formed by 4 backends, 1 sysadmin, 2 iOS developers, 2 Android developers, 1 QA, 1 TPM, and 1 PO.

We used PHP 7, MySQL for the write model, Solr for the projections of the read model, Symfony 3, Doctrine... we designed all the services following DDD and CQRS.
To communicate between (micro)services of our squad and the ones of other squads we used domain events, through AWS using SQS and SNS, so we got reactive systems with very low number of direct HTTP calls.
We tested our API's and consumers with Behat and our code with PHPUnit.

We also used Golang to develop small lambdas and processes to handle and manipulate data.

I was Backend Developer in one of the company teams in charge of two projects.

The first project was based on PHP and Node JS, and we did unit tests over PHPSpec and PHPUnit.
It was a background-checking site, operative only in the USA.
The interesting part of the project was getting all the needed information from several providers via API.
Also since it was kind of legacy project that was done fast and without tests we were increasing unit tests coverage, and doing TDD with the new features.
Another problem was MySQL performance, a bad design was making that service consume 80% of CPU. We solved that by adding proper indexes and updating some wrong-configured fields.
Also, I created NodeJS Lambdas over AWS, which were importing data from third-party APIs to a No-SQL database over DynamoDB.
This project had three services:

• A PHP service that managed all the frontend and the API in charge of creating any content, access control... We migrated that project from PHP 5 to PHP 7, and from Silex 1 to Silex 2... we had fun doing that.
• A NodeJS 4.7 service that did all the searches.
• A new NodeJS 8 service where we were migrating all the searches. TDD with Mocha, Chai and Sinon.

The second one was a new project made from scratch following TDD and DDD. It was fully developed with PHP, using Symfony 3. The unit tests were made over PHPUnit.
It was a website that provided security for personal identification. It was also a product only available in the USA.
In that case, we had 2 services:

• One static content service with Nginx, where we had all the front end. That frontend was fully HTML and JS, so we didn't have PHP mixed there, our API was fully separated.
• One PHP 7 service with an API secured with OAuth using JWT tokens. The API was RESTful level 2 (see Richardson Maturity Model) starting adding hypermedia, so the idea was to jump to level 3.

The team was following Kanban, and we also used Event Storming for big features or new projects, like we did with the second one.

I was a Backend Developer in a scrum team of 5 devs. We were creating new modules of API Rest based on PHP 7.

The API centralize all data management of the business and sales too.

We used Symfony 2 but only as an application layer. All the business logic was isolated and structured following DDD and Hexagonal Architecture.
Otherwise, we were following CQRS, so we had a read model and write model isolated. And we were using Event Sourcing on majority part of the project.

Security was over OAuth 2.0 using JWT.

After joining them, it turned out that the company wasn't in good financial health and they closed 3 months later.

Projects:

• Motocard: New ERP to handle website products. Website connection with ERP SqlServer database.
• Inforsa: Develop new API to read data from their data providers from API calls, FTP files... Develop new ERP to handle client and providers liquidations.
• Pans&Company: Website and background processes maintenance.
• Ribs: Website and background processes maintenance.

Migrate old TT2 to new NodoGestion.
Prepare the ERP for new sectors like energy and fishing distributors and factories.

Maintain GestorTT which was a telephony ERP for Telefonica, Vodafone and Orange stores.
I was specifically working on logistics, commissions and liquidations sections.
Migrate old GestorTT to new TT2 based on PHP.

Tailor-made websites from scratch and Drupal adaptations. Also, Drupal plugins creation.
I did corporate websites, social networks, back offices, online shops...

Tailor-made websites from scratch and Drupal adaptations. Also, Drupal plugins creation.
I did corporate websites, social networks, back offices, online shops...
Also, I was doing server administration for web, DNS and mail services over Debian servers.