Nutriblend Group S.A.S. · WinWar
Full Stack Developer · Backend · Frontend · DevOps
Two parallel tracks: the company ERP and the multi-agent sales system. Docker every day: containerized local environment, image built in the pipeline and containerized deployment on a self-hosted server.
Multi-agent automated sales system
+30% in retail sales
Several coordinated agents automate the retail sales cycle. TypeScript, Gemini API for agent reasoning, Redis for state and queues, MySQL for persistence.
- TypeScript
- Gemini API
- 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.
- The result is measured against the last 3 months of sales statistics. This is not a demo: it runs in production.
- Claude as an assistant during development: prompts, refactors and technical documentation.
WWSystem · custom ERP for the nutritional supplements industry
Technical lead, team of 3
Full-stack, multi-role ERP covering the whole operation, from raw material purchasing to invoice collection. In production, with 7 daily users across sales, plant, back office and management. First version in under 6 months; ~1,065 commits of my own out of ~2,500 (~42%).
- Node.js 22
- Express 4
- Sequelize
- MySQL / MariaDB
- React 18
- Vite
- Tailwind CSS
- Socket.IO
- Docker
- GitHub Actions
- Nginx
Technical detail
- Complete RBAC system: a declarative permission catalog
<resource>.<action>.<scope>as the single source for both the code and the migration seed, 7 roles, data scopes (own vs all) enforced in the services, SQL resolution with an in-memory cache (explicit invalidation + 5-minute TTL) and a genericrequirePermission()middleware. The administrator has no bypass in code: the wildcard comes from the database. - End-to-end purchase orders: draft → quoted → issued → invoiced → received → reconciled, with an append-only event ledger, reversal by storno (never deletion), a quantity-difference inbox and an inconsistency circuit splitting three permissions across three owners. Transactionally integrated with stock, expenses and the VAT ledger.
- Administrative and accounting circuit: hierarchical chart of accounts, expenses with two status axes (payment and document), 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 UPDATEon every operation that moves stock or money, with a single gate that prevents negative balances. - Infrastructure: multi-stage Docker and Compose, GitHub Actions publishing images to GHCR and deploying through a self-hosted runner, two isolated environments (production and testing) behind an NGINX gateway terminating TLS, daily backup to Google Drive with rclone + systemd and GFS retention (7 daily / 4 weekly / 12 monthly) with dump integrity verification.
- System scale: ~158,000 lines of code, 3 repositories, 58 tables, 221 versioned migrations, ~287 REST endpoints and ~1,059 automated tests.