Discovery e audit dei difetti
Catalogazione dei bug critici del legacy, mappatura del percorso di pagamento difettoso, definizione del catalogo e dei dati di fedeltà da portare avanti, e impostazione della postura GDPR + CCPA per i mercati US e UE.
Caso studio · Ristorante · Ordinazione Cibo
Vilka-Lozhka — app di ordinazione per catena di ristoranti su iOS e Android
Come abbiamo rifatto da zero le app mobile per una catena di ristoranti fast casual — client iOS e Android nativi su un backend Laravel pulito, un catalogo combo, un carrello in tempo reale, un percorso stabile di acquiring con carta e pagamenti ricorrenti, un saldo fedeltà e lo scheduling dell'orario di ritiro — rilasciati su App Store e Google Play e progettati per servire il pubblico negli Stati Uniti e nell'Unione Europea con conformità a GDPR e CCPA.
Il brief — un'app di ordinazione per ristoranti che accetti davvero i pagamenti
Il team di prodotto di Vilka-Lozhka si è rivolto a YuSMP Group con una coppia di app mobile che aveva smesso di fare la cosa che un'app di ordinazione cibo deve fare in modo affidabile: incassare i pagamenti. Il codice legacy aveva accumulato bug critici, e l'integrazione dei pagamenti — che si basava su un cablaggio difettoso di Apple Pay e Google Pay — falliva abbastanza spesso da spingere i clienti ad abbandonare gli ordini al checkout. La catena aveva bisogno di una riprogettazione completa e di una ricostruzione funzionale, non di una correzione: eliminare i difetti ereditati, sostituire il percorso di pagamento con un flusso stabile di acquiring con carta che supporti sia addebiti una tantum sia ricorrenti, e rinnovare l'interfaccia affinché le app potessero superare la revisione di App Store e Google Play e sembrare attuali rispetto ai concorrenti orientati alla consegna. La build doveva servire gli acquirenti negli Stati Uniti e nell'Unione Europea da un'unica codebase, con la postura di privacy e le informative che il pubblico in US e UE si aspetta ormai da qualsiasi app che conservi un token di carta e un'identità fedeltà. Lo abbiamo trattato come una riscrittura greenfield del dominio degli ordini e dei pagamenti — un backend Laravel e React pulito, Swift nativo su iOS e Kotlin su Android — portando avanti intatto il catalogo menu e i dati di fedeltà.
Punti salienti del progetto
Rifacimento nativo iOS & Android
Backend Laravel + React
Catalogo combo con pranzi fissi
Matematica del carrello in tempo reale
Acquiring con carta + pagamenti ricorrenti
Saldo fedeltà e riscatto
Scheduling dell'orario di ritiro
App Store + Google Play attivi · US & UE
I numeri
Una panoramica di quanto il rifacimento di Vilka-Lozhka ha realizzato su iOS, Android e un backend di ordinazione pulito nel primo ciclo di produzione.
2piattaforme native — iOS in Swift e Android in Kotlin, client separati su un unico backend Laravel
2modalità di pagamento — addebiti una tantum con carta e pagamenti ricorrenti tokenizzati tramite un unico provider di acquiring
0numeri di carta memorizzati nei nostri sistemi — l'acquiring restituisce un token opaco, mai il PAN
~40 mintipica finestra dall'ordine al ritiro mostrata in-app affinché i clienti pianifichino un orario di ritiro realistico
2store attivi — Apple App Store e Google Play negli store US e UE
10–16 settfinestra di consegna tipica per un MVP comparabile di ordinazione ristorante su entrambi gli store
Perché un rifacimento nativo invece di una correzione o di un SDK di ordinazione white-label
La decisione che ha dominato questo progetto è stata costruire-versus-correggere. Le app legacy presentavano due classi di difetti particolarmente pericolosi da correggere in modo incrementale: cablaggio dei pagamenti rotto e aritmetica del carrello inaffidabile. Entrambi si trovano sul percorso del denaro, dove una correzione imprudente può addebitare doppiamente un cliente o perdere un ordine, quindi inseguire le regressioni nel codice accumulato è più lento e rischioso di una riscrittura disciplinata del dominio degli ordini e dei pagamenti. Abbiamo anche valutato gli SDK di ordinazione white-label per ristoranti e li abbiamo scartati: i loro flussi di checkout non potevano ospitare le regole di fedeltà esistenti della catena, le loro opzioni di acquiring non includevano il percorso di pagamento ricorrente di cui l'azienda aveva bisogno, e i loro bundle gonfiavano l'IPA e l'APK oltre le soglie che l'App Store applica per le installazioni in modalità cellulare.
Scegliere il nativo su uno stack pulito di sviluppo di app mobile — Swift su iOS, Kotlin su Android, un backend Laravel e React — ci ha consentito di portare avanti il catalogo menu e i dati di fedeltà riscrivendo tutto ciò che riguarda pagamenti, stato del carrello e stato dell'ordine. Il confronto di seguito è la logica che abbiamo illustrato al cliente prima di impegnarci nel rifacimento.
| Dimensione | Rifacimento nativo (Vilka-Lozhka) | Correzione codice legacy | SDK white-label |
|---|---|---|---|
| Stabilità del percorso di pagamento | Riscritto su un provider di acquiring con idempotenza | Cablaggio Apple/Google Pay rotto ereditato | Fisso dal fornitore; ricorrente spesso non disponibile |
| Pagamenti ricorrenti | Tokenizzati, supportati dal primo giorno | Non presenti; difficili da aggiungere in modo sicuro | Dipende dal fornitore; raramente flessibile |
| Regole di fedeltà | Registro personalizzato, regole della catena conservate | Contatori fragili soggetti a corruzione | Modello fedeltà del fornitore, non della catena |
| Dimensione del bundle app | Binari nativi snelli per piattaforma | Porta codice morto e dipendenze obsolete | Gonfiamento SDK oltre i limiti di installazione in rete cellulare |
| Rischio di approvazione store | Informative sulla privacy pulite, UI rinnovata | I rifiuti legacy probabilmente persisteranno | I rifiuti dell'SDK condiviso colpiscono tutti i client |
| Migrazione del catalogo e dei dati | Menu + fedeltà portati avanti intatti | Bloccati nel vecchio schema | Da rimodellare nello schema del fornitore |
| Proprietà a lungo termine | Il cliente possiede sorgente completo e roadmap | Possiede codice fragile, il debito cresce | Vincolato ai prezzi e alla roadmap del fornitore |
Riferimenti di piattaforma: Documentazione Apple StoreKit e pagamenti in-app, Riferimento Google Play Billing, PCI Security Standards Council.
Build iOS — Swift, onboarding tramite telefono e il catalogo combo
Il client iOS è costruito in Swift, e la prima cosa che abbiamo semplificato è stata il flusso di registrazione. Le app legacy chiedevano troppe informazioni prima che il cliente potesse vedere un prezzo; il flusso rifatto si apre su un singolo campo per il numero di telefono con tastiera numerica e un consenso all'accordo utente inline, così un nuovo acquirente è a un codice SMS dal poter navigare. Da lì il catalogo propone in primo piano i combo del pranzo fisso della catena — gli articoli con il margine più alto e la rotazione più rapida — seguiti da insalate, piatti di pesce, zuppe e contorni, ciascuno con miniatura, prezzo e uno stepper che scrive direttamente nel carrello senza una modale a schermo intero nel mezzo.
Il catalogo è data-driven dal backend Laravel, così il team operativo può ricaricare gli articoli, cambiare il pranzo fisso del giorno e attivare o disattivare la disponibilità per location senza un rilascio dell'app. I messaggi orientati al ritiro sono integrati nella home — un indirizzo di consegna e un controllo «specifica orario di ritiro» compaiono sopra il catalogo, e l'onboarding imposta l'aspettativa che un ordine fresco sia pronto in circa 40 minuti. Lo stesso team di ingegneria porta iOS e Android in lockstep nell'ambito della nostra pratica di ingegneria iOS e Android, così il modello del catalogo, la matematica del carrello e le regole di fedeltà si comportano in modo identico su entrambe le piattaforme.
Build Android — Kotlin, il carrello in tempo reale e lo scheduling del ritiro
Il client Android è scritto in Kotlin e condivide il modello di carrello e ordine con iOS tramite il backend Laravel. Il carrello è dove un'app cibo guadagna fiducia: le voci sono raggruppate, ognuna porta il proprio addebito per contenitore dove il menu lo richiede, e il totale progressivo viene ricalcolato istantaneamente al variare degli stepper — nessun spinner, nessun round-trip per tocco, perché le regole di pricing sono replicate lato client e riconciliate con il server solo al checkout. Il pattern replicato-poi-riconciliato è ciò che ha eliminato i bug di aritmetica del carrello che affliggevano la build legacy, dove il totale visualizzato e il totale addebitato potevano divergere.
Il checkout combina tre decisioni in un'unica schermata: la location di ritiro, un commento opzionale all'ordine e un orario di ritiro che il cliente può modificare, con l'app che mostra la stima realistica «pronto in circa 40 minuti» anziché promettere uno slot impossibile. Il toggle fedeltà è qui — il cliente può applicare i bonus per uno sconto fino al 30% del totale dell'ordine, e lo sconto viene calcolato lato server affinché il numero che il cliente vede sia quello che vede la cucina e il team finanziario. Costruire il carrello e il checkout su una base solida è il tipo di sviluppo software su misura che si ripaga da solo già nella prima settimana in cui una catena smette di perdere ordini al passaggio di pagamento.
Architettura dei pagamenti, acquiring tokenizzato e protezione dei dati
Il rifacimento dei pagamenti era il cuore dell'ingaggio. Abbiamo sostituito il cablaggio wallet difettoso con un'integrazione diretta di acquiring con carta guidata dal backend, che supporta sia un addebito una tantum sia un percorso ricorrente tokenizzato affinché un cliente abituale possa riordinare senza reinserire i dati della carta. L'applicazione non memorizza mai un numero di carta — il provider di acquiring restituisce un token opaco che si associa al record del cliente, e ogni addebito viene eseguito su quel token con gestione conforme a PCI-DSS. I webhook di settlement confermano che il denaro è arrivato prima che l'ordine venga rilasciato alla cucina, le chiavi di idempotenza rendono i tentativi sicuri affinché una rete instabile non produca mai un doppio addebito, e i rimborsi vengono riconciliati sullo stesso token affinché la dashboard dell'operatore non sia mai in disaccordo con la realtà. La conferma «il vostro ordine è stato pagato con successo» viene mostrata solo dopo che il webhook è andato a buon fine, non in modo ottimistico.
Sul lato dei dati, il rifacimento è stato strutturato per il pubblico in US e UE fin dall'inizio. I dati personali sono minimizzati al numero di telefono e alla cronologia degli ordini di cui un ordine da asporto ha realmente bisogno; il saldo fedeltà è un registro append-only piuttosto che un campo mutabile; e il consenso viene acquisito esplicitamente alla registrazione. La postura si allinea agli obblighi GDPR per gli utenti nell'Unione Europea e agli obblighi CCPA / CPRA per gli utenti in California e negli Stati Uniti.
Postura di conformità: conforme GDPR · pronto ISO 27001 · SOC 2 Tipo II in corso · compatibile HIPAA · CCPA riconosciuto.
Metodologia di consegna
Un rifacimento in cinque fasi che ha portato Vilka-Lozhka da un'app legacy difettosa a un rilascio stabile e approvato dallo store su iOS, Android e un backend di ordinazione pulito.
Progettazione backend e pagamenti
Backend Laravel + React pulito, schema del catalogo e del registro fedeltà, progettazione dell'integrazione acquiring con addebiti una tantum e ricorrenti tokenizzati e webhook di settlement idempotenti.
Build delle piattaforme native
Client iOS Swift e client Android Kotlin che condividono un unico modello d'ordine: onboarding tramite telefono, catalogo combo, carrello in tempo reale, scheduling del ritiro e toggle di riscatto fedeltà.
Consolidamento dei pagamenti e QA
QA end-to-end dei pagamenti — prevenzione del doppio addebito, riconciliazione dei rimborsi, parità della matematica del carrello tra client e server, e gestione token conforme a PCI-DSS sotto carico.
Lancio store e supporto
Invio su App Store e Google Play con UI rinnovata e informative sulla privacy negli store US e UE, seguito da una finestra di feedback dell'operatore e di stabilizzazione.
Fedeltà, back office dell'operatore e il bridge dei diritti
Il programma fedeltà era il sottosistema a cui abbiamo prestato più attenzione, perché una catena di ristoranti sopravvive o muore in base alla corrispondenza tra il numero che il cliente vede al checkout e quello che la cucina e il team finanziario vedono nel back office. Abbiamo costruito il saldo come registro append-only piuttosto che come contatore mutabile: i punti maturano solo sugli ordini completati, i riscatti sono limitati per ordine come regola di business — uno sconto fino al 30% del totale dell'ordine — e ogni maturazione o utilizzo è una voce del registro che la dashboard dell'operatore legge direttamente. Questa progettazione rende le controversie verificabili e consente alla catena di eseguire promozioni senza corrompere i saldi storici, perché una promozione è semplicemente una nuova regola di maturazione sovrapposta alla stessa cronologia immutabile. Il back office dell'operatore legge la stessa unica fonte di verità che usa l'app, così un responsabile che riconcilia la cassa non deve mai indovinare quale sistema sia autorevole. L'intero sottosistema è stato costruito per essere estensibile: aggiungere un livello di fedeltà multi-location, un bonus referral o un programma per conti aziendali è una modifica di configurazione al servizio di registro e diritti piuttosto che un rilascio client, il che mantiene la catena fuori dal ciclo di revisioni di App Store e Google Play per i normali cambiamenti di marketing.
Lancio negli Stati Uniti e nell'Unione Europea
Le app Vilka-Lozhka sono state costruite per essere lanciate su Apple App Store e Google Play con store attivi negli Stati Uniti e nell'Unione Europea da un'unica codebase. La stessa build serve gli acquirenti in California, New York, Texas, Florida e Washington negli US, e in Paesi Bassi, Germania, Francia, Irlanda e Svezia nell'UE, senza un'app separata per regione. I flussi di consenso sono region-aware a livello del client: gli utenti nell'UE e nello SEE ricevono una schermata di consenso granulare in stile GDPR con toggle separati per eventuali analisi facoltative del prodotto, mentre gli utenti in California ricevono una comunicazione in stile CCPA «Non vendere né condividere le mie informazioni personali» nello stesso flusso. Le pratiche di gestione dei dati sono allineate al GDPR per gli utenti europei e al quadro normativo sulla privacy degli stati US — CCPA / CPRA (California), VCDPA (Virginia), CPA (Colorado), CTDPA (Connecticut), UCPA (Utah), TDPSA (Texas) e Oregon CPA. Poiché l'app minimizza i dati personali a un numero di telefono e alla cronologia degli ordini, la conformità regionale si riduce a una corretta informativa piuttosto che alla separazione dei dati per giurisdizione.
I pagamenti e l'acquiring sono stati l'area che abbiamo consolidato di più per un lancio multi-mercato: il livello di acquiring tokenizzato astrae il provider dietro un'unica interfaccia, così sostituire o aggiungere un acquirer regionale per US o UE è una modifica di configurazione del backend piuttosto che una ricostruzione del client. Sia la classificazione per età dell'App Store sia la classificazione dei contenuti di Google Play sono state calibrate per una funzionalità di ordinazione cibo con pagamenti, citando direttamente gli obblighi GDPR e gli obblighi CCPA della California nell'informativa sulla privacy in-app. Il team di ingegneria che ha realizzato la build opera su un orario CET con sovrapposizione sulla costa est degli US (9:00–13:00 ET) per stand-up, coordinamento delle revisioni store e risposta agli incidenti — il fuso orario che consente a un team di prodotto statunitense e a un team di ingegneria europeo di condividere quattro ore di sovrapposizione live ogni giorno.
Stack tecnologico e roadmap
Swift
SwiftUI
Kotlin
Jetpack Compose
PHP
Laravel
React
REST API
PostgreSQL
Redis
Acquiring con carta
Pagamenti ricorrenti
Apple StoreKit
Google Play Billing
Docker
Nginx
Prometheus
Grafana
La roadmap attiva di sviluppo software su misura per Vilka-Lozhka include una modalità di consegna accanto al flusso di ritiro attuale con dispatch del corriere, un livello di fedeltà multi-location con conti aziendali, prompt di ri-ordine push legati al registro fedeltà, e una superficie di ordinazione web che condivide lo stesso backend Laravel. I piani infrastrutturali includono l'aggiunta di un secondo acquirer regionale dietro l'interfaccia di pagamento tokenizzato esistente per la copertura US e UE, e analisi più ricche per l'operatore integrate nella roadmap cloud & DevOps affinché la catena possa vedere la dimensione del carrello, il tasso di riscatto e l'accuratezza dell'orario di ritiro per location quasi in tempo reale.
Costruite un'app di ordinazione ristorante simile — contattateci
Se state pianificando un'app di ordinazione ristorante o QSR, sostituendo un'integrazione di pagamento difettosa o rifacendo un'app cibo legacy che ha smesso di convertire al checkout per il pubblico in US e UE, abbiamo realizzato questo stack end-to-end e possiamo comprimere significativamente la tempistica di sviluppo. Il caso completo è documentato su yusmpgroup.com/cases/vilka-losja (iOS e Android), e il team di ingegneria che lo ha realizzato è all'interno di YuSMP Group. Operiamo a prezzo fisso per MVP ben definiti e con team dedicati di sviluppo per la consegna continuativa, con un orario CET e una finestra garantita di sovrapposizione con la costa est degli US (9:00–13:00 ET) per stand-up, demo e risposta agli incidenti.
Domande frequenti
Quanto costa realizzare un'app di ordinazione cibo per ristorante come questa?
Un MVP di ordinazione per catena di ristoranti che comprende client iOS e Android nativi, un catalogo combo, un carrello in tempo reale, un provider di acquiring e lo scheduling del ritiro costa tipicamente 90.000–200.000 USD. L'aggiunta di un programma fedeltà, fatturazione ricorrente, supporto multi-location, integrazioni con cucina e operatori, e analisi porta un prodotto completo a 220.000–450.000 USD. I principali fattori di costo sono l'integrazione dei pagamenti e dell'acquiring, la logica di fedeltà e dei diritti, e il mantenimento di due client nativi in lockstep tra iOS e Android.
Perché rifare da zero un'app ristorante legacy invece di correggerla?
Le app legacy di ordinazione cibo di solito cedono prima sul percorso di pagamento e sulla matematica del carrello, e sono i punti più pericolosi da correggere in modo incrementale perché ogni fix rischia di addebitare doppiamente o perdere un ordine. Quando l'integrazione dell'acquiring è rotta e la codebase ha accumulato bug critici, una ricostruzione disciplinata su un backend Laravel pulito con client nativi Swift e Kotlin è più rapida a un rilascio stabile e approvato dallo store rispetto all'inseguimento delle regressioni nel vecchio codice. Abbiamo portato avanti il catalogo e i dati di fedeltà riscrivendo il flusso di ordine e pagamento dai principi fondamentali.
Come si integrano i pagamenti ricorrenti con carta in un'app di ordinazione cibo?
L'acquiring con carta per un'app cibo necessita sia di addebiti una tantum sia di un percorso ricorrente tokenizzato affinché i clienti abituali possano riordinare senza reinserire i dati della carta. L'app non memorizza mai il numero completo della carta — il provider di acquiring restituisce un token opaco che si associa al record del cliente, e il backend addebita su quel token con gestione conforme a PCI-DSS. I webhook confermano il settlement prima che l'ordine venga rilasciato alla cucina, le chiavi di idempotenza prevengono i doppi addebiti sui tentativi, e i rimborsi vengono riconciliati sullo stesso token affinché la dashboard dell'operatore rimanga coerente.
Di cosa ha bisogno un programma fedeltà nel backend di un'app ristorante?
Un programma fedeltà necessita di un'unica fonte di verità per il saldo che sia letta sia dall'app sia dal back office dell'operatore, in modo che il numero che il cliente vede al checkout corrisponda sempre a quello che vede la cucina e il team finanziario. I punti maturano solo sugli ordini completati, i riscatti sono limitati per ordine come regola di business (qui, uno sconto fino al 30% del totale dell'ordine), e ogni maturazione o utilizzo è una voce append-only nel registro piuttosto che un contatore mutabile. Quel registro rende le controversie verificabili e consente alla catena di eseguire promozioni senza corrompere i saldi storici.
Quanto tempo ci vuole per rilasciare un'app di ordinazione ristorante su iOS e Android?
Un MVP mirato con client iOS e Android nativi, un catalogo combo, un carrello in tempo reale, un provider di acquiring e lo scheduling del ritiro richiede tipicamente 10–16 settimane. L'aggiunta di un programma fedeltà, fatturazione ricorrente, supporto multi-location e integrazioni con l'operatore aggiunge 6–10 settimane. Il passaggio di approvazione sullo store — informative sulla privacy, revisione della policy di pagamento e coordinamento dell'invio su App Store e Google Play — è spesso sottovalutato e dovrebbe essere pianificato con 3–5 settimane di lavoro dedicato.
Casi correlati
Altre build mobile e di piattaforme commerce
Delivery
Una piattaforma di consegna cibo con ordinazione in tempo reale, dispatch del corriere e flussi di pagamento in US & UE.
Vedi il caso →
Lucky Shrimp
Un'esperienza di ordinazione ristorante con catalogo menu, carrello e ritiro — build mobile nativa per i clienti US & UE.
Vedi il caso →
SuperStep
Una build commerce retail omnicanale con catalogo, carrello, fedeltà e pagamento negli store US & UE.
Vedi il caso →Servizi correlati
Sviluppo App Mobile
App iOS, Android e cross-platform native con pipeline di rilascio pronte per lo store.
Scopri lo sviluppo app mobile →
Sviluppo Software su Misura
Piattaforme personalizzate progettate sul vostro modello di business, che scalano in modo ordinato dall'MVP a milioni di utenti.
Scopri lo sviluppo software su misura →
Cloud & DevOps
Infrastruttura resiliente, CI/CD e osservabilità affinché i flussi di pagamento e ordinazione restino operativi sotto carico.
Scopri Cloud & DevOps →Pianificate una build simile
Prenota una chiamata di analisiRichiedi una proposta
Condividete alcuni dettagli e un consulente senior risponderà entro un giorno lavorativo.