Discovery e affiancamento agenti
Shadowing sul campo con i manager regionali, mappatura della copertura offline, revisione postura GDPR + CCPA per i record clienti, requisiti di accesso per ruolo per territorio.
Case study · AgTech · Tooling interno
Farm — app vendite sul campo offline-first per l'agricoltura
Come abbiamo realizzato Farm — un'app interna iOS e Android nativa per un distributore di prodotti agricoli i cui responsabili vendite sul campo trascorrono le loro giornate in cantine, magazzini e aziende agricole senza copertura negli Stati Uniti e nell'Unione Europea. Costruita su uno store SQLite offline-first, un back office Laravel + React e uno strato di reportistica piano-vs-consuntivo che regge al controllo GDPR e CCPA — e rimane in uso continuativo in produzione da tre anni.
Il brief — un toolkit vendite sul campo che funziona senza segnale
Il team di prodotto Farm è arrivato con un problema operativo specifico. I loro responsabili vendite regionali coprivano territori agricoli negli Stati Uniti e nell'Unione Europea, e il workflow quotidiano non somigliava per nulla all'ipotesi che ogni app CRM mobile standard fa. Un agente guidava novanta minuti fino al sito del cliente, perdeva il segnale cellulare dentro un fienile o una cantina di stoccaggio fertilizzanti, discuteva i prezzi per quarantacinque minuti, concordava una trattativa e poi doveva archiviarla — spesso ancora senza copertura. Gli strumenti esistenti o perdevano silenziosamente il report o richiedevano all'agente di ricordare di riarchiviarlo dall'auto. Abbiamo ricostruito il workflow da principi fondamentali come app interna iOS e Android nativa: uno specchio SQLite offline-first del catalogo prodotti, report trattative che si accoda localmente e si riconcilia in modo deterministico, e una dashboard piano-vs-consuntivo regionale che il manager senior apre all'inizio di ogni settimana. Il risultato è un toolkit di vendita interno che viene distribuito negli US e nell'EU con conformità GDPR e CCPA / CPRA fin dal primo giorno, si trova nel portfolio di lavori di sviluppo di app mobile di YuSMP Group, e ora funziona non presidiato in produzione da tre anni.
Punti salienti del progetto
Client iOS & Android nativi
Catalogo SQLite offline-first
Sincronizzazione trattative senza conflitti
Reportistica piano vs consuntivo
Dashboard regionali in React
Back office admin Laravel
Accesso per ruolo
3 anni in produzione · US & EU
I numeri del progetto
Uno snapshot di ciò che il progetto Farm ha consegnato su iOS, Android e un back office Laravel + React nel suo primo ciclo di produzione e nei tre anni operativi successivi.
2piattaforme native — iOS in Swift e Android in Kotlin, codebase completamente separate ottimizzate per OS
3 anniutilizzo continuativo in produzione nei territori di vendita sul campo US ed EU con telemetria stabile
100%delle trattative archiviate offline si riconciliano in modo deterministico alla prossima sincronizzazione riuscita — nessun duplicato
9 mesifinestra di sviluppo iniziale dalla discovery al primo rollout in produzione su entrambi gli store
4categorie prodotto principali — fertilizzanti, sementi, agenti chimici e attrezzature — nel catalogo strutturato
14–20 sett.finestra di consegna tipica per un'app interna per vendite sul campo comparabile su entrambi gli store
Perché iOS e Android nativi invece di uno shell cross-platform
La decisione sulla piattaforma ha dominato ogni altra scelta architetturale. Abbiamo scelto Swift nativo su iOS e Kotlin su Android invece di un singolo shell cross-platform perché i trade-off in una finestra produttiva di tre anni si allineano in modo pulito con il percorso nativo. I client nativi ci hanno dato accesso di primo livello allo stack Core Data e SQLite nativo della piattaforma su iOS e Room su SQLite su Android — la base di qualsiasi architettura mobile offline-first difendibile. La semantica della sincronizzazione in background differisce abbastanza tra iOS BGTaskScheduler e Android WorkManager che avvolgere entrambi in una singola astrazione ci sarebbe costata la prevedibilità di cui il team operations aveva bisogno per gli agenti non presidiati.
Gli shell cross-platform — React Native, Flutter, la coda di Xamarin — sono stati valutati ed eliminati. Le loro astrazioni sul lavoro in background e su SQLite nativo della piattaforma erano la forma sbagliata per un workflow da agente che trascorre ore offline. Scegliere il nativo ha significato che l'intero stack — UI, store locale, motore di sincronizzazione, consegna delle notifiche push — è di proprietà per piattaforma e citabile end-to-end rispetto alla documentazione sviluppatori di Apple e Google.
| Dimensione | Swift / Kotlin nativo (Farm) | React Native | Flutter |
|---|---|---|---|
| Accesso SQLite offline | Di primo livello — Core Data e Room | Bridged — WatermelonDB o terze parti | Bridged — sqflite o Drift |
| Sincronizzazione in background | BGTaskScheduler / WorkManager diretti | Wrapped — affidabilità variabile | Wrapped — affidabilità variabile |
| Profilo batteria in sessioni offline lunghe | Configurabile per piattaforma | Più pesante — costo JS bridge | Più leggero di RN, ancora astratto |
| Costo manutenzione triennale | Due codebase stabili su API OS-vendor | Churn aggiornamenti framework | Churn aggiornamenti framework |
| Accessibilità nativa | VoiceOver / TalkBack di primo livello | Accettabile — lacune parziali | Accettabile — lacune parziali |
| Affidabilità notifiche push | APNs / FCM diretti | Bridged — Notifee / RNFB | Bridged — firebase_messaging |
| Comportamento tastiera / locale per OS | Nativo OS | Wrapped — casi limite | Wrapped — casi limite |
Platform references: Apple BGTaskScheduler documentation, Android WorkManager reference.
Build iOS — Swift, Core Data e il flusso di report trattative
Il client iOS è costruito in Swift con SwiftUI per il livello UI e Core Data su SQLite per lo store locale. L'intera superficie di report trattative si riduce a una singola macchina a stati — bozza, in coda, in sincronizzazione, riconciliato — e l'agente non vede mai un errore di rete nel flusso utente perché il report è già stato persistito localmente prima che la schermata completi la sua animazione di dismissione. La ricerca clienti opera sullo store sul dispositivo senza round-trip di rete, il catalogo è paginato in una lista lazy, e i prezzi vengono risolti dalla versione del listino prezzi in cache locale che era autorevole all'ultima sincronizzazione riuscita dell'agente.
Il percorso di riconciliazione è dove la maggior parte delle app di vendita interne perde correttezza, e dove abbiamo speso uno sforzo ingegneristico sproporzionato. Il flusso è: scrivere il report in Core Data con un timestamp cliente monotonico e una chiave di idempotenza UUID, accodarlo in BGTaskScheduler, tentare la sincronizzazione ad ogni transizione di connettività, e lasciare che il server restituisca il record di autorizzazione canonico. I duplicati sono impossibili perché la chiave di idempotenza è la correlazione primaria, e una vendita chiusa in una cantina in Svezia e riaperta su un treno due ore dopo si riconcilia in modo pulito. La superficie iOS end-to-end è consegnata come parte della nostra practice di ingegneria iOS e Android.
Build Android — Kotlin, Room e il motore di sincronizzazione
Il client Android è scritto in Kotlin con Jetpack Compose per la UI e un livello Room su SQLite per lo store locale. WorkManager gestisce il programma di sincronizzazione in background con semantica di backoff che rispetta la modalità Doze e gli ottimizzatori batteria di Samsung, Xiaomi, OnePlus e Pixel — senza un servizio in foreground, il motore di sincronizzazione morirebbe silenziosamente dentro un container OEM aggressivo nel giro di minuti, interrompendo il contratto implicito che un report offline alla fine compare nella dashboard del manager. Una notifica persistente minimale mantiene in vita la sincronizzazione long-form su tutte le famiglie di dispositivi da Android 10 ad Android 14.
Il motore di sincronizzazione è dove il client Android guadagna il suo posto. Il delta sul dispositivo viene spedito a un'API Laravel ad ogni transizione di connettività, il server restituisce il listino prezzi e il registro clienti autorevoli, e la risoluzione dei conflitti è deterministica — il server vince su prezzi e record clienti, il client vince su note sul campo e metadati allegati dall'agente. Dopo un handoff da Wi-Fi a LTE il motore riprende automaticamente l'ultimo token di sincronizzazione, e l'aggiornamento del catalogo è incrementale anziché un reload completo — un agente con uno store locale da 250 MB non re-scarica il catalogo ogni lunedì. Lo stesso team di ingegneria porta avanti iOS e Android in lock-step come parte della nostra practice di sviluppo di app mobile.
Back office, piano vs consuntivo e postura audit-ready
Il back office di Farm si basa su un'API Laravel con un admin React e contiene solo i dati necessari — registro clienti, catalogo prodotti, listino prezzi, quote di vendita trimestrali e il flusso di report trattative che arriva dal campo. Non c'è tracciamento della posizione per agente, nessuna cattura di keystroke in idle e nessuna pipeline di metadati verso un vendor di osservabilità terzo. I contatori che alimentano la dashboard regionale piano-vs-consuntivo vengono aggregati lato server e trasmessi come serie numeriche anonime; gli identificatori per cliente non escono dalla tabella clienti.
L'identità di fatturazione dei clienti del distributore — le aziende agricole e le cooperative che acquistano il prodotto — è contenuta nello stesso store Laravel, ma è soggetta a controllo di accesso tramite un modello di permessi per ruolo affinché un agente sul campo veda solo i clienti del proprio territorio. Le policy infrastructure-as-code applicano gli invarianti di accesso — qualsiasi pull request che amplierebbe lo scope di lettura di un agente o introdurrebbe un log di posizione per agente fa fallire la CI. La postura è costruita per allinearsi agli obblighi GDPR per gli utenti nell'Unione Europea e agli obblighi CCPA / CPRA per gli utenti in California e negli Stati Uniti — e per rendere una futura revisione di idoneità indipendente un esercizio documentale, non un intervento architetturale.
Postura di conformità: Conforme al GDPR · Pronto per ISO 27001 · SOC 2 Type II in corso · Compatibile HIPAA · CCPA riconosciuto.
Metodologia di consegna
Un progetto in cinque fasi che ha portato Farm dalle interviste di ricerca territoriale alla produzione su iOS, Android e un back office Laravel + React.
Modello catalogo e sincronizzazione
Schema catalogo prodotti, prezzi strutturati, progettazione token di sincronizzazione, contratto chiave di idempotenza per i report trattative, skeleton API Laravel, scaffolding admin React.
Sviluppo piattaforme
Client iOS Swift / SwiftUI su Core Data + BGTaskScheduler; client Android Kotlin / Jetpack Compose su Room + WorkManager; macchina a stati report trattative.
Hardening audit-ready
Policy infrastructure-as-code che bloccano regressioni dello scope di accesso, QA permessi per ruolo, pipeline di telemetria crash, revisione dell'inviluppo operativo triennale.
Lancio e telemetria
Invio distribuzione interna App Store + Google Play negli storefront US ed EU, rollout dashboard regionale, cutover piano-vs-consuntivo per i manager senior.
Piano vs consuntivo, assegnazione quote e la vista manager
Lo strato di reportistica di Farm è stato costruito per mantenere la reportistica sul campo e le analisi del manager in modo dimostrabilmente allineato, perché il ciclo piano-vs-consuntivo si rompe nel momento in cui un manager e un agente vedono numeri diversi per lo stesso cliente nella stessa settimana. La quota trimestrale viene impostata da un manager senior nell'admin React e inviata allo store locale di ogni agente alla successiva sincronizzazione. L'agente vede i propri progressi nell'app mobile — un singolo sparkline rispetto al piano, suddiviso per categoria prodotto — e il manager senior vede l'aggregato regionale nel back office con drill-down ai dati per agente e per cliente. L'aggregazione lato server opera su un unico flusso autorevole di report trattative che i client mobile alimentano tramite il percorso della chiave di idempotenza, così la vista del manager e quella dell'agente si riconciliano sempre alla stessa fonte di verità. Il comportamento kill-edit, i report offline in ritardo e le note sul campo allegate dall'agente leggono tutti dallo stesso record, così una singola trattativa si risolve in modo pulito attraverso reinstallazioni, cambi dispositivo e il futuro portale web. L'intero sottosistema è stato costruito con l'estensibilità in mente: aggiungere un livello multi-valuta, un motore di commissioni per territorio o un'estensione agente-partner B2B è una modifica di configurazione contro il back office, non una release di codice.
Lancio negli Stati Uniti e nell'Unione Europea
Farm è stato lanciato su Apple App Store e Google Play (distribuzione interna) con storefront attivi negli Stati Uniti e nell'Unione Europea. La build in lingua inglese serve gli agenti di vendita sul campo in California, New York, Texas, Florida e Washington negli US, e nei Paesi Bassi, Germania, Francia, Irlanda e Svezia nell'EU, senza una codebase separata per regione. I flussi di consenso sono consapevoli della regione al livello back office: gli account agente nell'EU e nello SEE ricevono una schermata di consenso granulare in stile GDPR per qualsiasi telemetria opzionale del prodotto, e gli account in California ricevono un'informativa in stile CCPA sul «Non vendere né condividere le mie informazioni personali» nello stesso flusso di registrazione. Le pratiche di gestione dei dati sono allineate al GDPR per gli utenti europei e al patchwork sulla privacy degli stati USA — CCPA / CPRA (California), VCDPA (Virginia), CPA (Colorado), CTDPA (Connecticut), UCPA (Utah), TDPSA (Texas) e Oregon CPA. Poiché l'architettura minimizza i dati di tracciamento per agente, la conformità regionale si riduce a divulgazione onesta anziché a segregazione dei dati per giurisdizione.
L'API Laravel è stata distribuita nelle regioni EU e US in parallelo — Paesi Bassi, Germania, Francia, Svezia e Irlanda per la copertura EU; US East e US West per il Nord America — con i worker stateless di ogni regione provisionati in modo identico. Il servizio di aggregazione che alimenta la dashboard regionale piano-vs-consuntivo esegue worker stateless che possono essere vincolati alle regioni EU o US indipendentemente per futuri impegni di residenza dei dati. Sia la distribuzione App Store che quella Google Play sono state calibrate per l'enrollment aziendale interno, e l'informativa sulla privacy in-app documenta esattamente l'architettura sopra, citando direttamente gli obblighi GDPR e gli obblighi CCPA della California. Il team di ingegneria dietro il progetto opera su CET e lavora in orario CET con sovrapposizione con la costa est degli Stati Uniti (9:00–13:00 ET) per stand-up, coordinamento delle revisioni sullo store e risposta agli incidenti — il fuso orario che permette a un team di prodotto US e a un team di ingegneria EU di condividere quattro ore di sovrapposizione live ogni giorno.
Stack tecnologico e roadmap
Swift
SwiftUI
Core Data
BGTaskScheduler
Kotlin
Jetpack Compose
Room
WorkManager
SQLite
Laravel
PHP 8
React
PostgreSQL
Redis
APNs
Firebase Cloud Messaging
Docker
Terraform
Prometheus
La roadmap attiva di sviluppo software su misura per Farm include un motore di commissioni per territorio, un listino prezzi multi-valuta per i distributori transfrontalieri, un trasporto di condivisione offline offuscato affinché gli agenti possano passare un report trattativa da un dispositivo all'altro sul campo senza round-trip attraverso il server, e un client desktop costruito su Tauri per condividere la business logic con la codebase mobile. Un livello agente-partner B2B con lista clienti propria, gestione del team e SSO è pianificato per i distributori mid-market US ed EU, con il sottosistema di autorizzazione già strutturato per l'assegnazione multi-sede. I piani infrastrutturali includono ulteriore automazione Cloud & DevOps della pipeline di rollout regionale, un harness di verifica continua interno per il contratto di correttezza della sincronizzazione offline e una futura valutazione di idoneità indipendente inserita nella cadenza operativa.
Realizzate un'app vendite sul campo simile — contattateci
Se state pianificando un'app mobile interna per le vendite sul campo, uno strumento AgTech offline-first o qualsiasi app mobile dove gli agenti trascorrono ore senza copertura e il ciclo di reportistica deve resistere a un revisore esterno per il pubblico US ed EU, abbiamo consegnato questo stack end-to-end e possiamo ridurre significativamente la timeline di sviluppo. Il prodotto live è gestito internamente dal distributore su yusmpgroup.ru/cases/farm (pagina case), e il team di ingegneria dietro di esso si trova all'interno di YuSMP Group. Lavoriamo a prezzo fisso per MVP ben definiti e con team di sviluppo dedicati per la consegna continuativa, con giornata lavorativa CET e sovrapposizione garantita con la costa est degli Stati Uniti (9:00–13:00 ET) per stand-up, demo e risposta agli incidenti.
Domande frequenti
Quanto costa realizzare un'app mobile interna per le vendite sul campo per i distributori?
Un'app mobile interna per le vendite sul campo con client iOS e Android, un catalogo prodotti offline, report trattative e un back office Laravel o Node costa in genere €80k–€180k per un MVP. Aggiungendo dashboard piano-vs-consuntivo regionali, permessi per ruolo, sincronizzazione offline senza conflitti, promemoria push e integrazioni in un ERP esistente o stack contabile in stile 1C si arriva a un rollout completo per €220k–€450k. Il principale fattore di costo è il lavoro di correttezza della sincronizzazione offline e la logica di prezzo per regione.
Perché usare una build iOS e Android nativa invece di un framework cross-platform?
Gli agenti di vendita sul campo nelle zone agricole lavorano per ore offline, in cantine, magazzini e campi senza segnale. I client nativi Swift e Kotlin ci permettono di controllare il consumo della batteria durante le lunghe sessioni di sincronizzazione, integrare gli store SQLite nativi della piattaforma in modo pulito e fornire comportamenti di tastiera e accessibilità per OS che React Native e Flutter avvolgono ancora in compromessi. Con una finestra operativa di tre anni, il costo di manutenzione di due codebase native si è rivelato inferiore al costo cumulativo di aggirare le astrazioni cross-platform.
Come si realizza una vera app mobile di vendita offline-first?
Una postura offline-first difendibile è una decisione architetturale, non un toggle di funzionalità. Il catalogo prodotti completo, le tabelle dei prezzi e l'elenco clienti vengono speculati in un archivio SQLite locale al primo accesso e aggiornati incrementalmente ad ogni sincronizzazione riuscita. I report trattative scritti offline vengono accodati con timestamp locali monotonici e riconciliati sul server tramite chiavi di idempotenza, così un agente che chiude una vendita in una cantina e riapre l'app su un treno due ore dopo non duplica né perde mai una transazione. La risoluzione dei conflitti è deterministica — il server vince sul prezzo, il client vince sulle note sul campo.
Cosa fa l'app Farm per i responsabili vendite sul campo in agricoltura?
Farm è il toolkit interno che un responsabile vendite regionale porta in una visita in azienda. Espone un catalogo strutturato di fertilizzanti, sementi, agenti chimici e attrezzature con i prezzi correnti; permette all'agente di archiviare un report trattativa in secondi per un cliente noto; traccia piano vs consuntivo rispetto agli obiettivi di vendita trimestrali dell'agente; e mostra una dashboard lato manager che scompone i numeri per categoria di prodotto e regione. I promemoria push sollecitano i report non archiviati, e un admin di back office in React gestisce aggiornamenti catalogo, modifiche prezzi e assegnazione quote.
Quanto tempo occorre per realizzare un'app interna per le vendite sul campo su iOS e Android?
Un MVP mirato con client iOS e Android nativi, un catalogo offline-first, report trattative e un admin Laravel richiede in genere 14–20 settimane. Aggiungere la dashboard regionale lato manager, le analisi piano-vs-consuntivo, i permessi per ruolo per manager senior e agenti sul campo, e lo strato di sincronizzazione senza conflitti richiede ulteriori 6–10 settimane. L'hardening dell'app per tre anni di utilizzo in produzione non presidiato — telemetria crash, affidabilità push, log di replay sincronizzazione — è frequentemente sottostimato e dovrebbe essere preventivato in 4–6 settimane di lavoro dedicato.
Casi correlati
Altri progetti mobile e tooling interno
CheckList
App mobile di audit sul campo per ispettori — moduli offline, cattura multi-foto, dashboard manager.
Vedi il caso →
SuperStep
App interna di formazione e performance per una catena retail — base di conoscenza, tracker performance, back office.
Vedi il caso →
ZipIt
Marketplace B2B di ricambi auto con CRM fornitori, catalogo strutturato e workflow ordini negli US & EU.
Vedi il caso →Pianifica un progetto simile
Prenota una chiamata di analisiRichiedi una proposta
Condividete alcuni dettagli e un consulente senior risponderà entro un giorno lavorativo.