I 5 tipi di software che puoi creare con l'IA

TL;DR — Non tutte le idee appartengono a un App Store. La maggior parte dei prodotti di cui hai davvero bisogno rientra esattamente in cinque forme tecniche: un tool locale, una web app, un'app nativa, un servizio in background o un progetto hardware. Riconoscere la forma giusta ti fa risparmiare mesi di sviluppo errato e determina se puoi iniziare in mezz'ora con un AI builder in hosting o se devi combinare un coding agent con Supabase e Vercel. Per i solopreneur (in Italia e in Europa), la web app è quasi sempre il primo passo giusto — il resto è più raro, ma a volte senza alternative.

Il problema: Sai cosa vuoi, ma non sai come ottenerlo

La maggior parte delle persone che si cimentano con gli AI builder non si blocca sul codice. Si blocca per la confusione su dove iniziare. Sa più o meno cosa vuole migliorare — un foglio di calcolo inaffidabile, un processo che deve essere spiegato da capo ogni trimestre, un'informazione che vive online ma non arriva mai a destinazione. Ma se questo debba tradursi in uno script, un sito web o un piccolo dispositivo hardware, è tutto da capire.

È proprio qui che inizia il vero lavoro: descrivere il cambiamento desiderato in modo tale da poterne ricavare la forma tecnica — prima ancora che un modello scriva una singola riga di codice. In un video molto discusso su YouTube, questo viene illustrato con l'esempio di due progetti: un tracker per traghetti ad Amsterdam, che intercetta il segnale radio AIS (richiesto per legge) delle navi con un Raspberry Pi, un'antenna e un ricevitore per un totale di circa 200 euro, per arrivare finalmente in orario al molo; e un'app per la manutenzione domestica, costruita esclusivamente per un singolo appartamento — i suoi elettrodomestici, le sue piante, il suo giardino — che genera automaticamente le mansioni di manutenzione per la settimana.

Nessuno dei due è un software "fancy" (sofisticato). Sono piccoli, specializzati e si adattano alla vita di una sola persona, esattamente come nessuna app di massa potrebbe mai fare. Questo è il cuore del Personal Software — ed è proprio per questo che ti serve una mappa delle cinque forme.

La partenza: Cinque domande prima del codice

Prima di scegliere un tool, rispondi a queste cinque domande. Decideranno la forma del progetto molto più di qualsiasi scelta del modello AI:

• Che cambiamento desideri? Non "un'app", ma: cosa deve sembrarti tangibilmente diverso nella vita di tutti i giorni?
• Da dove proviene il segnale? L'informazione si trova nel mondo reale (radio, sensore, telecamera), in un file, in un'API — o è solo nella tua testa?
• Dove deve apparire il risultato? Sul telefono, sul monitor della scrivania, su un display in cucina, o non deve essere affatto visibile?
• Chi può visualizzare e modificare? Solo tu? Un partner? Un team? Questo determina se hai bisogno di un login e di permessi.
• Cosa succede se il sistema fallisce? È solo fastidioso ma innocuo, oppure è un problema critico per la sicurezza? Questo scala enormemente l'impegno richiesto.

Queste domande forniscono quasi già la risposta: un progetto che riceve un segnale fisico e mostra il risultato localmente diventerà un progetto hardware. Un progetto in cui due persone devono mantenere sincronizzata la stessa lista su due telefoni è una Web App con un database condiviso.

Le cinque forme in sintesi

1. Il tool locale: Il percorso più semplice

Un tool locale gira su un singolo computer e lavora con file o con un piccolo database locale (spesso SQLite). È in assoluto il percorso più semplice per tutto ciò che usi solo tu — un organizzatore di documenti, un tool di ricerca privato, un'utility che rinomina e ordina mille foto. Non ha bisogno di un sito web, di un login o di un host. Sostanzialmente dici al Coding Agent: "Installati sul mio portatile e costruisci questo" — e hai finito.

Quando sceglierlo: Quando l'informazione rimane privata, vive su una sola macchina e nessun altro essere umano avrà mai bisogno di accedervi. In questo caso, qualsiasi infrastruttura cloud è puro overhead.

2. La Web App: Il tuo default per il Personal Software

La Web App si apre da un link, gira nel browser e può essere salvata sulla schermata home del telefono. È il default consigliato per la maggior parte dei progetti personali, a meno che tu non abbia un motivo specifico per rendere le cose più complicate. Una singola versione funziona su laptop, iPhone e Android. Puoi condividerla con partner o colleghi senza dover passare per un App Store o procurarti un "account sviluppatore" presso Apple.

