Caso studio · Logistica · Ultimo miglio · Mobile
Come abbiamo preso un'app Android legacy criticamente instabile — attiva presso un operatore logistico tedesco e che perdeva fatturato a causa di consegne fallite — l'abbiamo stabilizzata, effettuato il refactoring del suo core di routing e poi sviluppato la controparte iOS pronta per la pubblicazione. Ottimizzazione percorsi multi-punto, tracciamento autista in tempo reale, fatturazione in-app e pagamenti, consegnati per flotte di produzione in Germania e pronti a scalare nell'Unione Europea e negli Stati Uniti.
xRouten è un prodotto di navigazione e pianificazione percorsi per flotte aziendali, costruito e gestito in Germania. Quando il cliente ha contattato YuSMP, l'app Android esistente era attiva presso operatori logistici a pagamento ma soffriva di prestazioni scarse, frequenti errori e bug critici che interrompevano direttamente le operazioni aziendali — consegne fallite, finestre di ritiro mancate e perdite finanziarie reali per i clienti finali dell'operatore. Il team di prodotto aveva bisogno di due cose in un unico ingaggio: primo, un passaggio di stabilizzazione di emergenza sull'app Android in produzione per fermare il churn degli utenti e ripristinare la fiducia; secondo, una controparte iOS con piena parità di funzionalità in modo che l'operatore potesse espandere la sua flotta di autisti su hardware iPhone. Abbiamo accettato entrambi — refactoring legacy del codebase Android instabile in Kotlin, seguito da una build iOS da zero in Swift condividendo lo stesso backend — e abbiamo consegnato un prodotto pronto per la pubblicazione sia per Google Play che per l'App Store di Apple, attivo con un operatore logistico tedesco e pronto a scalare nei mercati più ampi dell'Unione Europea e degli Stati Uniti.
Una panoramica di quanto ha prodotto l'ingaggio xRouten tra refactoring Android e nuova build iOS.
La superficie più critica per il business in xRouten è il costruttore di percorsi. Un dispatcher o un autista fornisce all'app un elenco di fermate — a volte una manciata, spesso decine — e l'app deve restituire una sequenza ottimizzata in un tempo abbastanza breve da sembrare istantaneo. Nella build legacy, questo calcolo era inaffidabile: i percorsi non riuscivano a calcolarsi, andavano in timeout o restituivano sequenze ovviamente non ottimali che sprecavano ore di lavoro degli autisti e bruciavano carburante. Abbiamo riscritto il core di routing rispetto all'API matrix di un SDK di mappatura: il client invia l'elenco delle fermate a un ottimizzatore lato server che recupera distanza e ETA tra ogni coppia, esegue un'euristica 2-opt sulla matrice risultante e restituisce una sequenza di fermate quasi ottimale con indicazioni turn-by-turn per ogni tratto.
Il client mobile renderizza il percorso, supporta la ri-ottimizzazione incrementale quando le fermate vengono aggiunte a metà turno o contrassegnate come completate, e mette in cache la matrice per percorso in modo che una singola consegna completata non attivi un ricalcolo completo. Il risultato è un costruttore di percorsi che restituisce un calcolo istantaneo dei percorsi ottimali tra decine di fermate — esattamente il comportamento percepito dall'utente che il cliente aveva richiesto fin dall'inizio del rapporto. La stessa architettura viene riutilizzata nella build iOS senza modifiche al backend: l'ottimizzatore è agnostico rispetto alla piattaforma e i client mobile sono renderer leggeri su uno stack condiviso di sviluppo software su misura.
| Dimensione | Build legacy (pre-ingaggio) | Build refactored (post-ingaggio) |
|---|---|---|
| Calcolo percorso multi-punto | Timeout e sequenze ovviamente non ottimali | Calcolo istantaneo su API matrix + risolutore 2-opt |
| Tracciamento posizione autista | Aggiornamenti sporadici, marker sulla mappa con scatti | Streaming in tempo reale fluido con campionamento adattivo |
| Fattura e pagamento | Soluzione alternativa fuori dall'app — gli autisti usavano strumenti esterni | Generazione fatture in-app + sistema di pagamento funzionante |
| Errori critici in produzione | Multipli — causa di consegne fallite e perdita di fatturato | Eliminati nel refactoring |
| Interfaccia utente e percezione del brand | Datata; reclami degli utenti visibili nelle recensioni dello store | Interfaccia moderna ridisegnata che migliora l'UX |
| Disponibilità iOS | Nessuna — solo Android | Build Swift pronta per la pubblicazione con parità di funzionalità |
Riferimenti di piattaforma: Kotlin, Swift, Android Foreground Services, Apple CoreLocation.
La seconda funzionalità principale era il streaming affidabile della posizione in tempo reale per gli autisti dell'operatore, renderizzato in modo fluido su una mappa del dispatcher senza gli scatti e le lacune che affliggevano la build legacy. Su Android ci affidiamo a un servizio Kotlin in primo piano per mantenere attivo il campionamento GPS attraverso la modalità Doze e gli aggressivi ottimizzatori della batteria presenti sui dispositivi Samsung, Xiaomi, OnePlus e Pixel — senza di esso, gli aggiornamenti della posizione si interrompono entro pochi minuti dallo spegnimento dello schermo. Su iOS la superficie equivalente utilizza CoreLocation con l'appropriata autorizzazione per la posizione in background, abbinata al monitoraggio dei cambiamenti significativi come fallback efficiente per la batteria.
Il campionamento è adattivo: a basse velocità nel denso traffico urbano le coordinate del conducente si aggiornano ogni cinque-dieci secondi; sull'autobahn tra le città tedesche la frequenza di campionamento si dilata, perché il dispatcher non ha bisogno di precisione a 1 Hz quando un veicolo si muove in linea retta a 120 km/h. La vista del dispatcher interpola tra i campioni in modo che il marker scivoli invece di saltare, rendendo una frequenza di campionamento grossolana percepita fluida dall'operatore. Gli aggiornamenti della posizione vengono trasmessi in streaming su un WebSocket persistente — la stessa scelta di trasporto utilizzata per la chat nel nostro lavoro di sviluppo di app mobile consumer — in modo che una breve interruzione della connettività (passaggio del gestore tra LTE e 5G, comune sui percorsi a lunga distanza tedeschi) si recupera in meno di due secondi senza perdere l'ultima posizione nota.
Il terzo pilastro del refactoring è stato un modulo di documentazione digitale: al momento della consegna, il conducente genera una fattura per il cliente direttamente dall'app, la invia dalla stessa schermata e riscuote il pagamento senza uscire dal flusso di lavoro. Nel prodotto legacy, i conducenti avevano trovato soluzioni alternative a questa lacuna usando carta o app non correlate — una traccia documentale che violava le aspettative di conformità tedesche e rallentava ogni consegna. Il nuovo modulo produce una fattura strutturata (PDF per il cliente, dati strutturati per il back office dell'operatore), allega la prova di consegna e instrada il pagamento attraverso un gateway di pagamento integrato — non l'acquisto in-app dell'App Store, che Apple esclude esplicitamente per beni fisici e servizi.
L'affidabilità deriva da un commit a due fasi tra l'emissione della fattura e l'intento di pagamento: un'interruzione di rete sul campo non può risultare in un addebito senza una fattura corrispondente, e non può risultare in una fattura senza un esito di pagamento registrato. Il flusso accetta una cattura riuscita, una cattura differita (il conducente è in un seminterrato e offline — la fattura viene messa in coda per la sincronizzazione alla prossima connessione) e un errore definitivo (carta rifiutata — il conducente vede un errore inline e può accettare un pagamento alternativo nella stessa schermata). Il risultato è il sistema di pagamento funzionante che il cliente aveva richiesto fin dall'inizio, con un'affidabilità delle transazioni che corrisponde a quanto i clienti dell'operatore si aspettano da qualsiasi moderno servizio tedesco dell'ultimo miglio.
Postura di conformità: allineato GDPR · pronto ISO 27001 · SOC 2 Type II in corso · HIPAA-capable · CCPA-acknowledged.
Tre caratteristiche del progetto hanno reso xRouten un ingaggio non banale e hanno plasmato il modo in cui abbiamo gestito il lavoro. Primo, il codebase era un prodotto legacy con una superficie esistente instabile — non stavamo partendo da zero su uno spazio vuoto, stavamo stabilizzando un sistema in esecuzione da cui dipendevano veri autisti. Ciò significava che ogni modifica doveva essere difendibile nei confronti della base utenti esistente: refactoring a strati, bloccare i nuovi percorsi di codice dietro feature flag, rilasciare versioni intermedie che ritiravano incrementalmente le peggiori classi di bug piuttosto che una singola grande riscrittura che avrebbe bloccato gli operatori su una build difettosa per settimane.
Secondo, la posta in gioco era alta in un modo che le app consumer raramente sono: un errore dell'app non produceva una brutta esperienza utente, produceva una consegna fallita e una perdita finanziaria reale per il cliente finale dell'operatore. Quella asimmetria ci ha spinto verso un'ingegneria difensiva — stati di errore espliciti visualizzati al conducente, tentativi con backoff esponenziale per qualsiasi operazione di rete che mutava lo stato e comportamento offline-first per le superfici sul campo in modo che un'interruzione della connettività non perdesse mai silenziosamente il lavoro.
Terzo, c'erano barriere linguistiche e geografiche: l'intera interfaccia del prodotto e la documentazione sono in tedesco, e la validazione dello strato di routing richiedeva test su mappe tedesche e convenzioni di indirizzi tedeschi da parte di un team di ingegneria basato in Russia. Abbiamo trattato questo come una disciplina ingegneristica piuttosto che come un problema — revisione da parte di madrelingua tedesca su ogni stringa dell'interfaccia, fixture di indirizzi tedeschi nella suite di test di routing e una matrice di QA che esercitava l'app rispetto ai pattern reali di ritiro Deutsche Post e DHL piuttosto che dati di test sintetici. Quella disciplina è la stessa che applichiamo quando gestiamo un team di sviluppo dedicato per qualsiasi cliente USA o UE in cui il mercato operativo non è la lingua principale del team di ingegneria.
Un ingaggio in cinque fasi che ha portato xRouten da un prodotto Android live instabile a una coppia iOS e Android pronta per la pubblicazione.
Audit del codebase Android legacy, inventario dei bug critici, priorizzazione per impatto sul business (consegne fallite prima), rilasci di hotfix per fermare il churn degli utenti mentre il refactoring più profondo viene definito.
Riscrittura del costruttore di percorsi multi-punto in Kotlin rispetto all'API matrix di un SDK di mappatura con un'euristica 2-opt, suite di regressione su fixture di indirizzi tedeschi reali, rollout incrementale dietro un feature flag.
Streaming della posizione in tempo reale basato su servizi in primo piano, interpolazione fluida lato dispatcher, generatore di fatture in-app e integrazione gateway di pagamento con semantica di commit a due fasi.
Interfaccia moderna ridisegnata applicata a entrambe le piattaforme, client iOS Swift costruito rispetto allo stesso backend con parità di funzionalità per routing, tracciamento, fatturazione e pagamenti.
Rilascio su Google Play dell'app Android refactored, build iOS pronta per la pubblicazione per la sottomissione all'App Store, passaggio di QA in lingua tedesca, runbook e handover on-call al cliente.
Alla fine dell'ingaggio, il prodotto xRouten era passato da un'app Android instabile che generava escalation di supporto a una versione pronta per la produzione sia per l'App Store che per Google Play. Gli errori critici che stavano causando consegne fallite nella versione legacy sono stati eliminati; l'interfaccia moderna ridisegnata ha migliorato sia l'esperienza utente che la percezione del brand per gli autisti e i clienti dell'operatore; il sistema di pagamento in-app ha fornito un'affidabilità delle transazioni che la build precedente semplicemente non offriva; e l'architettura refactored è strutturata in modo che il team di prodotto dell'operatore possa aggiungere nuove funzionalità — metodi di pagamento aggiuntivi, analytics a livello di flotta, supporto multi-tenant per subappaltatori — senza ereditare il debito tecnico della build originale. Lo stesso backend condiviso serve sia il refactoring Android che la nuova build iOS, quindi un'unica roadmap di prodotto guida entrambe le piattaforme in futuro.
xRouten è attivo con un operatore logistico dell'ultimo miglio tedesco ed è costruito sulla stessa postura ingegneristica che utilizziamo nel nostro lavoro per i clienti negli Stati Uniti e nell'Unione Europea. L'app è tedesca come prima lingua oggi — interfaccia in tedesco, documentazione in lingua tedesca, validata rispetto a indirizzi, reti stradali e pattern di consegna tedeschi — ma l'architettura è agnostica rispetto alla regione. L'astrazione dell'SDK di mappatura supporta le reti stradali e i formati di indirizzi USA senza modifiche al codice, l'integrazione del gateway di pagamento può scambiare processori regionali per mercato e gli stack del servizio in primo piano e di CoreLocation si comportano in modo identico su dispositivi rilasciati negli USA e nell'UE.
La postura in materia di privacy rispecchia il resto del nostro portafoglio: l'app è allineata al GDPR per gli utenti europei — rilevante immediatamente in Germania, Francia, Paesi Bassi, Irlanda e Svezia — e pronta a soddisfare il patchwork di privacy degli stati USA: CCPA / CPRA in California, VCDPA in Virginia, CPA in Colorado, CTDPA in Connecticut, UCPA nello Utah, TDPSA in Texas e Oregon CPA. I dati di posizione degli autisti sono la superficie più sensibile in un'app logistica — sono, per definizione, dati di monitoraggio dei dipendenti — e l'architettura separa i flussi di posizione dall'identità a livello di storage, con finestre di conservazione configurabili per operatore per corrispondere alle aspettative del Consiglio di fabbrica tedesco che regolano questa categoria di dati nell'UE.
La roadmap per xRouten estende la base refactored nelle direzioni che l'operatore non poteva tentare in sicurezza sulla build legacy: analytics a livello di flotta (produttività degli autisti, costo del percorso per consegna, varianza di carburante e tempo rispetto al piano ottimizzato), supporto multi-tenant in modo che i corrieri subappaltati possano gestire i propri pool di autisti all'interno dell'account dell'operatore, metodi di pagamento regionali aggiuntivi (addebito diretto SEPA, Klarna, Apple Pay e Google Pay) e una console web lato dispatcher che rispecchia il modello di dati dell'app mobile. I piani infrastrutturali includono un SLO più rigido sull'ottimizzatore di routing (risposta inferiore al secondo per percorsi fino a 50 fermate) e impegni di residenza dei dati UE supportati da partizioni del database ancorate per regione per soddisfare le aspettative di privacy dell'operatore tedesco in virtù del GDPR.
Un passaggio di stabilizzazione legacy focalizzato su un'app Android — eliminazione degli errori critici, refactoring del core di routing e rilascio di una versione pronta per la produzione — costa tipicamente tra 80.000 e 180.000 USD a seconda delle dimensioni del codebase e della copertura dei test. La costruzione di una controparte iOS con parità di funzionalità (routing multi-punto, tracciamento in tempo reale, fatturazione, pagamenti) su un backend condiviso aggiunge solitamente tra 120.000 e 250.000 USD. I fattori di costo includono la scelta dell'SDK per la mappatura, le integrazioni con il gateway di pagamento e lo sforzo di QA necessario per validare l'ottimizzazione dei percorsi rispetto a indirizzi tedeschi reali e dati sul traffico.
L'ottimizzazione di percorsi multi-punto su mobile è una variante del Problema del Commesso Viaggiatore. Per flotte aziendali con decine di fermate per percorso, il calcolo viene eseguito lato server rispetto all'API matrix di un provider di mappatura (distanza e ETA tra ogni coppia di fermate), con un risolutore euristico — tipicamente una variante 2-opt o Lin–Kernighan — che trova una sequenza quasi ottimale in millisecondi. Il client mobile renderizza il risultato e gestisce la ri-ottimizzazione incrementale quando le fermate vengono aggiunte, rimosse o completate sul campo. La cache della matrice per percorso e la re-query solo delle coppie modificate mantiene bassi i tempi di risposta anche quando gli autisti avanzano nelle consegne.
Il tracciamento degli autisti in tempo reale in produzione ha tre componenti: un servizio in primo piano su Android (e un'autorizzazione per la posizione in background su iOS) che mantiene attivo il campionamento GPS attraverso la modalità standby del dispositivo e gli ottimizzatori della batteria; un livello di trasporto — WebSocket o MQTT — che trasmette gli aggiornamenti della posizione a un backend con latenza inferiore al secondo; e una vista del dispatcher che interpola tra i campioni per renderizzare un movimento fluido su una mappa senza scatti. La batteria è il vincolo dominante: il campionamento a 1 Hz scarica velocemente un telefono, quindi una build reale campiona in modo adattivo a intervalli di 5-30 secondi a seconda della velocità e della geometria del percorso.
La fatturazione in-app per un flusso di lavoro logistico genera un documento fattura strutturato (PDF o dati in stile XRechnung tedesco conforme) al momento della consegna, allega la firma del conducente e la prova di consegna, e lo invia al cliente tramite email o link in-app. Il pagamento viene tipicamente gestito da un gateway di pagamento separato (Stripe, Adyen o un processore per il mercato tedesco) piuttosto che dall'acquisto in-app dell'App Store, perché i beni pagati sono consegne fisiche, non contenuti digitali — le regole IAP dell'App Store escludono esplicitamente questa categoria. L'affidabilità deriva da un commit a due fasi tra l'emissione della fattura e l'intento di pagamento, in modo che un'interruzione di rete sul campo non possa creare un addebito senza un record di fattura corrispondente.
Un passaggio di stabilizzazione Android legacy — controllo dei bug critici, refactoring del core di routing e rilascio di una versione corretta su Google Play — richiede tipicamente da 10 a 16 settimane per un'app delle dimensioni di xRouten. La costruzione della controparte iOS con piena parità di funzionalità, inclusi i flussi di fatturazione e pagamento, aggiunge da 14 a 20 settimane. I rischi dominanti per il calendario sono l'allineamento delle licenze dell'SDK di mappatura, il QA per il mercato tedesco (test dei percorsi rispetto ai pattern reali di ritiro Deutsche Post e DHL) e i cicli di revisione dell'App Store / Google Play quando un'app precedentemente instabile rientra nello store con autorizzazioni sostanzialmente modificate.
Se operate un prodotto logistico per flotte o ultimo miglio — ovunque negli Stati Uniti, nell'Unione Europea o in un mercato come la Germania dove la conformità e le sfumature linguistiche contano — e state valutando un refactoring legacy, un'estensione iOS o Android o una nuova build, abbiamo consegnato questo stack end-to-end per un operatore tedesco live e possiamo comprimere significativamente i tempi di build. Il team di ingegneria dietro xRouten fa parte di YuSMP Group. Lavoriamo a prezzo fisso per refactoring ben definiti e con team di sviluppo dedicati per la consegna continuativa, con un orario CET e una finestra garantita di sovrapposizione con la Costa Est USA (9:00–13:00 ET) per stand-up, demo e risposta agli incidenti.
Postura di conformità: allineato GDPR · pronto ISO 27001 · SOC 2 Type II in corso · HIPAA-capable · CCPA-acknowledged.
Servizi correlati
App iOS, Android e cross-platform dal concept all'App Store con uno standard di qualità da App Store.
Scopri lo sviluppo di app mobile →
Migrazioni AWS, Azure e GCP, piattaforme Kubernetes, CI/CD e osservabilità per team USA & UE.
Scopri Cloud & DevOps →
Ingegneria del prodotto end-to-end per ambiziose aziende USA & UE, realizzata da team senior con pratiche allineate GDPR e orientate a SOC 2.
Scopri lo sviluppo software su misura →Casi correlati
Piattaforma social nativa iOS + Android con geo-radar discovery, chat in tempo reale e un'economia di monete virtuali — App Store + Google Play, USA & UE.
Vedi il caso →
Piattaforma web dealer con sincronizzazione CRM Bitrix24, pre-compilazione Dadata e avvisi vocali in tempo reale — canale unico per ogni richiesta di finanziamento auto.
Vedi il caso →
VPN nativa iOS + Android con WireGuard, backend no-logs, split tunnel e lancio su App Store + Google Play per USA & UE.
Vedi il caso →
Piattaforme enterprise con architettura al primo posto, conformità audit-ready e integrazione con SAP, Salesforce, Workday, Okta.
Scopri di più →
Migrazione strangler-fig di stack legacy (.NET Framework, Java 8, monolite) senza rischi di rip-and-replace.
Scopri di più →Piattaforme AWS, Azure, GCP con IaC, osservabilità e deploy zero-downtime.
Scopri di più →Condividete alcuni dettagli e un consulente senior risponderà entro un giorno lavorativo.