Ir al contenido

Nicolás Raffagnini

EN
EN

Nicolás RaffagniniDesarrollador Full Stack · Backend & DevOps

Me hago cargo del producto de punta a punta.

Relevamiento con el cliente, modelado de datos, backend, frontend, infraestructura y soporte en producción. Hoy sostengo un ERP con 7 usuarios diarios y un sistema multiagente de IA que ya genera ventas reales.

EscribimeWhatsAppDescargar CVVer GitHub

Abierto a propuestas · remoto o Rosario

Lo que me diferencia

  1. 01

    Un multiagente en producción con resultado de negocio medido, no un demo.

  2. 02

    Dueño de la infraestructura, no sólo del código: servidor propio configurado desde cero y CI/CD armado por mí.

  3. 03

    Referente técnico de un equipo de 3, con trato directo con el cliente.

+30%
más ventas minoristas
33
módulos en producción
~1.059
tests automatizados
USD 150
de ahorro mensual de infra

Cifras del ERP y del multiagente que sostengo hoy en NBG. Las expliqué una por una en los casos.

Casos

Cinco problemas reales: la situación, qué hice y con qué resultado. Las cifras son las del dossier, sin redondear.

IA en producción
NBG
2025 – hoy

Un sistema multiagente que vende solo

+30%más ventas minoristas, medido sobre la estadística de los últimos 3 meses

Situación
El ciclo de venta minorista era manual: cada consulta la atendía una persona, de punta a punta.
Qué hice
Diseñé una orquestación de varios agentes en TypeScript sobre la API de Gemini, con Redis para el estado de cada conversación y las colas entre agentes, y MySQL para la persistencia. Claude como asistente de desarrollo: prompts, refactors y documentación.
Resultado
~30% más de ventas minoristas en la estadística de los últimos 3 meses. No es un demo ni un proyecto de curso: está en producción.
  • TypeScript
  • API de Gemini
  • Redis
  • MySQL
  • Docker
Detalle técnico
  • Un seller-agent calcula con Gemini los embeddings de 768 dimensiones de cada producto; el ERP los usa para su búsqueda semántica. Es el punto de contacto entre los dos sistemas.
  • Redis sostiene el estado de cada conversación y las colas entre agentes.
  • Corre contenerizado en el mismo servidor propio que el ERP.
Flujo del sistema multiagenteEl cliente entra por el canal de venta, el orquestador reparte el trabajo entre los agentes, los agentes razonan contra la API de Gemini, Redis sostiene el estado y las colas, MySQL persiste, y el seller-agent le pasa al ERP los embeddings de 768 dimensiones que alimentan su búsqueda semántica.Agentes coordinadosseller-agentotros agentesClienteOrquestadorAPI de GeminiRedisestado + colasMySQLpersistenciaERPbúsqueda semánticaembeddings 768d
Producto de punta a punta
NBG
2025 – hoy

WWSystem · el ERP que reemplazó las planillas de una fábrica

33módulos de negocio en producción, más 8 compartidos

Situación
Una fábrica de suplementos nutricionales manejaba su operación completa con planillas y procesos manuales, sin trazabilidad ni control de stock real.
Qué hice
Construí un ERP full-stack y multi-rol que cubre de la compra de materia prima al cobro de la factura: modelado de datos, backend, frontend, infraestructura y soporte. Soy el referente técnico del proyecto en un equipo de 3 desarrolladores, con ~1.065 commits propios sobre ~2.500 (~42%).
Resultado
En producción con 7 usuarios diarios de ventas, planta, back office y dirección. Primera versión en menos de 6 meses. Hoy: ~158.000 líneas, 58 tablas, 221 migraciones versionadas, ~287 endpoints REST y ~1.059 tests automatizados.
  • Node.js 22
  • Express 4
  • Sequelize
  • MySQL / MariaDB
  • React 18
  • Vite
  • Tailwind CSS
  • Socket.IO
  • Docker
  • GitHub Actions
  • Nginx
