Indice
Nel mondo della tecnologia esistono due approcci diametralmente opposti allo sviluppo di una piattaforma digitale: da un lato la manutenzione di sistemi legacy, spesso rigidi e stratificati, dall’altro la possibilità (e la responsabilità) di costruire tutto da zero, in puro stile greenfield.
Fabio Steffenino, oggi CTO di Moov, ha vissuto entrambe le esperienze. Dopo un solido percorso internazionale che lo ha visto in aziende come Amadeus, Aon e Illimity, oggi guida la costruzione di una piattaforma assicurativa per la mobilità che parte da una tela bianca: il servizio Flee, con cui Moov punta a trasformare il mercato del noleggio a lungo termine e dell’assicurazione pay-per-use. Lo fa con un team giovane, un progetto ambizioso e una roadmap che attraversa no code, serverless e approcci event-driven.
Questa conversazione con Fabio non è solo una testimonianza su come si lancia una startup tech. È una lezione concreta su cosa significa davvero guidare una trasformazione tecnologica: nel codice, nei processi e nella mentalità.
Costruire da zero: opportunità o ansia da prestazione?
L’esperienza di Moov parte da un contesto paradossalmente già rodato. Il team di fondatori ha infatti iniziato a sviluppare il progetto all’interno di Aon, per poi “staccarlo” e rifondarlo in una struttura indipendente. Una sorta di spin-off con capitali ed energia da startup, ma con conoscenza pregressa del dominio.
Ed è proprio qui che iniziano le sfide.
Non si tratta solo di riscrivere codice, ma di ridefinire il modello di servizio, i workflow e le priorità. Con tutto il fascino e la pressione che il greenfield comporta: si ha carta bianca, ma nessun paracadute. Come ammette Fabio, “le prime settimane sono piene di entusiasmo… e di paure”. Paure legittime: ogni scelta tecnologica sbagliata può costare tempo, risorse e vantaggio competitivo.
No code come acceleratore, non come panacea
Uno dei passaggi più interessanti della strategia di Moov è l’utilizzo mirato del no code e low code per ridurre il time-to-market. Non come soluzione definitiva, ma come leva temporanea per prototipare, validare e lanciare processi anche complessi con rapidità.
Workflow costruiti con Make, Airtable, Retool, n8n e Zapier hanno permesso al team di uscire in fretta con le prime funzionalità, testare onboarding, lead generation, fatturazione e gestione dei dati telematici — in attesa della versione custom più scalabile.
Un approccio lucido: il no code non è l’obiettivo, è un mezzo. Una strategia di “prodotto tecnologico” che separa ciò che è core da ciò che è supportivo. Per il core si sviluppa, per il resto si orchestra.
L’importanza della documentazione anche quando il codice non c’è
Troppo spesso, nel correre verso l’MVP, ci si dimentica che l’accumulo di automazioni no code senza una buona documentazione produce un effetto collaterale pericoloso: l’incomprensibilità.
Fabio sottolinea come l’adozione di tool come Notion, Event Catalog e Cloud Catalog sia stata essenziale per mantenere visibilità, tracciabilità e ordine anche in assenza di un vero e proprio repository di codice. La parola chiave è disciplina: ogni flusso, ogni entità, ogni evento è documentato. Non per burocrazia, ma per garantire che il sistema resti manutenibile nel tempo.
Da grandi aziende a startup: leadership in contesti radicalmente diversi
Una parte fondamentale della chiacchierata riguarda il cambiamento di mentalità necessario per chi si sposta da una realtà enterprise a una startup. Fabio ha vissuto questo shift sulla propria pelle passando da strutture come Amadeus (oltre 30.000 dipendenti) a team molto più snelli.
Il passaggio non è solo metodologico (scrum vs safe, agile vs freestyle), ma soprattutto culturale. In una grande azienda si seguono processi stabiliti, si lavora all’interno di schemi già definiti. In una startup bisogna decidere tutto: che processi usare, quando cambiare direzione, chi coinvolgere e come costruire il team.
Qui emerge il vero ruolo di un tech leader: non essere il più esperto di tutto, ma creare il contesto in cui il team può funzionare. Non imporre, ma facilitare. Come un allenatore che costruisce la squadra, non come un giocatore in campo.
Le esperienze internazionali come palestra di adattabilità
Un altro spunto prezioso arriva dall’esperienza internazionale di Fabio, che ha lavorato tra Francia, India e Stati Uniti. Esperienze che gli hanno insegnato a non imporre il proprio metodo, ma a costruire un linguaggio comune, valorizzare le differenze e adattare il proprio stile di leadership a contesti culturali diversi.
Questa “apertura mentale” è una soft skill cruciale per chi guida team tech oggi. Non solo per ragioni etiche o umane, ma perché la complessità dei sistemi — e delle persone — richiede un approccio che non può essere solo tecnico.
Tecnologia, ma con un’anima: il lato umano di Moov
L’ultimo elemento che rende unica l’esperienza raccontata da Fabio è l’iniziativa di impatto sociale portata avanti da Moov. L’azienda collabora con l’associazione HILL per offrire mobilità gratuita ai bambini malati e alle loro famiglie attraverso il progetto “Taxi solidale”.
Due auto del servizio Flee vengono messe gratuitamente a disposizione, e ogni tot chilometri percorsi dai clienti vengono “convertiti” in chilometri donati. Un approccio concreto al tema della responsabilità sociale, che va oltre le dichiarazioni e diventa parte integrante del modello di business.
Un reminder che anche nel tech si può — e si deve — costruire con uno scopo.
Progettare prima di scrivere
La chiusura di questa storia non riguarda il codice, né la velocità, né l’architettura. Il vero filo conduttore dell’approccio di Moov è uno: la progettazione consapevole.
Che si tratti di scegliere tra serverless e monolite, tra make e sviluppo custom, tra agile e kanban, ciò che fa la differenza è capire prima cosa si vuole costruire. Avere un’idea chiara di cosa è davvero distintivo, e usare ogni strumento in funzione di quel fine.
E, come ha ricordato Fabio, anche un semplice libro per bambini può insegnarlo: “La coccinella e la balena” è la metafora perfetta di chi esce dalla propria roccia per esplorare nuovi orizzonti.
Il vero CTO non è chi scrive il miglior codice, ma chi sa guidare quel viaggio.
