Leonardo Chiaramonti

Problema

Il prodotto richiedeva feature nuove ogni settimana. Un rewrite big-bang avrebbe congelato la delivery per mesi; restare sullo stack legacy rendeva ogni feature più lenta e rischiosa.

Impatto

• ✓Una codebase tipizzata e testabile su cui il team può davvero assumere.
• ✓Le nuove schermate di listing passano da giorni a ore grazie alla DataTable generica e alle convenzioni di routing.
• ✓Zero downtime in produzione durante la migrazione.
• ✓Prodotto e delivery gestiti da solo per un anno: roadmap, priorità e release per 650 punti vendita — un prodotto che da solo vale ~300k€/anno.

Approccio

• >Ricostruita l’applicazione su TanStack Start, React 19, TanStack Router/Query/Table/Form, Zod, shadcn/ui e Tailwind v4 — routing file-based, loader query con Suspense, search params come unica fonte di verità per paginazione, ordinamento e filtri.
• >Progettata una DataTable generica server-side e un design system brandizzato: le nuove schermate CRUD diventano configurazione, non codice.
• >App legacy mantenuta in produzione durante la transizione; lo stesso backend Spring Boot serve entrambe, quindi il cutover è per schermata, non per prodotto.

Problema

Una sola codebase doveva rilasciare in modo affidabile su iOS e Android tra dev, staging e produzione, con fix rapidi sul campo e nessuna release rotta.

Impatto

• ✓Gli ispettori ricevono i fix in ore via OTA invece che in giorni via store review.
• ✓Ogni release passa dai flussi E2E prima di arrivare su un dispositivo.
• ✓Un solo team rilascia tre ambienti e due store da una singola codebase.

Approccio

• >Expo SDK 53 + React 19 + React Native 0.79 con expo-router, NativeWind, MMKV, Reanimated e react-hook-form + Zod per form tolleranti all’offline.
• >Build EAS multi-ambiente (dev / staging / prod) con aggiornamenti over-the-air per hotfix immediati che saltano la review degli store.
• >Quality gate in CI: 12 workflow GitHub Actions tra lint, type-check, unit test e flussi end-to-end Maestro; Sentry in produzione.
• >Lavoro di performance dove serve: GridList al posto di FlatList, refactor del calendario, flussi BottomSheet, gestione tastiera.

Problema

La registrazione manuale delle temperature è soggetta a errori e non soddisfa gli auditor; le piattaforme IoT off-the-shelf erano costose, rigide e impossibili da integrare con la suite HACCP.

Impatto

• ✓Monitoraggio continuo e automatico della catena del freddo al posto dei registri manuali.
• ✓Registrazioni di temperatura pronte per gli audit, con alert sulle violazioni di soglia.
• ✓Una sola persona ha coperto l’intera catena: sourcing hardware → backend → release Kubernetes → installazione sul campo.

Approccio

• >Scouting e selezione della sonda di temperatura e del fornitore hardware: valutazione di costi, affidabilità e aderenza ai requisiti di compliance.
• >Progettato il flusso di device management nel backend Java: registrazione dispositivi, auto-assegnazione al reparto responsabile, grant client-side, mock mode per lo sviluppo.
• >Logica di compliance sopra le letture: soglie, alert e registrazioni di non conformità che alimentano i flussi HACCP esistenti.
• >Rilasciato come release iot-compliance su EKS, osservabile via OpenTelemetry come ogni altro servizio.
• >Sonde installate e messe in servizio fisicamente in loco nei punti vendita.

Problema

I deploy erano manuali e il drift tra ambienti costante. Nessuno sapeva rispondere a "cosa gira esattamente in prod, e come ci è arrivato?"

Impatto

• ✓Owner di ~12 release Kubernetes in produzione sul cluster.
• ✓Un nuovo microservizio passa da repo a deploy prod-ready in un giorno, non in uno sprint.
• ✓Gli incident partono da trace e dashboard, non da ipotesi.

Approccio

• >Organizzazione AWS multi-account con Terraform: account management / audit / dev / staging / prod, CloudTrail centralizzato, IAM SSO, moduli riusabili per VPC, RDS, Redis, ECR ed EKS.
• >Un unico modulo Terraform riusabile eks-release-template: ogni servizio (auth, payments, copilot, IoT compliance, frontend...) deploya allo stesso modo, con External Secrets e AWS Load Balancer Controller.
• >Pipeline CI/CD tipizzate per classe di artefatto (Java, SPA, microfrontend, Python, migrazione DB) più ArgoCD per lo stato del cluster.
• >Osservabilità di default: auto-instrumentation OpenTelemetry su ogni servizio Java, trace e dashboard in SigNoz.

Problema

L’AI enterprise fallisce sulle parti noiose: PDF malformati, campi allucinati, controllo dei costi e integrazione con auth e dati esistenti.

Impatto

• ✓Documenti che prima richiedevano data entry manuale diventano record strutturati in automatico.
• ✓Il copilot risponde dentro il prodotto con contesto tenant-aware, non in una chat separata.
• ✓Lo sviluppo itera senza bruciare budget API grazie alla mock mode.

Approccio

• >Copilot: microservizio Spring Boot 3 / Java 17 con Spring AI, più frontend Next.js 15 + assistant-ui, integrato con l’identity provider OAuth della piattaforma.
• >Digitizer: pipeline NestJS + BullMQ che estrae JSON strutturato dai PDF con Claude, con fallback vision multimodale quando il layer testuale è inutilizzabile; retry/backoff e mock mode a costo zero per lo sviluppo.
• >Output strutturati validati contro schemi — il modello propone, il codice dispone.