Detalle técnico
  • Órdenes de compra de punta a punta: borrador → cotizada → emitida → facturada → recibida → conciliada, con ledger append-only de eventos y anulación por storno, nunca por borrado.
  • Circuito administrativo-contable: plan de cuentas jerárquico, egresos con dos ejes de estado, vencimientos y pagos parciales, egresos recurrentes por cron y cuenta corriente de proveedores.
  • Libro de IVA y motor de desglose fiscal: base imponible despejada desde el importe total, con neto por diferencia para que la suma cierre exacta contra el total facturado.
  • Cartera de valores financieros (cheques y e-cheques) como módulo transversal entre cobranzas y pagos: el mismo instrumento entra por un cobro y sale por un pago, con transiciones auditadas.
  • Auditoría append-only con snapshot antes/después de ~20 entidades, delimitada frente a los ledgers de stock para no duplicar registro.
  • Búsqueda semántica de productos con embeddings de 768 dimensiones y similitud coseno en memoria, con caché precalentado al arrancar; precio y stock nunca se embeben, se leen en vivo.
  • Refactor arquitectónico del backend de estructura horizontal a features verticales autocontenidas —monolito modular de 33 módulos— con reglas de dependencia explícitas y ciclos resueltos por lazy loading.
  • Transacciones con SELECT ... FOR UPDATE en toda operación que mueve stock o dinero, con una única compuerta que impide saldos negativos.
Circuito de la orden de compraLa orden de compra recorre seis estados, de borrador a conciliada. Cada transición queda escrita en un ledger append-only, y una orden nunca se borra: se anula por storno.BorradorCotizadaEmitidaFacturadaRecibidaConciliadaLedger append-only de eventosAnulación por storno · nunca borrado
Infraestructura
NBG
2025

El costo de la nube contra siete usuarios internos

USD 150por mes de ahorro, con una inversión única de USD 650

Situación
El ERP corría en Google Cloud (Cloud Run + instancias de MySQL), elegido al principio por alta disponibilidad. El costo mensual pesaba sobre una operación chica.
Qué hice
Evalué el gasto real contra el uso, propuse un servidor propio y lo configuré desde cero: sistema operativo, Nginx, Node.js, MySQL y contenedores Docker. Después armé el CI/CD con GitHub Actions.
Resultado
USD 150 por mes de ahorro con una inversión única de USD 650, amortizada en menos de 5 meses. El deploy pasó de ~10 minutos a 2:30 (−75%).
  • Linux
  • Nginx
  • Docker Compose
  • GitHub Actions
  • GHCR
  • rclone + systemd
Detalle técnico
  • Dos entornos aislados —producción y testing— detrás de un gateway NGINX que termina TLS.
  • GitHub Actions publica las imágenes en GHCR y despliega con un runner self-hosted.
  • Backup diario a Google Drive con rclone + systemd, retención GFS (7 diarios / 4 semanales / 12 mensuales) y verificación de integridad del dump.
  • El trade-off es explícito: se aceptó menos alta disponibilidad para una operación de 7 usuarios internos.
Pipeline e infraestructuraUn push dispara GitHub Actions, que publica la imagen en GHCR; un runner self-hosted la despliega en el servidor propio, detrás de un gateway NGINX que termina TLS sobre dos entornos aislados. Un backup diario con rclone y systemd sube a Google Drive con retención GFS.pushGitHub ActionsGHCRRunner self-hostedGateway NGINXtermina TLSProducciónTestingrclone + systemdGoogle DriveGFS 7 / 4 / 12deploy 2:30
Seguridad
NBG
2025

Autorización hardcodeada en ~287 endpoints

~287endpoints REST, con la autorización declarada en un solo lugar

Situación
La autorización estaba escrita a mano por rol, con middlewares del tipo xOrAdmin repartidos por las rutas. Cada rol nuevo o cada excepción implicaba tocar código en varios lugares.
Qué hice
Diseñé un catálogo declarativo de permisos como fuente única para el código y para el seed de las migraciones, un middleware genérico requirePermission(), resolución por SQL con caché (invalidación explícita al editar roles, más un TTL de 5 minutos como red) y scopes de datos aplicados dentro de los servicios.
Resultado
Un solo lugar donde se declara quién puede qué, con un test automatizado que valida la coherencia del catálogo. Saqué el bypass del administrador del código: el admin recibe el comodín desde la base, así toda la autorización pasa por el mismo flujo.
  • Node.js 22
  • Express 4
  • Sequelize
  • MySQL
  • Mocha
