Problema

Los equipos de soporte de un ERP fiscal-contable reciben miles de tickets con información incompleta y vocabulario muy específico del dominio. El sistema clasifica, pide los datos que faltan, recupera contexto de guías oficiales y casos históricos, y prepara una respuesta o un resumen para el asesor humano, reduciendo el tiempo hasta primera respuesta y la carga de triaje manual.

Mi rol

Único desarrollador efectivo del backend (~325 de ~340 commits). Diseñé e implementé end-to-end: API, orquestación con LangGraph, capa RAG, anonimización, ingesta XLSX, dashboard de revisión, observabilidad, migraciones y CI.

Decisiones técnicas

• Grafo de estado con LangGraph en vez de cadenas lineales: separa nodos de recolección, clasificación, retrieval y finalización, con routing condicional (follow-up vs. escalado humano).
• Retrieval híbrido: denso en Qdrant + BM25 con filtro por aplicación + reranker en Vertex AI, con historical boost y adaptive threshold. Mejor recall en dominios con jerga muy específica.
• Modo shadow + dataset curado v2 incremental para iterar prompts y modelos midiendo p85 sin tocar producción.
• LiteLLM + Langfuse como capa unificada: cambiar entre Gemini Flash, Flash Lite y OpenAI sin tocar los nodos del grafo.
• Anonimización en tres capas previa al LLM para no exponer datos fiscales sensibles a proveedores externos.

Qué demuestra

Llevar un sistema de IA aplicada de cero a producción solo — arquitectura, RAG no trivial, observabilidad, evaluación con shadow mode y despliegue — manteniendo el código testeable y el dominio (fiscal, datos sensibles) bajo control.

Stack

Problema

Pequeños y medianos negocios pierden ventas por no responder rápido en WhatsApp y Telegram. La plataforma les da un asistente con IA que toma pedidos, reservas, consulta stock y escala a humano cuando hace falta, configurable desde un dashboard sin tocar código.

Mi rol

Único desarrollador end-to-end (~132 commits, autor único). Arquitectura de microservicios, modelo multi-tenant en Postgres, pipeline de prompts en capas, tool-calling, auto-evaluación nocturna, dos proveedores WhatsApp intercambiables y dashboard React.

Decisiones técnicas

• Schema por tenant en Postgres (en vez de tenant_id en columnas) para aislamiento real de datos y backups granulares por cliente.
• Redis Streams como bus entre Gateway y Core en lugar de HTTP directo, para desacoplar canales (Telegram/WhatsApp) del motor de IA y permitir reintentos/backpressure.
• Prompt en capas (IDENTITY → CAPABILITIES → INSTRUCTIONS → ADJUSTMENTS → KNOWLEDGE → HISTORY) con tools filtradas por capacidades del tenant en YAML, para que el mismo core sirva a negocios muy distintos sin forks.
• Ciclo de auto-mejora nocturno: un worker evalúa conversaciones con LLM y propone ajustes al prompt del tenant, revisables desde el dashboard.

Qué demuestra

Llevar un producto SaaS completo de cero a MVP comercializable solo — arquitectura distribuida, multi-tenancy real, integración con LLMs y dashboard de operación — con decisiones de aislamiento, desacople y configurabilidad pensadas para escalar a múltiples clientes.

Stack

Problema

Empresas con cientos de cuentas de servicios públicos (energía, gas, agua, telecomunicaciones) gastan miles de horas mensuales descargando facturas de portales, validándolas, contabilizándolas y pagándolas. La plataforma automatiza ese ciclo end-to-end, con auditoría, alertas y conciliación bancaria integradas.

Mi rol

Lead backend / principal mantenedor. Sobre ~9.700 commits totales, ~7.100 son míos (más del 70%). Diseñé los subsistemas de workers asíncronos, reportería, pipelines de IA para extracción/digitalización de facturas, conciliación bancaria, alertas y la mayoría del esquema Prisma. Coordino con un equipo de 4–6 desarrolladores.

Decisiones técnicas

• Arquitectura basada en colas BullMQ con 79 workers especializados (descarga, auditoría, conciliación, pagos, alertas) para aislar fallos por integración externa y permitir reintentos y backpressure sin afectar el API.
• Capa de IA propia con agentes LangGraph, RAG y memoria en MongoDB, con observabilidad en LangSmith, para extracción estructurada de campos desde facturas heterogéneas (PDF/imagen) y clasificación de correos.
• 147 reportes Excel generados como jobs en disco bajo un patrón uniforme, permitiendo a usuarios de negocio pedir extracciones complejas sin tocar BI.
• Datastream Postgres → BigQuery para analítica sin penalizar el OLTP; índices parciales y funciones SQL custom para acelerar los flujos críticos de pago.

Qué demuestra

Sostener y evolucionar un sistema crítico de larga vida con muchas integraciones frágiles (portales externos, bancos, OCR/IA), priorizando observabilidad, colas desacopladas y automatización donde antes había trabajo manual. Cómodo cruzando dominios: DB performance, workers, IA aplicada y reportería de negocio.

Stack