Skip to content

Nicolás Raffagnini

ES
ES

Nicolás RaffagniniFull Stack Developer · Backend & DevOps

I own the product end to end.

Gathering requirements with the client, data modeling, backend, frontend, infrastructure and production support. Today I maintain an ERP with 7 daily users and a multi-agent AI system already driving real sales.

Email meWhatsAppDownload CVView GitHub

Open to opportunities · remote or Rosario

What sets me apart

  1. 01

    A multi-agent system in production with a measured business result, not a demo.

  2. 02

    I own the infrastructure, not just the code: a self-hosted server configured from scratch and a CI/CD pipeline I built myself.

  3. 03

    Technical lead of a 3-developer team, working directly with the client.

+30%
more retail sales
33
business modules in production
~1.059
automated tests
USD 150
saved on infrastructure per month

Figures from the ERP and the multi-agent system I maintain at NBG today. Each one is explained in the cases below.

Cases

Five real problems: the situation, what I did and the result. The figures come from the dossier, unrounded.

AI in production
NBG
2025 – hoy

A multi-agent system that sells on its own

+30%more retail sales, measured against the last 3 months of statistics

Situation
The retail sales cycle was manual: every inquiry was handled by a person, end to end.
What I did
I designed an orchestration of several agents in TypeScript on top of the Gemini API, with Redis for each conversation state and the queues between agents, and MySQL for persistence. Claude as a development assistant: prompts, refactors and documentation.
Result
~30% more retail sales in the last 3 months of statistics. This is not a demo or a course project: it runs in production.
  • TypeScript
  • API de Gemini
  • Redis
  • MySQL
  • Docker
Technical detail
  • A seller-agent uses Gemini to compute 768-dimension embeddings for every product; the ERP consumes them for its semantic search. That is the contact point between both systems.
  • Redis holds each conversation state and the queues between agents.
  • It runs containerized on the same self-hosted server as the ERP.
Multi-agent system flowThe customer comes in through the sales channel, the orchestrator distributes work across the agents, the agents reason against the Gemini API, Redis holds state and queues, MySQL persists, and the seller-agent hands the ERP the 768-dimension embeddings that power its semantic search.Coordinated agentsseller-agentother agentsCustomerOrchestratorGemini APIRedisstate + queuesMySQLpersistenceERPsemantic search768d embeddings
End-to-end product
NBG
2025 – hoy

WWSystem · the ERP that replaced a factory’s spreadsheets

33business modules in production, plus 8 shared ones

Situation
A nutritional supplements factory ran its entire operation on spreadsheets and manual processes, with no traceability and no real stock control.
What I did
I built a full-stack, multi-role ERP covering everything from raw material purchasing to invoice collection: data modeling, backend, frontend, infrastructure and support. I am the technical lead of the project in a 3-developer team, with ~1,065 commits of my own out of ~2,500 (~42%).
Result
In production with 7 daily users across sales, plant, back office and management. First version in under 6 months. Today: ~158,000 lines, 58 tables, 221 versioned migrations, ~287 REST endpoints and ~1,059 automated tests.
  • Node.js 22
  • Express 4
  • Sequelize
  • MySQL / MariaDB
  • React 18
  • Vite
  • Tailwind CSS
  • Socket.IO
  • Docker
  • GitHub Actions
  • Nginx
Technical detail
  • End-to-end purchase orders: draft → quoted → issued → invoiced → received → reconciled, with an append-only event ledger and reversal by storno, never by deletion.
  • Administrative and accounting circuit: hierarchical chart of accounts, expenses with two status axes, due dates and partial payments, recurring expenses by cron and supplier current accounts.
  • VAT ledger and tax breakdown engine: taxable base derived from the gross amount, with the net figure taken by difference so the total matches the invoiced amount exactly.
  • Financial instrument portfolio (checks and e-checks) as a cross-cutting module between collections and payments: the same instrument comes in through a collection and goes out through a payment, with audited transitions.
  • Append-only audit trail with before/after snapshots of ~20 entities, scoped against the stock ledgers so nothing is recorded twice.
  • Semantic product search with 768-dimension embeddings and in-memory cosine similarity, with the cache warmed at startup; price and stock are never embedded, they are read live.
  • Architectural refactor of the backend from a horizontal layout to self-contained vertical features —a modular monolith of 33 modules— with explicit dependency rules and cycles resolved through lazy loading.
  • Transactions with SELECT ... FOR UPDATE on every operation that moves stock or money, with a single gate that prevents negative balances.
Purchase order circuitA purchase order moves through six states, from draft to reconciled. Every transition is written to an append-only ledger, and an order is never deleted: it is reversed by storno.DraftQuotedIssuedInvoicedReceivedReconciledAppend-only event ledgerReversal by storno · never deleted
Infrastructure
NBG
2025

Cloud costs against seven internal users

USD 150saved per month, against a one-time USD 650 investment