L'architettura tipica per un'app del genere è semplice: un backend Supabase condiviso (database Postgres + Login + Storage per i file), la Web App vera e propria e Vercel come host, che ti fornisce link di anteprima prima di sovrascrivere la versione live. È esattamente questa combinazione — Web App + database condiviso + host — a rendere possibile l'esempio della manutenzione domestica: due persone vedono la stessa lista aggiornata su due telefoni diversi.

Importante per la scelta del database: Gli Hosted Builder come Lovable ti chiederanno in seguito se i dati devono risiedere nel loro backend cloud gestito o in Supabase. Il cloud del builder è la strada più breve; Supabase richiede un po' più di configurazione iniziale, ma mantiene database e autenticazione in uno standard Postgres ampiamente utilizzato — salvando la tua portabilità. La regola d'oro: Cambia presto l'interfaccia, non i dati. Migrare un'app tra qualche anno è molto più difficile che costruirci sopra una nuova interfaccia grafica.

3. L'App Nativa: Solo se il telefono richiede di più

Questo è ciò che la maggior parte delle persone intende con la parola "App" — Apple ha allenato questo termine per anni. Ma richiede molto più lavoro. Ne hai bisogno solo se il tuo prodotto dipende da una funzione profonda del telefono: notifiche push affidabili, Bluetooth, geolocalizzazione in background, NFC o se vuoi distribuirla esclusivamente tramite gli App Store. Altrimenti, non fare il grande salto.

La strada più pratica è un Coding Agent con Expo: da un unico progetto ottieni un'app iOS e Android, e un servizio di build gestisce gran parte della firma e della pacchettizzazione. Avrai comunque bisogno di account sviluppatore Apple e Google e dovrai superare le loro revisioni — un processo reale e piuttosto laborioso. Per questo vale la regola: Dimostra prima la tua idea come Web App privata, a meno che le capacità specifiche dello smartphone non siano inseparabili dalla tua idea. Non vorrai certo pagare la "tassa" dell'App Store solo per scoprire se al tuo partner piace davvero usare la lista delle manutenzioni.

4. Il servizio in background: Software senza schermo

Un servizio in background potrebbe non avere alcuna interfaccia utente (UI). Si sveglia — in base a una programmazione oraria o a un evento —, esegue il suo compito e invia il risultato da qualche parte. Controlla un dataset pubblico ogni mattina, elabora un file non appena viene caricato, oppure invia un allarme se un sensore supera una certa soglia. In sostanza, è un passo di trasformazione: preleva i dati da una fonte e li consegna a una destinazione. Tali servizi spesso non hanno bisogno di un "feeling di prodotto", ma richiedono una logica di innesco pulita e un luogo in cui far atterrare il risultato (email, chat, database).

5. Il progetto hardware: Il software più vicino possibile al mondo reale

Qui il software vive il più vicino possibile al mondo fisico: il ricevitore per traghetti AIS, un display sul tavolo della cucina, una telecamera, un sensore industriale. La scelta del piccolo computer dipende dal compito:

• Raspberry Pi — un piccolo computer multiuso, ideale se un ricevitore o un'antenna ha bisogno di un decodificatore sempre in esecuzione.
• ESP32 — perfetto se il compito è quasi esclusivamente "leggere un sensore" o "accendere un dispositivo".
• Home Assistant — il punto di ingresso più veloce se i dispositivi esistono già in casa e vuoi solo integrarli in un unico posto.

La leva decisiva: più ti avvicini ai sensori esistenti di una normale Smart Home, meno dovrai costruire da zero e più potrai semplicemente cablare componenti off-the-shelf. E poiché i moderni Coding Agent sono ora in grado di leggere foto di circuiti stampati e componenti, identificare connessioni, spiegare i pin e verificare il tuo setup, il confine tra uno sviluppatore software e un esperto hardware non è mai stato così sottile.

Le due strade: Hosted Builder vs. Coding Agent

Una volta definita la forma, le scelte dei tool diventano quasi banali. Hai essenzialmente due famiglie a disposizione:

L'Hosted Builder (Lovable, Replit, Bolt) è la strada più veloce per la primissima Web App: descrivi il software, il builder crea il progetto, ti mostra un'anteprima e ti dà un pulsante per pubblicare. Non installi linguaggi di programmazione, non avvii server, non devi nemmeno capire la riga di comando — eppure ottieni qualcosa di funzionante. Se il progetto richiede più di una semplice interfaccia web (scripting Python, un server sempre attivo, job programmati, una build mobile), Replit è il candidato più forte, perché impacchetta gran parte dell'infrastruttura in un servizio. Bolt è un'altra ottima via per una Web App full-stack rapida.

