CivicOS è un progetto full-stack da zero: non una vetrina istituzionale, ma un prodotto digitale con portale web, app mobile e flussi operativi reali per la raccolta differenziata e i servizi al cittadino. Qui spiego perché non è “un sito con un’app appiccicata”, cosa comporta lo stack Laravel + React Native, e per chi ha senso un intervento di questa portata.
Contesto e problema iniziale
Comunicare con i cittadini su raccolta rifiuti, orari, punti sul territorio e segnalazioni non è un problema di brochure. È un problema di servizio quotidiano: informazioni che cambiano, richieste che arrivano, emergenze da notificare, mappe da consultare. Quando tutto passa da PDF, centralino o post social sparsi, il cittadino si perde e l’ente perde tempo.
CivicOS nasce da questa esigenza: digitalizzare il rapporto tra cittadino e comune (o gestore del servizio) intorno alla raccolta differenziata e ai servizi collegati. Non bastava “mettere online un calendario”. Serviva un ecosistema: un back-office dove gestire contenuti e richieste, un’app dove il cittadino trova ciò che gli serve, e canali di comunicazione in tempo reale quando c’è qualcosa di urgente.
È un ambito Smart City concreto, non uno slogan. Parliamo di flussi reali — calendario raccolta, ritiro ingombranti, mappe, segnalazioni — che devono funzionare su web e su mobile con le stesse regole. Partire da zero, in questo caso, non era un vezzo: non esisteva un prodotto già allineato a quei bisogni, e un template WordPress non avrebbe coperto l’app, le API e le notifiche push.
Approccio e scelte tecniche
Lo stack — Laravel, React Native, REST API, MySQL, push notifications — risponde a tre esigenze: un backend solido per amministrare e orchestrare i dati, un’app iOS/Android con una sola codebase mobile, e un contratto chiaro (API REST) tra i due mondi.
Laravel mi permette di strutturare autenticazione, modelli, validazioni e logiche di business in modo ordinato, con un ecosistema maturo per API e integrazione. MySQL resta adatto a dati relazionali (utenze, richieste, punti mappa, calendari) che devono restare coerenti tra web e app. React Native consente di pubblicare su iOS e Android senza sviluppare due applicazioni native separate da zero — utile quando il prodotto deve vivere su entrambi gli store e evolversi insieme.
Le push notifications non sono un “extra marketing”: in questo contesto sono un canale operativo. Avvisi urgenti, emergenze, comunicazioni comunali: se il cittadino deve aprirsi il sito ogni volta, il servizio perde valore. L’app e le push chiudono quel gap.
È un livello di complessità diverso da un sito vetrina. Nella pagina sulla realizzazione siti web distinguo i progetti di comunicazione da quelli prodotto; per tempi e effort, quanto tempo serve per un sito (o un prodotto) professionale aiuta a calibrare le aspettative. Anche i costi scalano con lo scope: orientati con quanto costa un sito web, sapendo che web + app + API è un’altra fascia rispetto a una landing.
Cosa è stato fatto in pratica
Il deliverable non è una homepage. È un sistema. In concreto:
- Portale web e app (Laravel + React Native): Architettura da zero del back-office web e dell’app iOS/Android, con API REST e database MySQL. Stesse logiche lato server, due interfacce (admin e cittadino) allineate.
- Servizi smart sul territorio: Calendario raccolta, ritiro ingombranti, mappa punti acqua e segnalazioni geolocalizzate al Comune. Funzioni che il cittadino usa davvero, non sezioni decorative.
- Notifiche push: Canale in tempo reale per avvisi urgenti, emergenze e comunicazioni comunali — parte integrante del prodotto, non un plugin aggiunto dopo.
Dal punto di vista del lavoro quotidiano: modellare i dati, definire i flussi di richiesta, costruire le schermate mobile, collegare mappe e geolocalizzazione, far sì che ciò che l’operatore pubblica o gestisce dal web arrivi in modo coerente sull’app. È sviluppo prodotto, non “mettere online tre pagine istituzionali”.
Risultato qualitativo
Non pubblico metriche inventate su download o tasso di apertura delle push. Il risultato che posso descrivere in modo onesto è qualitativo: CivicOS offre un canale unico e strutturato per raccolta differenziata e servizi al cittadino, con web e mobile sullo stesso motore. Il cittadino ha dove guardare orari, mappe e richieste; l’ente ha uno strumento per comunicare e gestire, invece di pezzi sparsi.
Per un prodotto Smart City, “funziona” significa: i flussi principali sono usabili, le informazioni sono aggiornabili dal back-office, le notifiche arrivano quando servono. Il resto — adozione, volumi, evoluzioni future — dipende da come il servizio viene comunicato e gestito sul territorio. Il prodotto live è civicos.it.
Cosa implica per un cliente simile
Se stai valutando un progetto web + app per PA, multiutility o un servizio territoriale, questo case study serve soprattutto a chiarire lo scope.
Prima: non è lo stesso preventivo di un sito aziendale. API, app store, push, mappe e back-office moltiplicano analisi, sviluppo e manutenzione. Seconda: conviene partire dai flussi reali (cosa deve fare il cittadino? cosa deve gestire l’operatore?) e solo dopo scegliere lo stack — Laravel + React Native ha senso quando ti serve un prodotto multi-piattaforma con backend centralizzato. Terza: un MVP può essere più snello, ma va detto chiaramente cosa entra e cosa resta fuori; altrimenti si promette un ecosistema e si consegna una brochure.
Se il tuo bisogno è invece un sito professionale senza app, restano rilevanti le guide su realizzazione siti web e come scegliere lo sviluppatore. Se invece stai costruendo un prodotto digitale serio — come CivicOS — serve un interlocutore che ragioni su architettura, non solo su template. Possiamo parlarne partendo dai tuoi flussi operativi, senza buzzword Smart City e senza promesse assolute.