Profilo professionale
Software engineer full-stack, più forte sul frontend, con ~2,5 anni di sistemi in produzione per un'azienda di software per l'hospitality. Guido la migrazione page-by-page di un SaaS gestionale multi-tenant da Razor/jQuery legacy a React 19, e possiedo end-to-end le aree pagamenti, chiosco e marketplace di una piattaforma e-commerce — incluso un flusso di pagamento Nexi exactly-once su un downstream non idempotente. Ho inoltre costruito il workflow di engineering AI-augmented del team su Claude Code. Stack principale: React 19, TypeScript, Redux Toolkit + RTK Query, ASP.NET Core.
Adesso: Guido la migrazione page-by-page del SaaS gestionale multi-tenant Portal verso React 19, possiedo end-to-end le aree pagamenti, chiosco e marketplace della piattaforma e-commerce Network — incluso il flusso di pagamento Nexi exactly-once — e curo il workflow di engineering AI-augmented del team su Claude Code.
Ho architettato il frontend React 19 come tre SPA indipendenti — marketplace, chiosco e landing dei preventivi — su Redux Toolkit + RTK Query: un layer di auth con refresh 401 single-flight, un'architettura di pagamento ports-and-adapters (Nexi, wallet e sconti dietro un'unica interfaccia provider) e form su react-hook-form + Zod che normalizzano payload legacy inconsistenti al boundary. In parallelo ho condotto un audit di sicurezza e tenancy sul gestionale multi-tenant che ha fatto emergere accessi cross-tenant (IDOR) e un token CSRF emesso ma mai validato lato server, irrobustendo poi l'isolazione dei dati con il claim del tenant filtrato sulla riga.
Ho progettato il framework di engineering AI-augmented del team su Claude Code: file di istruzioni per layer, subagent specializzati con tool ristretti e una skill di orchestrazione plan-first. Ho costruito subagent di review read-only sul codebase ASP.NET Core / React — 3 bug latenti del flusso pagamenti sono emersi prima del rilascio.
Condivido approccio e impatto apertamente; alcuni dettagli interni restano fuori.
Filosofia tecnica: Risolvi il problema, poi rendi difficile che si ripeta — con standard, contratti tipizzati e review adversariale.
Risultati
Flusso di pagamento Nexi exactly-once
Primail pagamento dei preventivi colpiva un sistema di prenotazione downstream non idempotente, esposto a doppie prenotazioni, conferme perse e risposte silenziose "HTTP 200 ma fallite".
Dopoun payment-lock locale con chiave su un codice transazione univoco e una state machine gestita con MediatR (pending → nexi_paid → confirmed | failed) che ignora i callback di gateway ritrasmessi, con un guard sulle risposte silenziose perché nessun pagamento risulti confermato senza una prenotazione reale.
Risultatopagamento esattamente-una-volta — niente doppie prenotazioni né conferme perse.
Frontend React 19 come tre SPA indipendenti
Primala piattaforma e-commerce era stata sviluppata esternamente senza soddisfare i requisiti e andava ricostruita in-house.
Dopomarketplace, chiosco e landing dei preventivi come tre SPA su Redux Toolkit + RTK Query, con un layer di auth a refresh 401 single-flight, un'architettura di pagamento ports-and-adapters (Nexi / wallet / sconti dietro un'unica interfaccia provider) e form su react-hook-form + Zod su payload legacy inconsistenti.
Risultatobooking, carrello, checkout, wallet e account portati da zero a produzione, con testing Vitest e Playwright (e2e + a11y).
Migrazione SaaS multi-tenant senza riscrittura big-bang
Primaun SaaS gestionale multi-tenant per l'hospitality su ASP.NET MVC / Razor / jQuery legacy, da modernizzare senza fermare il prodotto.
Dopomigrazione page-by-page a React 19 montata nell'app esistente dietro un backend-for-frontend, con un route manifest che decide per ogni pagina se navigare in SPA o ricaricare.
Risultatole pagine migrano in modo incrementale, senza una riscrittura big-bang né interruzioni per i tenant.
Audit di sicurezza e tenancy (IDOR + CSRF)
Primal'isolazione dei dati multi-tenant non era verificata e i confini di sicurezza erano impliciti.
Dopoaudit di sicurezza e tenancy che ha fatto emergere accessi cross-tenant (IDOR) e un token CSRF emesso ma mai validato lato server, con il claim del tenant ripensato per filtrare sulla riga e non via join a un padre.
Risultatoisolazione dei dati multi-tenant irrobustita e rilievi di sicurezza chiusi prima che diventassero incidenti.
Framework di engineering AI-augmented (Claude Code)
Primala code review dipendeva dalla disponibilità del team e il drift cross-stack TS↔C# sfuggiva.
Dopoun framework su Claude Code con file di istruzioni per layer, subagent specializzati con tool ristretti e una skill di orchestrazione plan-first, più subagent di review read-only sul codebase ASP.NET Core / React.
Risultato3 bug latenti del flusso pagamenti emersi prima del rilascio; review adversariale ripetibile su ogni nuova feature.
Progetti selezionati
Bookable — Multi-Style Booking Platform
Piattaforma di prenotazione full-stack live: un solo modello di contenuti reso in tre design system commutabili a runtime, un flusso di richiesta prenotazione validato e una dashboard admin sicura.
laboratoire — monorepo React 19 / TypeScript
Monorepo personale pnpm + Turbo. Costruito il core server-side di un flusso di prenotazione su Next.js App Router — order processing idempotente, ri-validazione dei prezzi lato server e un webhook Cal.com con verifica HMAC timing-safe — dietro auth admin con iron-session e una CI gate senza segreti.
Esperienza
Software Engineer — Network (e-commerce hospitality) · React 19 · ASP.NET Core 10
- Contributore principale e primo autore per volume di commit della piattaforma e-commerce, ricostruita in-house dopo che lo sviluppo esterno precedente non aveva soddisfatto i requisiti. Unico autore del flusso di pagamento dei preventivi, fondatore del chiosco React di self check-in e autore dominante della SPA marketplace — booking, carrello, checkout, wallet e account — da zero a produzione.
- Reso il pagamento dei preventivi esattamente-una-volta su un sistema di prenotazione downstream non idempotente: un payment-lock locale con chiave su un codice transazione univoco e una state machine gestita con MediatR (pending → nexi_paid → confirmed | failed) che ignora i callback di gateway ritrasmessi — niente doppie prenotazioni né conferme perse, con un guard sulle risposte silenziose "HTTP 200 ma fallite" perché nessun pagamento risulti confermato senza una prenotazione reale.
- Architettato il frontend React 19 come tre SPA indipendenti (marketplace, chiosco, landing preventivi) su Redux Toolkit + RTK Query: un layer di auth con refresh 401 single-flight, un'architettura di pagamento ports-and-adapters (Nexi / wallet / sconti dietro un'unica interfaccia provider) e form su react-hook-form + Zod su payload legacy inconsistenti. Testing con Vitest e Playwright (e2e + a11y); coordinato il release train testing → staging → production su Azure DevOps.
- Progettato il framework AI-augmented del team su Claude Code (file di istruzioni per layer, subagent specializzati con tool ristretti, una skill di orchestrazione plan-first) e costruiti subagent di review read-only sul codebase ASP.NET Core / React — 3 bug latenti del flusso pagamenti emersi prima del rilascio.
Software Engineer — Portal (SaaS gestionale multi-tenant) · React 19 · ASP.NET Core · BFF
- Alla guida della migrazione page-by-page di un SaaS gestionale multi-tenant per l'hospitality da ASP.NET MVC / Razor / jQuery legacy a React 19, montato nell'app esistente dietro un backend-for-frontend; un route manifest decide per ogni pagina se navigare in SPA o ricaricare, così le pagine migrano in modo incrementale senza riscrittura big-bang.
- Verificata e irrobustita l'isolazione dei dati multi-tenant (claim del tenant filtrato sulla riga, non via join a un padre); condotto un audit di sicurezza e tenancy che ha fatto emergere accessi cross-tenant (IDOR) e un token CSRF emesso ma mai validato lato server, tra gli altri rilievi.
- In precedenza su Portal: costruito un sistema di classi CSS riutilizzabili e file di utility JS condivisi diventati il riferimento del team per le nuove pagine, riducendo la duplicazione tra moduli; irrobustita la pipeline di deploy contro bundle frontend obsoleti.
Frontend Developer · Stage
- Front-end per fatturazione automatica (B2C / B2B2C) con HTML, CSS, JS e C# / ASP.NET MVC.
- Integrazione API Aruba per la fatturazione elettronica; standardizzazione UI e refactoring del codice legacy prima del rilascio.
Formazione
Level 3 Diploma · Computing
Fondamenti software, concetti dati, basi di sviluppo web.
Diploma di Perito Informatico
Diploma quinquennale ITIS in informatica; fondamenti di programmazione, basi di dati, networking.