Il Coding Agent è il livello successivo — eppure non è riservato solo agli utenti avanzati: Codex o Claude Code vedono i file del tuo progetto, li modificano, avviano l'app localmente, leggono gli errori e ci riprovano. A questo si aggiungono GitHub Desktop per il controllo di versione visivo, Supabase per il database condiviso e Vercel per la fase di pubblicazione. Il grande vantaggio: Puoi scambiare un singolo componente senza dover scambiare tutto. Il modello AI può cambiare, mentre il database rimane. L'host può cambiare, mentre il codice resta. L'interfaccia può cambiare senza spostare i dati — è solo un'altra finestra sulla stessa stanza.

Modello ≠ Coding Agent ≠ Builder — e perché è importante

Spesso le persone confrontano questi tre elementi come se fossero lo stesso prodotto. Non lo sono. La stratificazione è chiara:

• Il Modello è il puro livello di ragionamento e di capacità di programmazione.
• Il Coding Agent fornisce al modello l'accesso a una cartella, ai comandi, alle anteprime e agli strumenti.
• L'Hosted Builder impacchetta Agent + Ambiente + Pulsante di pubblicazione in un unico prodotto.

Da questa stratificazione deriva una grande libertà: Modello e ambiente di lavoro non devono necessariamente provenire dalla stessa azienda. Puoi utilizzare un modello aperto come GLM 5.2/5.3 tramite uno stack di coding tool supportato. Per la primissima build: Scegli un solo ambiente, non tre. La vera libertà non deriva dal far litigare tre modelli su ogni pulsante, ma dal fatto che tu possiedi i file del progetto, i dati e le decisioni — sapendo esattamente cosa sta facendo il modello.

Come mantenere il modello sulla giusta strada: Quattro piccoli file

L'errore più comune quando si costruisce con l'IA non riguarda il codice, ma le decisioni nascoste. Il modello sceglie improvvisamente un database con cui ha familiarità senza dare spiegazioni, aggiunge un servizio a pagamento o rende pubblica l'app. La soluzione non risiede in prompt magici o narrativi, ma in un cambio di ruolo: il modello deve agire come un partner di sviluppo che motiva e rende trasparenti le sue decisioni. All'atto pratico, questo significa mantenere quattro piccoli file di testo accanto al progetto, che ogni modello può leggere:

• project.md — per chi è il software, cosa succede oggi senza l'app, cosa dovrebbe succedere invece (Prima/Dopo), dove deve essere eseguita e quali informazioni devono rimanere private.
• decisions.md — ogni volta che il modello fa una scelta che influenza costi, dati, accessi, deployment o portabilità, deve registrare qui le opzioni valutate, la sua raccomandazione e la motivazione — specialmente se la decisione è stata presa insieme a te.
• scenarios.md — le situazioni reali che il software deve gestire (es. "Registrare un apparecchio tramite foto dal telefono, trovare il manuale corrispondente, generare il prossimo task di manutenzione"). Questi casi reali sono i tuoi casi di test.
• agent.md / claude.md — il breve file di istruzioni per il Coding Agent specifico. Dice solo come deve comportarsi lo strumento in uso; le verità permanenti del progetto rimangono nei primi tre file.

# agent.md
Agisci come un partner di sviluppo che deve giustificare le proprie decisioni.
Quando una scelta riguarda costi, dati, privacy, portabilità, deployment 
o manutenzione: spiegalo in modo semplice e chiaro.
- Fornisci 2-3 opzioni realistiche.
- Raccomandazione: scegline una per questo progetto e motivala.
- Indica cosa sarà più facile / più difficile cambiare in futuro.
- Chiedi il permesso prima di fare azioni pubbliche, costose o distruttive.
- Nessun secret (chiavi API) nel codice, negli screenshot o nelle chat.

# project.md (Esempio)
Obiettivo: App per la manutenzione di un singolo appartamento.
Prima: Promemoria su post-it, nessuna visione condivisa.
Dopo: entrambi i partner vedono la stessa lista su due telefoni.
Esecuzione: nel browser, privata, solo 2 login.
Dati Privati: Numeri di serie, foto della casa, link ai manuali.

Sicurezza: privato prima di pubblico, controllo nel backend

Le regole di sicurezza sembrano tante, ma sono semplici:

