Ezequiel
Calvo

Around 2022, we had about 20 people working across 4 different product verticals, all dependent on a single monolith that handled crypto, fiat, and authentication logic. The monolith had become a clear bottleneck—code was tightly coupled, teams were stepping on each other's toes, and every change required full regression testing across all products. We were planning to double the team size, and I knew this architecture wouldn't scale.

I proposed creating a new vertical called "Core"—a separate team and infrastructure that would centralize developments impacting multiple products. This wasn't just about splitting the monolith; it was about creating an internal product with its own backlog and managing requirements from other teams.

I evaluated several options, including improving the existing monolith and better modularization, but the codebase was too large and had too many responsibilities—refactoring it seemed impractical. We designed Core as a microservices architecture with an explicit orchestrator. Each microservice managed its own database independently, and the orchestrator received external requests and routed them to the appropriate services.

From day one, we built Core as completely separate infrastructure. No one could access anything in Core without going through its API gateway over the internet—even our own products consumed it as if they were third parties. This wasn't just good architecture—it was a compliance decision. When you're handling financial transactions, you need clear separation of concerns and complete auditability. Every request logged, every response traceable.

We knew from day one that KYC would be central to our operations. In early 2019, when we were building our on/off ramp connected to Binance, we chose Jumio as our document verification provider—they were industry-leading, and importantly, Binance used them too. This wasn't just about technology—it was about demonstrating to partners that we were using institutional-standard tooling.

The first major challenge came with Comply Advantage. We had an extremely high false positive rate—any minor name match in adverse media would freeze the user. Over two years, we hadn't received a single true positive from Comply. So we made a pragmatic decision: we introduced a new status called "unverified_screening" that allowed users to operate while flagging their dossier for operator review. This dramatically improved our conversion rate without sacrificing real compliance.

About a year ago, everything changed. New regulations in Argentina meant PSAVs (crypto service providers) would be regulated similarly to PSPs. Simultaneously, our CEO pushed to replace Jumio with a local provider that charged in pesos instead of dollars. We integrated Nosis to obtain credit scores and risk profiles, then developed an internal risk matrix. For transaction monitoring, we built it in-house.

As a temporary solution while awaiting Renaper approval, we built an internal AI-powered verification system. The challenge was balancing innovation with compliance—new technology had to meet the same audit standards as traditional providers. This affected our conversion rate initially, but we maintained operations through significant regulatory changes while continuing to iterate on the solution.

Throughout this evolution, we implemented progressive KYC—less stringent checks for low amounts, more thorough verification as users scale up. This is a risk-based approach recommended by FATF: you allocate compliance resources where the risk is highest.

The team's main argument was that TypeScript was trending and "everyone was doing it." They justified it with the standard reasons: it's typed, less error-prone, more comfortable to develop. The pressure wasn't just from one person—the request itself was legitimate. I love being on the cutting edge with technology, but I also understand that if we chase every new tech trend, we'd live in eternal refactoring.

I evaluated several factors. The cost of migration was enormous—we had too much code, and we were constantly running behind objectives with train releases loaded with features and pre-established dates. There was no way to tell management that deadlines would slip for a technical improvement. More importantly, we didn't have a real pain point. We were a large team but well-segmented, we knew each other and our codebases well.

My focus at that time was on standardizing how we worked, not changing it. In a startup handling financial transactions, predictability is more valuable than cutting-edge tech. Our partners needed to know that when we deployed, things wouldn't break. Our operations team needed consistent patterns across services. Stability isn't sexy, but it's what lets you move fast sustainably.

I deliberately kept everything in JavaScript—even across frontend and backend, even our E2E tests—because I prioritized cross-project understanding and velocity in a volatile, fast-paced startup environment. Before announcing my decision, I had individual conversations with the most senior developers and persuaded them it was the right call.

About a year later, when the pace calmed down and I saw the opportunity, I was the one who proposed modernizing. We didn't just adopt TypeScript—we also started using Next.js and NestJS where appropriate. To this day, the legacy systems remain in pure JavaScript, and that's fine.

I spent all of 2018 working alone. My first attempt at building a team—4 junior part-timers in late 2018—failed. Their dedication was minimal, commitment was low. Everything changed in early 2019 when I brought in 2 full-time people I trusted. We'd just signed Binance for our on/off ramp and were starting our relationship with Stellar. Management knew we needed velocity.

The next major transition came when we secured funding ($10-12M USD). That unlocked a different scale—management loosened up and let me grow the team properly. From 20 to 40, the push came from management seeing that autonomous teams actually worked. We built 4 products in parallel, each with its own team.

But the hardest part wasn't the organizational structure—it was stepping back from what I did day-to-day and replicating myself into processes people could follow without me. I lived this multiple times: first when I stopped developing main features myself, then when I stopped being the tech lead and code review gatekeeper, then when I stopped managing infrastructure directly, and finally when all of this multiplied by 4 and I was 2-3 levels removed from daily work.

I was still in the details, but it was physically impossible to be in daily standups. I tried to attend planning sessions, but I had to trust my tech leads. And every transition involved hundreds of interviews for completely different roles—I was always involved in hiring decisions, performance issues, who to let go, who deserved another chance.

We ended up with tech leads per vertical, each product with its own PM. Each team ran their own planning and scrum ceremonies. We had special ceremonies between leaders to unify criteria and plan the big picture that involved everyone's results.

I ended up developing 4 tech leads. Two grew from within the company—one was my very first hire, and the second was a complete surprise. He had only 2 years of experience when he started, but he crushed it. The other two I hired externally (one of them I eventually had to let go due to toxic behavior and lack of commitment).

The best leader I developed was a semi-senior Node.js backend developer who became more than a tech lead—before he left the company, he was leading other tech leads. We achieved tremendous responsibility, synergy, and growth powered by his commitment. I think my best contribution to his growth wasn't just giving him a good framework, but motivation. One of my strengths is creating environments where people feel genuinely valued.

The hardest part about delegation isn't delegating tasks—it's the responsibility that comes with it. You can delegate the task, but not the responsibility. That thin line between delegating work and maintaining accountability is the hardest not to cross. The most difficult thing to delegate has always been the soft skills, not the technical ones. For example, it's always been hard to get people to make time to evaluate others properly.

What I learned is that a good tech lead needs: empathy, discipline, good teaching skills, comfort speaking in front of people, analytical ability to understand problems, and strong technical skills so the team respects them. Technical excellence alone isn't enough—you need someone who can inspire, teach, and hold people accountable while maintaining team morale.