Progetti
Costruire un'app che genera piani alimentari con l'IA e li tiene coerenti
Generare un piano alimentare con un modello di intelligenza artificiale richiede poco lavoro. Tenerlo coerente quando il peso cambia, l'obiettivo si sposta e l'utente salta due giorni ne richiede molto di più. Raccontiamo come è costruita DietApp e dove si concentra la difficoltà reale.
Da dove nasce DietApp: sapere cosa mangiare oggi senza rifare i conti
All'origine di DietApp c'è un fastidio pratico osservato sul campo, prima ancora di qualsiasi analisi di mercato. Chi inizia un piano alimentare non fatica il primo giorno. Fatica il mercoledì della terza settimana, quando il foglio stampato non corrisponde più a quello che c'è in frigo, il peso è cambiato, l'allenamento è saltato e ricalcolare porzioni e macronutrienti costa più tempo di quanto se ne abbia. A quel punto si torna a mangiare come prima.
Il compito che abbiamo dato all'app è volutamente stretto: rispondere alla domanda "cosa mangio oggi" con porzioni già calcolate, e tenere quella risposta aggiornata quando il contesto cambia. Tutto il resto, dalle sfide alle classifiche, è rumore rispetto a quel compito. L'app è pubblicata su Google Play dal 26 settembre 2025, ha superato i cinquecento download ed è stata aggiornata a luglio 2026.
La parte che sembra difficile, cioè far generare un piano alimentare a un modello di intelligenza artificiale, è quella che si risolve in fretta. La parte che consuma davvero tempo di sviluppo è mantenere quel piano coerente nel tempo e farlo stare dentro le regole che valgono quando si tocca la salute delle persone. Questo articolo racconta soprattutto la seconda parte.
Come funziona la generazione del piano alimentare con l'intelligenza artificiale
Il punto di partenza è un profilo: età, peso, altezza, livello di attività, obiettivo e alimenti che l'utente non vuole o non può mangiare. Da questi dati l'app costruisce un fabbisogno calorico e una distribuzione di macronutrienti, poi genera la struttura dei pasti sulla giornata.
La scelta architetturale che consideriamo più importante è la separazione tra calcolo e composizione. Il fabbisogno resta deterministico: è aritmetica, deve dare lo stesso risultato a parità di input e deve essere verificabile riga per riga. Al modello lasciamo la parte in cui è forte, cioè comporre pasti sensati e vari che rispettino quel budget e quei vincoli. Se si affida anche il calcolo al modello si ottiene un'app che ogni tanto sbaglia il totale senza che nessuno se ne accorga, e non c'è modo di riprodurre l'errore.
I vincoli su allergie e alimenti esclusi meritano un discorso a parte. Metterli nel prompt come indicazione testuale non basta: un modello linguistico li rispetta quasi sempre, e "quasi sempre" resta un criterio inaccettabile quando l'utente ha escluso le arachidi. Nella nostra implementazione l'esclusione è un filtro applicato prima e dopo la generazione, sul dato strutturato degli ingredienti. Se un piatto contiene un ingrediente vietato non viene proposto, indipendentemente da come il modello lo abbia descritto. Il prompt aiuta la qualità della proposta, il filtro garantisce la regola.
Vale la pena distinguere anche fra preferenza e vincolo. "Non mi piacciono i funghi" e "sono allergico ai crostacei" occupano lo stesso campo nel form e vanno trattati in modo diverso: il primo si può violare proponendo un'alternativa, il secondo mai. Gestirli con lo stesso meccanismo è comodo in fase di prototipo e diventa un problema appena l'app esce dal telefono di chi l'ha scritta.
Il ricalcolo automatico è il vero problema di ingegneria
Generare un piano una volta è un esercizio. Tenerlo valido mentre l'utente cambia peso, obiettivo o abitudini è il lavoro vero, perché ogni modifica al profilo mette in discussione dati già scritti, già visti e magari già seguiti a metà.
Il piano va trattato come uno stato persistente
Se si tratta il piano come il risultato di una chiamata, ogni variazione del profilo obbliga a rigenerare tutto e l'utente si ritrova la giornata stravolta a pranzo. Il piano va modellato come uno stato con una sua storia, su cui si applicano modifiche mirate.
Decidere cosa ricalcolare e cosa lasciare fermo
Un cambio di obiettivo, ad esempio dal mantenimento alla perdita di peso, giustifica una rigenerazione. Una oscillazione minima sulla bilancia no. Abbiamo definito soglie oltre le quali il fabbisogno viene ricalcolato, e sotto le quali il dato viene registrato ma non produce effetti immediati sul piano.
Non riscrivere il passato
I giorni già consumati devono restare come erano, altrimenti il diario perde senso e l'utente non riesce più a capire cosa ha davvero mangiato. Il ricalcolo agisce da oggi in avanti; lo storico è immutabile.
La varietà va gestita esplicitamente
Un modello, lasciato libero, tende a riproporre gli stessi piatti. Serve tenere memoria di cosa è già stato proposto nei giorni recenti e passarla come vincolo, altrimenti l'utente mangia sempre le stesse cose per due settimane e abbandona.
Prevedere il fallimento della generazione
La chiamata al modello può andare in timeout, tornare malformata o violare un vincolo in fase di verifica. L'app deve avere una strada alternativa che non lasci l'utente davanti a una schermata vuota all'ora di cena: riproporre il piano precedente coerente è meglio che non proporre nulla.
Il costo di ogni rigenerazione
Ogni ricalcolo è una chiamata a un servizio a consumo. Un'app freemium che rigenera il piano a ogni apertura ha un modello economico che non regge. Le soglie di ricalcolo servono anche a questo, ed è il motivo per cui il confine tra prodotto e infrastruttura, qui, è molto sottile.
Oltre quattrocento ricette italiane e il peso dell'aderenza
Il ricettario contiene più di quattrocento ricette italiane con i valori nutrizionali già calcolati. La scelta della cucina orienta l'intero piano: è la variabile che decide se viene seguito o abbandonato.
Ingredienti che si trovano davvero
Un piano perfetto sulla carta che chiede tre ingredienti reperibili solo in un negozio specializzato viene disatteso al primo giro di spesa. Restare dentro un repertorio di prodotti comuni nei supermercati italiani vale più di qualsiasi ottimizzazione dei macronutrienti.
Piatti che appartengono alle abitudini di chi legge
Proporre a un utente italiano una colazione che non ha mai fatto in vita sua significa chiedergli due cambiamenti insieme: mangiare meno e mangiare diverso. Uno dei due è già abbastanza difficile.
Valori nutrizionali precalcolati
Tenere i valori nutrizionali come dato del ricettario, e non come stima prodotta al volo dal modello, rende ogni piano verificabile. Se un totale non torna, si risale al piatto e all'ingrediente.
Le porzioni sono la parte scomoda
La stessa ricetta deve funzionare per fabbisogni molto diversi. Scalare linearmente tutti gli ingredienti dà risultati assurdi oltre una certa soglia. Alcune quantità si scalano, altre restano fisse, e questa distinzione va decisa ricetta per ricetta.
Immagini generate con l'IA e dichiarate come tali
Le immagini delle ricette sono generate con l'intelligenza artificiale e l'app lo dichiara. Fotografare quattrocento piatti non era realistico, ma spacciare un'immagine sintetica per una fotografia sarebbe stato scorretto verso l'utente.
Bianca in chat e la stima dei valori da una foto del piatto
Bianca è l'assistente in chat dell'app. Serve per le domande che nascono davanti al piatto: sostituire un alimento con un altro, capire quanto pesare una porzione, sapere se una variazione manda fuori strada la giornata. È qui che l'interfaccia conversazionale ha senso, perché la domanda dell'utente resta imprevedibile e non entra in un menu.
La funzione più vistosa è la stima di calorie e macronutrienti a partire da una foto del piatto. Funziona bene quando il piatto è singolo, illuminato in modo decente e composto da alimenti riconoscibili. Funziona peggio con i piatti misti, con i condimenti invisibili e soprattutto con le quantità: da una fotografia si distingue cosa c'è, molto meno quanto ce n'è, e l'olio a crudo non si vede.
Per questo la stima da foto è dichiarata come stima e resta modificabile a mano. La tentazione, quando una funzione impressiona in demo, è presentarla come misura. Sarebbe un errore su due fronti: tecnico, perché il margine di errore è reale, e di responsabilità, perché in ambito alimentare un numero mostrato con troppa sicurezza viene preso per buono. Preferiamo un'app che dice "circa" e permette di correggere, piuttosto che una che sbaglia con convinzione.
Le scelte tecniche dietro l'app per dieta personalizzata
Ogni voce qui sotto nasce da un vincolo concreto che abbiamo avuto davanti mentre sviluppavamo, e spiega quale.
App Android nativa
L'app è nativa e per ora solo su Android. La versione iOS è annunciata ma senza data. Concentrare il lavoro su una piattaforma sola permette di rilasciare aggiornamenti con una frequenza che due codebase parallele avrebbero reso impossibile.
Abbonamenti gestiti con RevenueCat
La gestione degli abbonamenti, con rinnovi, periodi di grazia, rimborsi e stati intermedi, è un sottosistema a sé. Delegarla a RevenueCat significa non riscrivere logica di fatturazione dentro l'app e avere lo stato dell'utente coerente tra dispositivo e backend. Premium costa 6,99 euro al mese o 34,99 euro all'anno tramite Google Play.
Firebase come backend
Authentication, Firestore, Hosting e Analytics coprono autenticazione, persistenza e distribuzione senza server da amministrare. Su un prodotto proprietario che portiamo avanti internamente, il tempo speso in manutenzione infrastrutturale è tempo sottratto alle funzioni.
React 18, Vite e Tailwind per il sito
Il sito diet-app.it è costruito con React 18, Vite, Tailwind, react-router e react-helmet-async. È lo strumento di acquisizione, quindi deve essere veloce da modificare e leggero da caricare.
Prerendering statico e dati strutturati
Una single page application vuota non è una buona base per la ricerca organica. Il sito viene prerenderizzato in HTML statico e i contenuti sono descritti con JSON-LD, così ogni pagina arriva ai motori già compilata invece di dipendere dall'esecuzione dello script.
Diario e tracciamento del peso
Il diario alimenta il ricalcolo: senza i dati che raccoglie, il piano resta fermo al profilo iniziale. Senza uno storico affidabile del peso, ogni aggiornamento del piano sarebbe basato su un unico valore momentaneo.
Domande frequenti su DietApp
L'app è freemium: si può usare senza pagare e la versione Premium si attiva a 6,99 euro al mese o 34,99 euro all'anno tramite gli abbonamenti Google Play. La gestione dei rinnovi e delle disdette avviene nel Play Store, come per qualsiasi abbonamento acquistato su Android.
Dal profilo dell'utente, cioè età, peso, altezza, livello di attività e obiettivo, l'app calcola il fabbisogno con una logica deterministica. Il modello generativo compone i pasti dentro quel budget, rispettando gli alimenti esclusi, e il risultato viene verificato contro il ricettario prima di essere mostrato.
Sì, gli alimenti esclusi si impostano nel profilo e funzionano come filtro sui dati strutturati delle ricette, non come semplice indicazione testuale al modello. Resta comunque necessario leggere le etichette dei prodotti acquistati e, in caso di allergie diagnosticate, confrontarsi con il proprio medico.
No, al momento DietApp è disponibile solo su Android tramite Google Play. Una versione iOS è annunciata ma non ha ancora una data di rilascio.
No. DietApp non è un dispositivo medico, non formula diagnosi e non promette risultati. Genera proposte alimentari a partire dai dati inseriti dall'utente e riporta disclaimer espliciti che invitano a rivolgersi a un professionista sanitario, soprattutto in presenza di patologie, in gravidanza o in età pediatrica.