Consultores TIC
View in English
Gustavo Azañero

Perfil

Gustavo Azañero

Soy ingeniero backend. Desde 2008 construyo y opero sistemas de los que dependen otras personas — motores de leads que se distribuyen a decenas de APIs de compradores, plataformas de contenido, integraciones de telefonía, sistemas de gestión.

Dirijo Consultores TIC, una empresa chica de software y hosting. Eso significa que nunca tuve la opción de pasarle un problema a otro equipo: la infraestructura, el despliegue, el monitoreo, el soporte y la conversación con el cliente son míos. No es un camino que le recomendaría a todo el mundo, pero elimina cualquier distancia entre lo que construyo y lo que tengo que mantener vivo.

Trabajo con especificación previa y uso agentes de IA para avanzar más rápido. Yo decido qué construir, cómo estructurarlo y si resiste. Esa distinción me importa y la mantengo explícita.

Cómo evolucionó el stack

El mismo problema —ingestar leads y despacharlos a socios— resuelto tres veces, cada una con lo que las restricciones realmente exigían.

  1. 2008

    Consultores TIC

    Fundé una empresa de software y hosting que atiende clientes locales e internacionales. Infraestructura, desarrollo y soporte técnico para las mismas cuentas durante más de una década.

  2. 2012

    ApiFuel — PHP nativo

    Construí el motor de leads en PHP nativo, ajustado para rendimiento bajo las restricciones de hosting compartido. El rendimiento fue requisito de diseño desde el primer día, no una optimización posterior.

  3. 2016

    ApiFuel — AWS Lambda y API Gateway

    Pasé el camino de ingesta y despacho a serverless. Cambié administración de servidores por escalado gestionado, a costa de cold starts y una depuración más difícil.

  4. 2025

    ApiFuel — TypeScript, BullMQ y Redis Cluster

    Reconstruí la capa de despacho en TypeScript con BullMQ y Redis Cluster. La restricción que definió el diseño nunca fue la tasa de peticiones: fue la concurrencia saliente, porque cada lead se distribuye a múltiples APIs de socios. Agregué un controlador que provisiona una flota EC2 efímera por delante de la demanda, porque una t4g.small nueva tarda entre uno y dos minutos en estar lista.

Productos que construí y operé

Cómo encaro la ingeniería

Cuatro cosas por las que prefiero que me juzguen antes que por una lista de tecnologías.

  1. Lo más simple que satisface el requisito

    Cada dependencia, servicio y abstracción es un costo que alguien paga durante años. Agrego una cuando el requisito la obliga, y dejo escrito por qué. Las decisiones y las alternativas que descarté están públicas en este repositorio.

  2. Medir antes de afirmar

    Si digo un número, puedo mostrar cómo se obtuvo y qué no cubre. Una prueba de carga no es tráfico de producción, y lo digo.

  3. Modos de falla antes que caminos felices

    Las integraciones, las colas y las redes fallan parcialmente y de forma ambigua. Los reintentos necesitan idempotencia, el despacho necesita backpressure, y los logs tienen que responder «qué pasó con esta petición concreta».

  4. Hacerse cargo de todo

    El código que nadie opera es una suposición. Lo despliego, lo monitoreo, contesto el correo de soporte y lo arreglo a las 2 de la mañana si hace falta.

Los detalles

Trayectoria completa, tecnologías y disponibilidad en el CV.

Descargar el CV Ponerse en contacto