Il CRM di HM Travel non è nato con lo stack che ha oggi. La prima versione era scritta in Flutter, con Firebase come backend — una scelta comune per costruire velocemente un'app multi-piattaforma. Ma un CRM per un'agenzia di viaggio non è un'app consumer: è uno strumento di lavoro usato tutto il giorno da reception, operatori e manager, dentro un browser, su schermi grandi, con liste lunghe di clienti, preventivi e appuntamenti da caricare e filtrare in continuazione.
Su questo terreno, Flutter Web ha mostrato i suoi limiti. Non è pensato per essere un framework web nativo: renderizza l'interfaccia a modo suo invece di usare gli strumenti standard del browser, e su un'applicazione data-intensive come un gestionale questo si traduce in caricamenti più lenti e un'esperienza meno reattiva rispetto a un sito web scritto per il web. Più cresceva il CRM, più questi limiti pesavano.
La decisione: riscrivere da zero
A febbraio abbiamo deciso di non incrementare, ma ripartire da zero. Tra febbraio e marzo il CRM è stato interamente riscritto: via Flutter e Firebase, dentro Next.js, TypeScript, PostgreSQL con Prisma come ORM, il tutto containerizzato con Docker. Uno stack pensato per il web fin dal principio, capace di sfruttare il rendering lato server per caricamenti rapidi anche con liste di migliaia di clienti e preventivi.
Cosa è cambiato da allora
Il beneficio non è stato solo di velocità. Il nuovo stack ha reso molto più semplice aggiungere funzionalità in modo continuo: nei mesi successivi alla riscrittura sono arrivati l'assistente AI "MyTrip", l'estrazione automatica dei dati dai documenti di viaggio, l'itinerario generato dall'intelligenza artificiale, l'app mobile nativa e i moduli di reportistica e lead tracking — tutte funzionalità costruite sopra alle solide fondamenta di un'architettura pensata per crescere, non per essere aggirata.
Ripartire da zero è stata una scelta rischiosa nel breve termine. A distanza di mesi, è quella che ha reso possibile tutto il resto.