LA MAPPA.
OGNI APP, IN TRE FASI.
Partiamo da un problema reale e lo trasformiamo in un’idea di app. Mai il foglio bianco: scegliamo insieme il caso più utile.
Un problema messo a fuoco e un’idea chiara da costruire.
Apriamo l’app “dietro”: cosa fa, con quali passi, quali input e output. Scriviamo il processo prima di scrivere il codice.
Il processo dell’app, nero su bianco. Questo è il vero metodo.
Costruiamo dal vivo con Lovable e Claude Code, poi proviamo i passaggi importanti e sistemiamo quello che non funziona. Vedi tutto il processo, senza tagli.
Una demo funzionante che hai visto nascere passo passo.
QUATTRO STAZIONI.
- [SETTIMANA 1]Serata 1 · Idea + progettazioneSerata 2 · Costruzione + prova
PROBLEMA + BRIEF
Dal problema misurabile a un brief che l’AI può usare davvero.
- IDEA
Partiamo da un attrito reale, non dalla soluzione che ti è già venuta in mente. Misuriamo tempo perso, frequenza, conseguenza e persona coinvolta.
Esempio: “ogni lunedì copio dati da tre file per due ore” è un problema; “voglio una dashboard” è già una soluzione.
> problema: 2 ore/settimana a copiare dati > utente: team commerciale > conseguenza: dati scollegati
→ il problema messo a fuoco - PROGETTAZIONE30’
Trasformiamo il problema in brief: obiettivo, target, input, output, vincoli e journey. Questo è il progetto prima della schermata.
Esempio: input = tre file aggiornati → output = una vista unica con priorità e prossima azione.
# brief input -> dati sparsi output -> vista unica + priorità vincoli -> dati aggiornabili
→ il processo dell’app, scritto - COSTRUZIONEprima versione
Creiamo una prima interfaccia con l’AI e controlliamo che rispetti il brief iniziale.
Esempio: prima versione troppo generica → aggiungiamo campi, regole e uno stato del flusso.
$ crea la prima interfaccia dal brief ✓ confronto con output atteso → fix dei punti mancanti
→ brief + prima interfaccia
ProblemaBriefUser journey - [SETTIMANA 2]Serata 1 · Idea + progettazioneSerata 2 · Costruzione + prova
DATI + MEMORIA
Come un’app salva, recupera e collega le informazioni utili.
- IDEA
Guardiamo cosa succede quando un dato sparisce al refresh: una schermata senza memoria non basta per avere un’app utile.
Esempio: un brief scritto oggi deve essere ancora disponibile domani, senza ricopiarlo.
> azione: salva brief > bisogno: ritrovarlo dopo > domanda: dove vive il dato?
→ il dato che vale la pena ricordare - PROGETTAZIONE30’
Separiamo front end, back end e database. Decidiamo quali campi servono, come si chiamano e quali dati devono essere collegati.
Esempio: cliente, pagamento e follow-up sono tabelle diverse che devono parlarsi.
# dati cliente -> id, nome, email pagamento -> cliente_id, stato follow-up -> cliente_id, data
→ il processo dell’app - COSTRUZIONE
Costruiamo un flusso che salva e rilegge il dato, poi controlliamo che la memoria risponda anche dopo una nuova sessione.
Esempio: salvo un brief, ricarico la pagina e ritrovo l’ultimo progetto nella dashboard.
$ salva il brief ✓ dato nel database ✓ ultimo brief visibile dopo refresh
→ flusso dati funzionante
Front endBack endDatabase - [SETTIMANA 3]Serata 1 · Idea + progettazioneSerata 2 · Costruzione + prova
API + SERVIZI ESTERNI
Dalla voce ai dati esterni: chiamate precise, risposte utili e costi sotto controllo.
- IDEA
Capisci cosa può fare un servizio esterno al posto della tua app: trascrivere, generare, cercare dati, inviare una mail o verificare un pagamento.
Esempio: un audio entra, un servizio lo trascrive e l’app usa il testo per compilare un brief.
> input: audio > servizio: trascrizione > output: testo strutturato
→ il task da delegare - PROGETTAZIONE30’
Disegniamo request e response: cosa mandiamo, cosa torna, quale chiave serve e dove resta protetta.
Esempio: invio un audio, ricevo testo; invio testo e criteri, ricevo un brief in sei campi.
# chiamata API request -> audio + chiave response -> testo uso -> compila il brief
→ il modello dati + automazioni - COSTRUZIONE
Colleghiamo un servizio in un flusso reale, proviamo i casi importanti e misuriamo costo, errore e risultato prima di usarlo in produzione.
Esempio: autorizzo il microfono, registro, trascrivo e mostro all’utente un messaggio utile se qualcosa non funziona.
$ registro audio ✓ autorizzazione ✓ trascrizione → fallback se la chiamata fallisce
→ integrazione utile + test
APITokenAutomazioni - [SETTIMANA 4]Serata 1 · Idea + progettazioneSerata 2 · Costruzione + prova
BUILD + SMOKE TEST
Il tuo caso reale, costruito e verificato con il metodo delle settimane precedenti.
- IDEA
Porti un tuo caso oppure ne scegliamo uno insieme. Lo riduciamo a una versione costruibile senza perdere il problema da cui sei partito.
Esempio: cinque domande chiave per capire problema, utente e risultato atteso.
> problema: __________ > utente: __________ > output: __________
→ caso pronto da costruire - PROGETTAZIONE30’
Definiamo il flusso: interfaccia, dati, eventuali servizi esterni e risultato visibile per chi usa l’app.
Esempio: scomponiamo il progetto negli stessi blocchi visti nelle settimane precedenti.
# flusso input -> ? dati -> ? output -> ? vincoli -> ?
→ flusso pronto da costruire - COSTRUZIONE
Costruisci con noi a fianco, poi esegui uno smoke test sui flussi essenziali: accesso, salvataggio, risposta e gestione degli errori.
Esempio: supporto sui punti difficili e correzioni prima della demo finale.
$ costruisci la demo ✓ flussi base ✓ correzioni → prossimi passaggi definiti
→ demo personale testata
CostruzioneControlli essenzialiCorrezioni
ALLA FINE DELLA MAPPA.
costruita su un problema reale
le 3 fasi che funzionano su ogni idea
recap, mappe e micro-compiti tra le lezioni
L'AI
NON SERVE
a niente
SE NON LA SAI USARE.
Il problema non è aprire ChatGPT. Il problema è farci qualcosa di utile.
Parti da un processo reale. Lo trasformi in brief, dati, flusso e una prima versione funzionante. → Impari a costruirla e testarla in aula.