• Privato di Default. Rendi l'app pubblica solo quando hai davvero bisogno di un accesso pubblico — e a quel punto usa un sistema di login gestito (Managed Login). Non inventarti da zero lo storage delle password quando le soluzioni esistono già.
• I Secret rimangono fuori. Le chiavi API e le password vanno inserite nelle impostazioni dei Secret del tuo host (es. Vercel), mai nel codice visibile, negli screenshot, nelle trascrizioni delle chat o su GitHub.
• Controllo degli accessi nel backend, non nella UI. "Nascondere un pulsante" non è un controllo dei permessi. Il fatto che il tuo partner non possa leggere i dati di un altro utente deve essere applicato a livello di database. Supabase è eccellente in questo (tramite la Row-Level Security) — ed è proprio questo l'errore più comune e grave quando due persone o nuclei familiari usano lo stesso prodotto.
• Dimostra Backup + Ripristino. Se i dati sono importanti: fai un backup e testa il ripristino. Per pagamenti, informazioni sui minori, dati medici o legali: fai controllare il software a un esperto prima di utilizzarlo.
• Non iniziare con dati sensibili. Inizia dalle cose semplici e passa ad app più sicure man mano che il tuo profilo di rischio cresce.

Testing: Nessun "finito" senza una stretta di mano reale

All'inizio non hai bisogno di un vocabolario tecnico per i test. Ti servono le situazioni reali che ti riguardano, messe per iscritto — per poi testarle sul dispositivo su cui girerà effettivamente il software, e vedere se funziona. Nel caso dell'esempio domestico, questo significa: Riesco a fotografare un elettrodomestico e creare la scheda corretta? Il numero di modello viene salvato? Il mio partner vede la stessa lista? Cosa succede se la foto è illeggibile? Testa anche gli "unhappy path" (i casi di errore o imprevisti).

E la frase più importante di tutte: non c'è alcun sostituto per un essere umano che dice: Questo funziona davvero. Non puoi semplicemente chiedere a Lovable, Codex o Claude Code di "testare se tutto funziona" e poi fidarti alla cieca. Il modello fornisce un risultato, non una garanzia.

La tua prima ora — come inizio io

Se vuoi iniziare ora:

1. Scrivi quella cosa che avresti voluto costruire da anni.
2. Descrivi come appare oggi (il problema) e come dovrebbe apparire invece (la soluzione).
3. Identifica il segnale o l'informazione che rende possibile la soluzione.
4. Determina dove deve apparire il risultato (su quale schermo e perché) e chi può vederlo.
5. Chiediti: Cosa succederebbe di male se fallisse o si rompesse?

Poi torna indietro e scegli la forma del tuo progetto. Per la primissima Web App privata con un setup minimo: Lovable — usando il loro cloud gestito, a meno che tu non sappia già che la portabilità dei dati ti è fondamentale (in tal caso, usa Supabase dal giorno 1). Se vuoi un maggiore controllo, apri Codex o Claude Code. Se c'è di mezzo un sensore fisico: Raspberry Pi, Home Assistant o ESP32 — e lascia che il Coding Agent lavori sui cablaggi.

Conclusione: La forma è metà dell'opera

Il livello che la maggior parte delle persone trascura non è il modello o il builder — è la domanda cruciale prima di scrivere il primo codice: in quale delle cinque forme rientra il tuo desiderio? Una volta stabilita la forma, le scelte dei tool diventano quasi ovvie, le questioni di sicurezza chiare e la prima build è fattibile in ore invece che in mesi. L'era del Personal Software non appartiene più solo ai tecnici che vivono vicino ai prodotti — appartiene alle persone che vivono vicino ai loro personali problemi. E sono proprio loro a sapere meglio di chiunque altro cosa gli manca.

FAQ

Per il Personal Software ho davvero bisogno di una Web App?

Non automaticamente — ma nella maggior parte dei casi la Web App è il punto di partenza più veloce, economico e portabile, perché una singola versione funziona sia su laptop che su telefono e può essere condivisa senza passare per un App Store. Scegli un tool locale se i dati devono rimanere strettamente privati su una singola macchina, e passa a un'App Nativa solo quando hai realmente bisogno di funzioni profonde del telefono come Push, Bluetooth, Geolocalizzazione in background o NFC. Se sei in dubbio: inizia con una Web App per convalidare l'idea prima di impelagarti nei processi (e nei costi) degli App Store.

Qual è la differenza tra un Coding Agent e un Hosted Builder?