Detalle técnico
  • El catálogo usa la forma <recurso>.<acción>.<scope> y alimenta tanto al código como al seed de las migraciones: no hay dos verdades.
  • 7 roles, con scopes de datos (own vs all) aplicados dentro de los servicios, no en las rutas.
  • La invalidación explícita cubre el caso normal; el TTL de 5 minutos es la red por si un nodo se pierde un evento.
Modelado de dominio
NBG
2025

Tres permisos para un mismo hecho

3permisos deliberadamente separados para tres responsables distintos

Situación
En la recepción de mercadería, el operario de planta ve la mercadería observada, pero quien decide si se acepta con desvío o se devuelve es el back office.
Qué hice
Separé tres permisos deliberadamente distintos: planta reporta, back office decide y planta confirma el ingreso a stock, con el evento registrado en un ledger append-only.
Resultado
El circuito refleja la responsabilidad real de cada sector. Un solo permiso le habría dado a planta la potestad de aceptar mercadería vencida contra el stock.
  • Modelado de dominio
  • Ledger append-only
  • RBAC
Detalle técnico
  • El ledger append-only deja el hecho registrado con su responsable: quién reportó, quién decidió y quién confirmó.
  • El circuito está integrado transaccionalmente con stock, egresos y Libro de IVA.

Stack

Tecnologías con uso profesional en producción, defendibles en una entrevista técnica.

Backend

  • Node.js 22 (ESM)
  • TypeScript
  • JavaScript
  • Express
  • APIs REST
  • Socket.IO
  • node-cron
  • Joi
  • Winston

Datos

  • MySQL / MariaDB
  • MongoDB
  • Redis
  • Sequelize
  • Mongoose
  • Modelado ER
  • Transacciones y bloqueo de fila

Frontend

  • React 18
  • Vite
  • React Router
  • Zustand
  • Tailwind CSS
  • Material UI
  • Radix UI
  • Recharts

Seguridad

  • RBAC con catálogo declarativo
  • JWT en cookie httpOnly
  • CSRF por doble submit
  • Helmet
  • CORS con lista blanca
  • Rate limiting

Testing

  • Mocha
  • Chai
  • Sinon
  • Supertest
  • Postman

Infraestructura

  • Linux
  • Nginx
  • Docker
  • Docker Compose
  • GitHub Actions
  • GHCR
  • Google Cloud (Cloud Run)
  • Vercel
  • Render
  • rclone + systemd

IA

  • Sistemas multiagente
  • API de Gemini
  • Embeddings y similitud coseno
  • Claude Code

Proceso

  • SCRUM
  • Trello
  • Code review por PR
  • Convención de ramas y commits
  • Migraciones versionadas

Conocimiento sin proyecto en producción

  • PostgreSQL
  • Python

Experiencia

  1. 2025 — hoy

    Nutriblend Group S.A.S. · WinWar

    Desarrollador Full Stack · Backend · Frontend · DevOps

    ERP en producción y sistema multiagente de ventas. Referente técnico de un equipo de 3.

    • Node.js 22
    • Express 4
    • Sequelize
    • MySQL / MariaDB
    • React 18
    • Vite
    • Tailwind CSS
    • Socket.IO
    • Docker
    • GitHub Actions
    • Nginx
  2. 2024 — 2025

    WOTECH

    Líder Técnico y Desarrollador Full Stack

    Lideré 3 desarrolladores durante 12 meses bajo SCRUM: 8 módulos entregados en ~24 sprints.

    • Node.js
    • Express
    • MySQL
    • Sequelize
    • React
    • Tailwind CSS
    • Vercel
    • Render
  3. 2023 — 2024

    No Country

    Desarrollador Backend y líder de equipo · práctica profesional

    Coordiné 3 backend dentro de un equipo de 9 y desarrollé el algoritmo de scoring y matching del MVP.

    • Node.js
    • Express
    • MongoDB
    • Mongoose
    • Socket.io
    • Postman

Formación

2023 – 2025

Técnico Superior en Desarrollo de Software

Terciario J. J. de Urquiza, Rosario

2025 – 2026

Generative AI Software Engineering Specialization

Coursera

2025 – 2026

Desarrollo de sistemas de IA agéntica

Microsoft

2022

Desarrollo Backend Node.js · Desarrollo Frontend React

Coderhouse

Idiomas

  • Español — nativo
  • Inglés — B1. Leo documentación técnica y escribo en inglés; conversación fluida, todavía no.