Jetcost
Il metasearch voli e hotel del gruppo lastminute.com, su Android. Uno sviluppatore sul codice, 600K+ utenti attivi mensili.
In 30 secondi
Dal 2022 gestisco l'intero ciclo di sviluppo dell'app Android di Jetcost: 15 mercati, 5M+ download. La mantengo al 99,7% crash-free mentre la migro a Jetpack Compose, e il redesign del funnel che ho rilasciato ha più che raddoppiato il CTR core (+125%). Nel frattempo il rating sul Play Store è salito da ~3,8 a 4,3 stelle.
Contesto e problema
Jetcost confronta i prezzi di voli, hotel e noleggio auto tra centinaia di provider. L'app Android serve ~600K utenti attivi mensili (Firebase) in 15 mercati e 15 lingue: ogni regressione di stabilità o velocità ha un impatto diretto sul business.
Quando sono arrivato nel 2022 l'app era una classica codebase a View system con anni di storia: solida, ma datata. Il rating era intorno alle 3,8 stelle, lo stack UI rendeva lente le nuove feature e ogni release era un rituale manuale soggetto a errori. La sfida: modernizzare app e pipeline di delivery mentre tutto continua a girare a pieno traffico, con un solo sviluppatore sul codice.
Il mio ruolo
Gestisco l'intero ciclo di sviluppo: architettura, implementazione, test, release e gestione dello store. Le decisioni tecniche sono mie, condivise con l'Engineering Manager e gli stakeholder di prodotto; gli esperimenti sono decisioni di prodotto del team che implemento end to end su Android, sopra l'infrastruttura di A/B testing che mantengo nell'app. Parte del mio toolkit quotidiano è l'AI-assisted development con Claude Code, incluse skill custom che ho scritto per questo progetto, dall'analisi root-cause dei crash su Crashlytics ai pattern Compose.
Decisioni tecniche
Modernizzare un'app critica per i ricavi senza romperla
Quando sono arrivato la codebase era un'app a View system con anni di storia. Il mio istinto era modernizzare tutto: Kotlin, Flow, Compose, l'intero stack moderno. Il business aveva bisogno che i ricavi non tremassero: in un'app usata da milioni di persone, toccare una virgola nel punto sbagliato ha un costo. Il compromesso è diventato la strategia: migrare schermata per schermata (ComposeView dentro le schermate esistenti, nuove feature 100% Compose), ogni passo abbastanza piccolo da poter tornare indietro. Oggi ~60% delle schermate principali è migrato o parzialmente migrato, con zero incidenti in produzione legati alla migrazione.
Rendere la sperimentazione economica
Le idee di prodotto si validano con A/B test via Firebase Remote Config, tracciati su doppio backend analytics (GA4 più la pipeline in-house). Se rilasciare una variante costa poco, più idee vengono testate. La vittoria più grande: la rimozione della detail page dal funnel di ricerca, che ha portato il CTR core dal 19% al 44%.
L'out-of-memory che ha richiesto mesi di caccia
Un crash OOM ha perseguitato l'app per mesi: colpiva una fetta minima di utenti, in uno scenario così specifico che nessuno sviluppatore l'avrebbe mai riprodotto spontaneamente. Trovarlo ha richiesto caccia, non intuito: LeakCanary, il profiler di Android Studio e dump della memoria analizzati finché il leak non ha mostrato il suo percorso. Un crash-free del 99,7% è fatto esattamente di questa pazienza.
Da ~3,8 a 4,3 stelle, di proposito
Il rating non è salito da solo. Ha richiesto leggere recensioni e segnali del supporto per trovare i veri punti di frizione, sistemare prima quelli, ed essere deliberati sulla richiesta: il prompt di recensione in-app vive nei momenti in cui l'utente ha appena ottenuto valore, mai dove interrompe. Ogni iterazione è stata misurata sul rating stesso.
React Native brownfield, studiato da zero
Quando il gruppo ha scelto di condividere alcuni widget tra le piattaforme, React Native non lo conoscevo: l'ho studiato da zero e ho co-definito la strategia. E il brownfield è la variante difficile e poco comune: non un'app RN greenfield, ma superfici RN (form di ricerca, ricerche recenti) che vivono dentro un'app nativa esistente tramite un bridge custom. Nativo dove conta, condiviso dove fa risparmiare tempo.
Automatizzare il release train
Con Fastlane la pipeline gestisce versioning, firma, upload AAB, release notes e screenshot dello store per 15 lingue. Le release di produzione escono ogni due settimane, le build di test ogni settimana; una release costa ~10 minuti invece di ore.
Una codebase, tante agende
Prodotto, marketing, CRM e SEO fanno atterrare le loro esigenze sulla stessa app Android, attraverso un solo sviluppatore. Buona parte del lavoro è orchestrazione: capire cosa serve davvero a ogni team, opporsi con i dati quando qualcosa non sta in piedi, e mettere in sequenza il lavoro così che ogni team rilasci senza pestare i piedi agli altri.
La privacy come vincolo ingegneristico
Compliance GDPR con CMP certificata (Iubenda) e Google Consent Mode v2, integrata senza interrompere la continuità degli analytics su 15 mercati.
Risultati
- +125% CTR core dal redesign del funnel, +81% revenue core nei mercati pilota, ora in rollout
- ~3,8 → 4,3★ rating Play Store su 38K+ valutazioni
- 99,7% utenti crash-free, 0,03% ANR, ampiamente sotto le soglie Google
- ~10 min a release, prima erano ore, con cadenza quindicinale
- Deutscher App Award 2026, categoria comparatori di prezzi voli. Assegnato dal Deutsches Institut für Service-Qualität (DISQ) con ntv, sulla base di un sondaggio sui consumatori tra le app più popolari in Germania.
Cosa ho imparato
Le migrazioni incrementali battono i rewrite quando ci sono utenti reali in gioco: la strategia Compose ibrida ha modernizzato l’app senza una sola finestra di rischio "big bang". Automatizzare il release train ha liberato settimane vere ogni anno e reso i rilasci prevedibili.
A questa scala gli esperimenti battono le supposizioni: costruire l’app attorno alla misurabilità ha cambiato il modo in cui il team prende le decisioni di prodotto.