In una insurtech come Prima, il software non è solo un supporto al business, ma è il cuore del servizio. Ogni preventivo, pagamento o aggiornamento di polizza è un “evento digitale” che deve essere elaborato in tempo reale da piattaforme affidabili, scalabili e sempre disponibili. Per questo, sviluppare software in questo contesto significa adottare processi da software company: cicli di rilascio frequenti, automazione, monitoraggio costante e capacità di reagire rapidamente agli imprevisti.
L’obiettivo non è solo scrivere codice, ma costruire sistemi che funzionino 24 ore su 24, gestiscano alti picchi di traffico e rispettino sempre tutte le normative sulla protezione dei dati. È un approccio che richiede un equilibrio fra velocità di sviluppo e affidabilità, tra sperimentazione e controllo.
Insurtech, il linguaggio da scegliere? Dipende dal problema
Nel settore assicurativo, un errore tecnico o una perdita di dati non è soltanto un bug: può generare danni economici e di reputazione, che incidono anche direttamente sulla fiducia. Secondo il report IBM Cost of a Data Breach 2025, una violazione ha un costo medio globale di 4,4 milioni di dollari – con un impatto anche maggiore proprio nei comparti finanziario e assicurativo. Questo spiega perché la tecnologia non viene scelta perché “più nuova” o “di tendenza”, ma come risposta più efficace a requisiti precisi: garantire consistenza delle informazioni, tempi di risposta stabili e sistemi che possano essere aggiornati senza interrompere il servizio.
Da qui la necessità per una insurtech di progettare architetture distribuite, di scomporre il software in componenti indipendenti (microservizi) e di scegliere i linguaggi in base al tipo di problema. Elixir, basato sulla virtual machine BEAM, che è la stessa sottostante ad Erlang, è nato per gestire sistemi telco con milioni di processi concorrenti: oggi permette anche a noi di Prima di gestire con affidabilità flussi di notifiche, calcoli di premio o aggiornamenti di polizza in tempo reale.
Rust, invece, viene adottato dove servono performance e sicurezza della memoria. Il suo modello di ownership — un controllo esplicito su come i dati vengono allocati e liberati — riduce una categoria di errori difficili da individuare nei linguaggi tradizionali. Per fare un esempio: Google ha misurato che l’introduzione di Rust nello sviluppo di Android ha ridotto le vulnerabilità legate alla memoria dal 76% nel 2019 al 24% nel 2024, e i rollback di codice sono stati meno della metà rispetto a componenti equivalenti in C++. Anche in Prima lo utilizziamo così: non per riscrivere tutto, ma per rafforzare parti critiche delle pipeline di eventi assicurativi, dove stabilità e tempi di elaborazione sono determinanti.
Il metodo conta più del linguaggio: ridurre il rischio rende possibile l’innovazione
Strumenti e linguaggi sono importanti per una insurtech, ma non bastano. Ciò che garantisce qualità e continuità nel tempo è soprattutto il metodo con cui il software viene progettato, scritto e mantenuto. Ogni nuova funzione passa attraverso code review sistematiche, in cui il codice viene letto da più persone per individuare errori, migliorare la chiarezza e condividere conoscenza all’interno del team.
I test automatici — unitari, di integrazione e, quando serve, test end-to-end — permettono di intercettare eventuali regressioni prima che raggiungano l’utente finale. A questo si aggiunge l’osservabilità, ovvero la capacità di sapere in ogni momento cosa sta accadendo nel sistema: metriche, log e sistemi di alert consentono di capire rapidamente se qualcosa non funziona come previsto. Infine, l’uso di feature flag (interruttori che consentono di attivare o disattivare parti di codice già distribuite) permette di rilasciare in modo sicuro, testando le novità su gruppi limitati di utenti prima di estenderle a tutti. Questo approccio diventa un metodo per ridurre il rischio, accelerare il cambiamento e rendere possibile innovare senza compromettere l’affidabilità.
In sintesi, sviluppare software in un’insurtech innovativa significa progettare sistemi che funzionino sempre, resistano al costante aumento di complessità e possano crescere senza perdere stabilità. Rust, Elixir e le altre tecnologie che utilizziamo non sono un fine, ma la conseguenza di un principio più semplice: scegliere ciò che serve per risolvere problemi reali.
Come ho recentemente spiegato anche nel corso del mio intervento al Lambda World 2025, è questo l’approccio che adottiamo ogni giorno in Prima: non “innamorarsi” delle tecnologie, ma usarla con rigore per costruire servizi solidi, veloci e degni della fiducia di chi li utilizza.