Situation
The ERP ran on Google Cloud (Cloud Run + MySQL instances), chosen initially for high availability. The monthly cost weighed on a small operation.
What I did
I measured the actual spend against the actual usage, proposed a self-hosted server and configured it from scratch: operating system, Nginx, Node.js, MySQL and Docker containers. Then I built the CI/CD with GitHub Actions.
Result
USD 150 per month saved against a one-time USD 650 investment, paid back in under 5 months. Deploy time went from ~10 minutes to 2:30 (−75%).
  • Linux
  • Nginx
  • Docker Compose
  • GitHub Actions
  • GHCR
  • rclone + systemd
Technical detail
  • Two isolated environments —production and testing— behind an NGINX gateway that terminates TLS.
  • GitHub Actions publishes the images to GHCR and deploys through a self-hosted runner.
  • Daily backup to Google Drive with rclone + systemd, GFS retention (7 daily / 4 weekly / 12 monthly) and dump integrity verification.
  • The trade-off is explicit: less high availability was accepted for an operation with 7 internal users.
Pipeline and infrastructureA push triggers GitHub Actions, which publishes the image to GHCR; a self-hosted runner deploys it on the self-hosted server, behind an NGINX gateway that terminates TLS over two isolated environments. A daily backup with rclone and systemd uploads to Google Drive with GFS retention.pushGitHub ActionsGHCRSelf-hosted runnerNGINX gatewayterminates TLSProductionTestingrclone + systemdGoogle DriveGFS 7 / 4 / 12deploy 2:30
Security
NBG
2025

Authorization hardcoded across ~287 endpoints

~287REST endpoints, with authorization declared in a single place

Situation
Authorization was written by hand per role, with xOrAdmin-style middlewares scattered across the routes. Every new role or exception meant touching code in several places.
What I did
I designed a declarative permission catalog as the single source for both the code and the migration seed, a generic requirePermission() middleware, SQL resolution with a cache (explicit invalidation when roles are edited, plus a 5-minute TTL as a safety net) and data scopes enforced inside the services.
Result
A single place where who-can-do-what is declared, with an automated test validating the catalog’s consistency. I removed the administrator bypass from the code: the admin gets the wildcard from the database, so all authorization goes through the same path.
  • Node.js 22
  • Express 4
  • Sequelize
  • MySQL
  • Mocha
Technical detail
  • The catalog uses the <resource>.<action>.<scope> shape and feeds both the code and the migration seed: there is no second source of truth.
  • 7 roles, with data scopes (own vs all) enforced inside the services, not in the routes.
  • Explicit invalidation covers the normal case; the 5-minute TTL is the safety net in case a node misses an event.
Domain modeling
NBG
2025

Three permissions for a single fact

3deliberately separate permissions for three different owners

Situation
On goods receipt, the plant operator sees the flagged goods, but whoever decides if they are accepted with a deviation or returned is the back office.
What I did
I split three deliberately distinct permissions: plant reports, back office decides and plant confirms the entry into stock, with the event recorded in an append-only ledger.
Result
The circuit reflects each department’s actual responsibility. A single permission would have given the plant the power to accept expired goods into stock.
  • Modelado de dominio
  • Ledger append-only
  • RBAC
Technical detail
  • The append-only ledger records the fact along with its owner: who reported, who decided and who confirmed.
  • The circuit is transactionally integrated with stock, expenses and the VAT ledger.

Stack

Technologies used professionally in production, and defensible in a technical interview.

Backend

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

Data

  • MySQL / MariaDB
  • MongoDB
  • Redis
  • Sequelize
  • Mongoose
  • ER modeling
  • Transactions and row locking

Frontend

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

Security

  • RBAC with a declarative catalog
  • JWT in an httpOnly cookie
  • Double-submit CSRF
  • Helmet
  • CORS allowlist
  • Rate limiting

Testing

  • Mocha
  • Chai
  • Sinon
  • Supertest
  • Postman

Infrastructure

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

AI

  • Multi-agent systems
  • Gemini API
  • Embeddings and cosine similarity
  • Claude Code

Process

  • SCRUM
  • Trello
  • PR code review
  • Branch and commit conventions
  • Versioned migrations

Knowledge without a production project

  • PostgreSQL
  • Python

Experience

  1. 2025 — present

    Nutriblend Group S.A.S. · WinWar

    Full Stack Developer · Backend · Frontend · DevOps

    An ERP in production and a multi-agent sales system. Technical lead of a 3-developer team.

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

    WOTECH

    Technical Lead and Full Stack Developer

    Led 3 developers for 12 months under SCRUM: 8 modules delivered across ~24 sprints.

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

    No Country

    Backend Developer and team lead · professional practice

    Coordinated 3 backend developers inside a 9-person team and built the MVP scoring and matching algorithm.

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

Education

2023 – 2025

Higher Technical Degree in Software Development

Terciario J. J. de Urquiza, Rosario

2025 – 2026

Generative AI Software Engineering Specialization

Coursera

2025 – 2026

Agentic AI systems development

Microsoft

2022

Node.js Backend Development · React Frontend Development

Coderhouse

Languages

  • Spanish — native
  • English — B1. I read technical documentation and write in English; fluent conversation, not yet.