Consultores TIC
Ver en español
Gustavo Azañero

Profile

Gustavo Azañero

I am a backend engineer. Since 2008 I have built and operated systems that other people depend on — lead engines that fan out to dozens of buyer APIs, content platforms, telephony integrations, management systems.

I run Consultores TIC, a small software and hosting company. That means I have never had the option of handing a problem to another team: infrastructure, deployment, monitoring, support and the customer conversation are all mine. It is not a career path I would recommend to everyone, but it removes any gap between what I build and what I have to keep alive.

I work spec-first and I use AI agents to move faster. I decide what to build, how it is structured, and whether it holds. That distinction matters to me and I keep it explicit.

How the stack evolved

The same problem — ingesting leads and dispatching them to partners — solved three times, each time with what the constraints actually required.

  1. 2008

    Consultores TIC

    Founded a software and hosting company serving local and international clients. Infrastructure, development and technical support for the same accounts for over a decade.

  2. 2012

    ApiFuel — native PHP

    Built the lead engine in native PHP, tuned for throughput under shared-hosting constraints. Performance was a design requirement from day one, not an optimisation pass.

  3. 2016

    ApiFuel — AWS Lambda and API Gateway

    Moved the ingestion and dispatch path to serverless. Traded server management for managed scaling, at the cost of cold starts and a harder debugging story.

  4. 2025

    ApiFuel — TypeScript, BullMQ and Redis Cluster

    Rebuilt the dispatch layer in TypeScript with BullMQ and a Redis Cluster. The constraint that drove the design was never request rate: it was outbound concurrency, because each lead fans out to multiple partner APIs. Added a controller that provisions an ephemeral EC2 fleet ahead of demand, since a new t4g.small takes one to two minutes to become ready.

Products I built and operated

How I approach engineering

Four things I would rather be judged on than a list of technologies.

  1. Simplest thing that satisfies the requirement

    Every dependency, service and abstraction is a cost someone pays for years. I add one when the requirement forces it, and I write down why. The decisions and the alternatives I rejected are public in this repository.

  2. Measure before claiming

    If I state a number, I can show how it was obtained and what it does not cover. A load test is not production traffic and I say so.

  3. Failure modes over happy paths

    Integrations, queues and networks fail partially and in ambiguous ways. Retries need idempotency, dispatch needs backpressure, and logs need to answer "what happened to this specific request".

  4. Own the whole thing

    Code that nobody operates is a guess. I deploy it, monitor it, answer the support email and fix it at 2 a.m. if that is what it takes.

The details

Full trajectory, technologies and availability in the CV.

Download the CV Get in touch