Il Coding Agent (es. Codex, Claude Code) lavora direttamente nei tuoi file di progetto, vede gli errori, avvia l'app localmente e modifica il codice, mentre un Hosted Builder (Lovable, Replit, Bolt) raggruppa ambiente di sviluppo, database, autenticazione e pubblicazione in un unico servizio. La conseguenza pratica: con l'Agent, ogni componente rimane sostituibile — il modello, l'host e l'interfaccia possono cambiare in modo indipendente, mentre i tuoi dati restano fermi. Con l'Hosted Builder ottieni il percorso più breve dalla descrizione all'interfaccia finita, ma paghi il prezzo di un maggiore vincolo (lock-in) alla piattaforma.

Come faccio a impedire al modello di impormi decisioni a sorpresa?

Cambiando il suo ruolo: il modello deve agire come un partner di sviluppo che è tenuto a rivelare le sue decisioni, invece di nasconderle silenziosamente nel codice. Concretamente, tieni aggiornati quattro piccoli file — project.md (obiettivo, prima/dopo, privacy), decisions.md (ogni scelta con impatto su costi/dati/deploy + la motivazione), scenarios.md (i tuoi casi di test reali) e agent.md/claude.md (regole di comportamento per il tool attuale) — e pretendi che il modello indichi due o tre opzioni per ogni scelta critica, ne raccomandi una e ti chieda sempre il permesso prima di eseguire azioni pubbliche, costose o distruttive.

Vale la pena creare un'App Nativa per un tool interno?

Per un tool interno, nella stragrande maggioranza dei casi è sovradimensionato, perché le revisioni degli App Store, gli account sviluppatore Apple e Google e la firma delle app richiedono procedure burocratiche e tempi di cui non dovresti aver bisogno. Una Web App nel browser o una build interna con Expo per la tua famiglia coprono gli stessi casi d'uso, senza l'attrito degli store. Scegli un'App Nativa solo se il tuo prodotto è funzionalmente legato a una capacità profonda dello smartphone a cui non puoi rinunciare — altrimenti, la Web App fornirà la stessa funzione con una frazione dello sforzo.

Come mi assicuro che due famiglie/utenti non si vedano a vicenda in un'app condivisa?

Il controllo degli accessi (Access Control) va gestito nel backend, non nell'interfaccia — nascondere un pulsante non è una vera restrizione di sicurezza. Imponi il confine a livello di database (con Supabase puoi usare la Row-Level Security o meccanismi equivalenti), in modo che un login possa leggere o modificare esclusivamente i record della propria famiglia, e aggiungi questo limite come uno dei casi di test nel tuo file scenarios.md. Inoltre, evita di confondere l'errore "sembra finito" con "è sicuro": verifica attivamente che un secondo utente non possa vedere i dati del primo prima di distribuire il prodotto a più parti.

Posso usare un modello aperto come GLM in un coding tool?

Sì — il modello e l'ambiente di lavoro non devono necessariamente provenire dalla stessa azienda, e questa è una delle più grandi libertà nel tooling IA odierno. Puoi far girare un modello aperto come GLM 5.2 o 5.3 attraverso uno stack di coding supportato usando una chiave API, mantenendo contemporaneamente il controllo su ambiente, dati e deployment. Per la primissima build, tuttavia, ti consiglio di scegliere un unico ambiente anziché riempire un progetto con più modelli — la libertà deriva dal possesso dei file e dei dati, non dall'impiego simultaneo di tre agenti diversi.

Fonti

• Video che analizza sistematicamente le cinque forme di software: "Nobody Laid Out The Five Kinds Of Software You Can Make. So I Did." — https://www.youtube.com/watch?v=joRXo6x7Pgk
• Lovable (AI builder in hosting per Web App): https://lovable.dev
• Replit (Builder con un'infrastruttura più solida): https://replit.com
• Bolt (Web App full-stack veloci): https://bolt.new
• Supabase (Postgres + Auth + Storage): https://supabase.com
• Vercel (Hosting e link di anteprima): https://vercel.com
• GitHub Desktop (Controllo di versione visivo): https://desktop.github.com
• Raspberry Pi (Piccolo computer multiuso): https://www.raspberrypi.com
• ESP32 (Dispositivo a sensore singolo): https://www.espressif.com
• Home Assistant (Integrazione centrale per dispositivi domestici esistenti): https://www.home-assistant.io
• Expo (Un solo progetto → iOS + Android): https://expo.dev
• Codex (Coding Agent): https://openai.com/index/introducing-codex/
• Claude Code (Coding Agent): https://www.anthropic.com/claude-code
• GLM 5.2 / 5.3 (Modelli aperti di Z.ai): https://z.ai
• SQLite (Database locale): https://sqlite.org