Vibe Coding: La Guida Definitiva per Costruire una SaaS Completamente Funzionante con Antigravity e Claude Code, dalla Progettazione alla Sicurezza fino al Deployment e alla Monetizzazione

→ (Sezione AI – Adattiva)

Esiste un momento preciso in cui una tecnologia smette di essere un privilegio riservato a chi sa scrivere codice e diventa uno strumento alla portata di chiunque abbia la visione giusta e la volontà di imparare un nuovo modo di costruire. Quel momento, per quanto riguarda la creazione di prodotti software veri e propri, è adesso. Non stiamo parlando di landing page statiche o di semplici automazioni: stiamo parlando di applicazioni SaaS completamente funzionanti, con autenticazione degli utenti, database persistente, integrazione dei pagamenti, logica di business complessa e standard di sicurezza professionali. Costruite in una giornata. Da chi non ha mai scritto una riga di codice in vita propria.

Il vibe coding non è un termine tecnico, ma descrive qualcosa di molto preciso: un approccio alla costruzione di software in cui l’intelligenza artificiale gestisce tutta la complessità tecnica dell’implementazione, mentre tu ti concentri su ciò che conta davvero, ovvero la visione del prodotto, la qualità del risultato, la logica del business e la strategia di mercato. È l’equivalente digitale di essere un regista: non devi saper manovrare ogni singola telecamera o mixare ogni singola traccia audio, ma devi sapere con assoluta chiarezza cosa vuoi vedere sullo schermo alla fine.

In Adattiva crediamo che la padronanza tecnologica sia sempre inseparabile dalla chiarezza strategica, e questo approfondimento nasce con un obiettivo duplice: darti tutti gli strumenti pratici per costruire una SaaS reale, funzionante e sicura, e darti anche la prospettiva di business necessaria per trasformarla in qualcosa che generi valore economico reale, non solo un esperimento tecnico interessante. Quello che costruiremo insieme in questo percorso è una piattaforma B2B per l’estrazione di lead qualificati con generazione automatica di icebreaker personalizzati tramite intelligenza artificiale, completa di landing page professionale, sistema di autenticazione, integrazione con Stripe per i pagamenti e database persistente.

L’Ambiente di Lavoro: Antigravity, Claude Code e la Logica del Workspace

Prima di costruire qualsiasi cosa, è fondamentale comprendere l’ambiente in cui andremo a lavorare, perché questo ambiente non è semplicemente un editor di testo potenziato: è un sistema integrato che combina la potenza di modelli di intelligenza artificiale diversi, ciascuno ottimizzato per compiti specifici, in un’unica interfaccia coerente e accessibile.

Antigravity è quello che in gergo tecnico viene chiamato IDE, ovvero un ambiente di sviluppo integrato. Ma a differenza degli IDE tradizionali, che erano progettati per sviluppatori esperti che scrivono codice manualmente, questo sistema è stato pensato fin dalla sua concezione per permettere a chiunque di interagire con un agente AI che può leggere, creare e modificare file, eseguire comandi, navigare la struttura di un progetto e produrre risultati concreti attraverso conversazioni in linguaggio naturale.

Il concetto fondamentale da comprendere è quello del workspace, o cartella di lavoro. Tutto ciò che farai, tutto il codice che verrà generato, tutti i file che verranno creati durante il processo di costruzione della tua applicazione, vivrà all’interno di questa cartella. È il tuo progetto, il tuo territorio operativo, e tutto ciò che l’agente AI produce si concretizza fisicamente in file accessibili dal tuo computer. Questo significa che il lavoro che fai non è astratto o virtuale: è codice reale, in file reali, che puoi aprire, leggere, condividere e distribuire.

Quando crei una nuova cartella di lavoro e la apri nell’ambiente, stai essenzialmente dicendo all’agente “questo è il contesto in cui lavoriamo”. Da quel momento, l’agente ha visibilità completa su tutto ciò che si trova in quella cartella e può interagire con ogni suo elemento, dalla creazione di nuovi file alla modifica di quelli esistenti, dall’esecuzione di comandi alla verifica dei risultati.

La Distinzione tra Modelli: Quando Usare Gemini e Quando Usare Claude

Uno degli aspetti che inizialmente può creare confusione riguarda la presenza di più modelli di intelligenza artificiale all’interno dello stesso ambiente. Antigravity integra i modelli di Google, la famiglia Gemini, direttamente nell’interfaccia chat principale, mentre permette anche di utilizzare Claude di Anthropic attraverso un’estensione dedicata. Comprendere quando usare l’uno e quando usare l’altro non è un dettaglio tecnico irrilevante: è una scelta che influisce concretamente sulla qualità dei risultati.

La regola pratica che funziona meglio nella pratica è semplice: usa i modelli Gemini per tutto ciò che riguarda l’aspetto visivo dell’applicazione, ovvero per il cosiddetto frontend, che comprende il design dell’interfaccia, i colori, i bottoni, i layout e tutto ciò che l’utente finale vede e tocca. Usa Claude per tutto ciò che riguarda la logica funzionale e il codice di backend, ovvero per la connessione al database, la gestione dell’autenticazione, le chiamate alle API esterne, i controlli di sicurezza e qualsiasi altra cosa che riguardi il “motore” invisibile dell’applicazione.

Questa divisione non è arbitraria. Nella pratica si osserva che i modelli Google tendono a produrre risultati migliori quando si tratta di manipolare elementi visivi e stilistici, mentre Claude tende a essere più preciso e affidabile quando si tratta di scrivere logica applicativa complessa, gestire la sicurezza e costruire le fondamenta tecniche dell’applicazione. Lavorare con entrambi in parallelo, assegnando a ciascuno il dominio in cui eccelle, permette di ottenere risultati qualitativamente superiori in tempi significativamente più brevi rispetto all’utilizzo di un singolo modello per tutto.

Il File Cloud.md: Il Documento Fondativo di Ogni Progetto

Prima ancora di iniziare a costruire qualsiasi componente della tua applicazione, esiste un passaggio preparatorio che fa la differenza tra un progetto che evolve in modo coerente e uno che si disperde in mille direzioni. Questo passaggio consiste nella creazione di un documento fondativo del progetto, convenzionalmente chiamato cloud.md, che raccoglie tutte le informazioni essenziali su ciò che stai costruendo: la descrizione del prodotto, la tecnologia che utilizzerà, la struttura delle pagine che comporrà, i servizi esterni con cui si integrerà e gli obiettivi specifici che deve raggiungere.

Questo documento non viene scritto manualmente da te: viene generato dall’agente AI sulla base di una conversazione iniziale in cui descrivi ciò che vuoi costruire. Il tuo compito è fornire una descrizione chiara e dettagliata del prodotto: quali funzionalità deve avere, quali pagine deve includere, quali servizi deve utilizzare, quale tipo di utente andrà a servirlo. L’agente traduce questa descrizione in un documento strutturato che diventa la guida di riferimento per tutto il processo di costruzione successivo.

Perché questo documento è così importante? Perché gli agenti AI, per quanto potenti, operano all’interno di contesti. Il documento fondativo è il contesto che permette all’agente di capire non solo cosa deve fare nel singolo passaggio, ma perché lo sta facendo e come si inserisce nel quadro complessivo del progetto. Senza questo contesto, ogni richiesta successiva parte praticamente da zero, senza beneficiare della coerenza accumulata nelle interazioni precedenti.

La struttura tipica di questo documento include una sezione che descrive cosa è il prodotto e a chi è destinato, una sezione che elenca lo stack tecnologico scelto, una sezione che definisce la struttura delle pagine dell’applicazione, una sezione che descrive le integrazioni con servizi esterni, e una sezione che identifica i punti critici e i rischi noti del progetto. Questo ultimo punto è particolarmente prezioso perché permette all’agente di anticipare i problemi invece di affrontarli solo quando si manifestano.

Markdown: Il Linguaggio che Collega Uomo e Macchina

Nel percorso di vibe coding incontrerai frequentemente file con estensione .md, abbreviazione di Markdown, e vale la pena capire cosa sono e perché vengono usati, non per diventare esperti di formattazione, ma per comprendere la logica che sta dietro a questo formato.

Markdown è essenzialmente un sistema di convenzioni testuali che permette di dare struttura e formattazione a un testo usando solo caratteri normali. Un cancelletto seguito da uno spazio crea un titolo principale. Due cancelletti creano un sottotitolo. Un asterisco all’inizio di una riga crea un punto elenco. Due asterischi attorno a una parola la rendono in grassetto.

La ragione per cui questo formato è così utilizzato negli ambienti di sviluppo, e in particolare nei file di istruzione per gli agenti AI, riguarda la sua capacità di essere allo stesso tempo leggibile da un essere umano e facilmente interpretabile da un sistema automatico. Quando l’agente AI legge un file Markdown, non vede solo testo: vede struttura, gerarchia, priorità. Capisce cosa è un titolo e cosa è un dettaglio, cosa è un’istruzione principale e cosa è una nota accessoria.

Nei tuoi progetti di vibe coding, incontrerai file Markdown principalmente in due contesti: i file di configurazione e documentazione del progetto, come il cloud.md di cui abbiamo parlato, e i file di istruzione o regole che guidano il comportamento dell’agente. In entrambi i casi, non è necessario padroneggiare tutte le sintassi possibili: è sufficiente capire che questo formato è il modo in cui tu e l’agente condividete informazioni strutturate.

Regole, Workflow e MCP Server: Personalizzare il Comportamento dell’Agente

Uno degli aspetti più potenti degli ambienti di sviluppo moderni con AI integrata riguarda la possibilità di personalizzare il comportamento dell’agente in modo sistematico e persistente, attraverso tre meccanismi distinti: le regole, i workflow e i server MCP.

Le regole sono istruzioni comportamentali che definiscono come l’agente deve agire in modo generale, indipendentemente dal compito specifico che gli viene assegnato. Possono essere globali, valide quindi per tutti i progetti, oppure locali al workspace corrente. Un esempio pratico di regola globale potrebbe essere una specifica sullo stile visivo da usare sempre quando si crea un’interfaccia utente: colori del brand, tipografia preferita, stile dei bottoni. Con questa regola configurata, ogni volta che chiedi all’agente di creare o modificare qualcosa di visivo, rispetterà automaticamente quelle scelte stilistiche senza che tu debba ripeterle ogni volta.

I workflow sono sequenze di passaggi predefiniti che l’agente esegue automaticamente quando riceve un determinato tipo di richiesta. La differenza rispetto alle regole è che i workflow definiscono un processo, non un comportamento. Un esempio potrebbe essere un workflow che, ogni volta che gli chiedi di fare una ricerca, non solo cerca informazioni generali ma visita anche fonti specifiche che tu hai pre-selezionato come autorevoli per il tuo settore. I workflow eliminano la necessità di ripetere istruzioni procedurali complesse ogni volta che hai bisogno dello stesso tipo di elaborazione.

Gli MCP server, infine, sono integrazioni con servizi esterni che qualcun altro ha già costruito e reso disponibili. Immagina di avere una libreria di superpoteri pronti all’uso: connessioni con piattaforme di pagamento, servizi di analisi dei dati, strumenti di comunicazione, piattaforme di design e molto altro. Collegare un MCP server al tuo ambiente significa dare all’agente la capacità di interagire direttamente con quel servizio, senza che tu debba scrivere codice di integrazione da zero. Per la nostra SaaS, utilizzeremo questa capacità per collegarci a Stripe per i pagamenti.

Modalità Planning e Modalità Fast: Scegliere l’Approccio Giusto

Prima di iniziare qualsiasi sessione di lavoro con l’agente, è importante scegliere consapevolmente la modalità operativa più adatta al tipo di compito da svolgere. Esistono due modalità principali, con caratteristiche e casi d’uso molto diversi.

La modalità Planning è quella da usare per compiti complessi, multi-step, che richiedono una pianificazione prima dell’esecuzione. In questa modalità, l’agente produce prima un piano dettagliato di ciò che intende fare, lo presenta per la tua approvazione, e solo dopo aver ricevuto il via libera procede con l’implementazione. Questo approccio è più lento ma molto più controllato: ti dà la possibilità di verificare che l’agente abbia capito correttamente l’obiettivo prima che inizi a modificare file e produrre codice. Per la costruzione iniziale di una SaaS da zero, è quasi sempre la scelta giusta.

La modalità Fast è quella da usare per compiti semplici e ben definiti, dove l’obiettivo è chiaro e il rischio di fraintendimenti è basso. Rinominare un file, cambiare il colore di un bottone, correggere un singolo errore in una specifica funzione: questi sono i casi d’uso ideali per la modalità Fast. L’agente agisce direttamente, senza presentare piani intermedi, e il risultato arriva molto più velocemente. Man mano che il progetto avanza e le fondamenta sono già costruite, questa modalità diventa quella predominante per i miglioramenti iterativi.

Comprendere quando usare l’una e quando usare l’altra è una competenza che si sviluppa con la pratica, ma la regola base è semplice: se non sei certo di cosa farà l’agente, usa Planning. Se sai esattamente cosa vuoi e il rischio è basso, usa Fast.

Progettare la SaaS: Prima la Struttura, Poi il Codice

Il momento più critico di qualsiasi progetto di sviluppo software non è l’implementazione, ma la progettazione. Questo vale ancora di più nel vibe coding, dove la velocità di implementazione è così alta che potresti ritrovarti con centinaia di righe di codice generate in pochi minuti, scoprendo poi che la struttura di base era sbagliata. Investire tempo nella progettazione iniziale non è una perdita di tempo: è la condizione necessaria per non perdere molto più tempo dopo a correggere scelte sbagliate.

Per la nostra SaaS B2B di estrazione lead, la progettazione si articola in alcuni elementi chiave. Prima di tutto, le pagine: una dashboard principale che mostra i dati aggregati e lo stato degli ordini recenti, una pagina per creare un nuovo ordine in cui l’utente inserisce i parametri di ricerca, una pagina per lo storico degli ordini con tutti i lavori precedenti e il loro stato, e una pagina di dettaglio che mostra i risultati specifici di ogni estrazione con la possibilità di visualizzare gli icebreaker generati e di esportare i dati in formato CSV.

Poi, le integrazioni esterne: il servizio di scraping per l’estrazione dei lead, l’API di Anthropic per la generazione degli icebreaker personalizzati, e il sistema di pagamento per la monetizzazione. Infine, le funzionalità che verranno aggiunte in una seconda fase: autenticazione degli utenti, gestione dei piani di abbonamento, landing page e pagamenti.

Questa scelta di costruire prima il nucleo funzionale e poi aggiungere gli strati di autenticazione e pagamento è deliberata e strategicamente corretta. Verificare che il prodotto funzioni prima di aggiungere la complessità dell’autenticazione permette di validare l’idea di base in modo rapido e di accumulare sicurezza sulla qualità del lavoro prima di introdurre nuove variabili. Ogni strato aggiuntivo che introduci ha il potenziale di rompere qualcosa che funzionava prima: procedere per strati separati e verificare a ogni passaggio è la strategia che riduce al minimo il numero di problemi da affrontare simultaneamente.

Apify: Il Servizio di Scraping che Alimenta la SaaS

Una delle lezioni più importanti che il vibe coding insegna è che costruire tutto da soli non è quasi mai la scelta giusta. Esistono centinaia di servizi specializzati che fanno una cosa sola in modo eccellente, e integrarli nella tua applicazione è quasi sempre più efficiente che reinventare la ruota da zero. Il tuo valore aggiunto non sta nel saper costruire un sistema di scraping di LinkedIn: sta nel capire quale combinazione di servizi esistenti creare per risolvere un problema reale del tuo mercato target.

Per la nostra SaaS, utilizziamo Apify, una piattaforma che mette a disposizione una libreria enorme di scraper già costruiti, testati e mantenuti da sviluppatori specializzati. La piattaforma offre scraper per praticamente ogni fonte di dati pubblica: LinkedIn, Instagram, Google Maps, Amazon, e molti altri. Ogni scraper ha un rating basato sulle recensioni degli utenti, un indicatore del numero di persone che lo utilizzano, e un modello di pricing che può essere a consumo, dove paghi solo quando lo usi, oppure in abbonamento.

Per il nostro caso d’uso specifico, utilizziamo uno scraper specializzato nell’estrazione di lead B2B, che permette di filtrare per titolo professionale, settore aziendale, paese, dimensione dell’azienda, e di validare automaticamente gli indirizzi email trovati. La qualità della fonte dati è importante: la migliore per i lead B2B professionali rimane LinkedIn Sales Navigator, anche se ha un costo mensile significativo. Per iniziare e validare il prodotto, uno scraper più economico è più che sufficiente.

Il modo corretto di integrare un servizio come Apify nel tuo progetto di vibe coding è fornire all’agente AI tre elementi: la documentazione del servizio, un esempio di input reale, e un esempio di output reale. Questo non è un dettaglio tecnico opzionale: è la differenza tra un’integrazione che funziona al primo tentativo e una che richiede dieci iterazioni di correzione. L’agente non conosce a priori la struttura degli input e degli output di un servizio esterno: devi fornirgliela tu, e più è dettagliata, meglio è.

I Linguaggi di Programmazione: Quello che Devi Sapere Senza Diventare uno Sviluppatore

Una delle ansie più comuni di chi si avvicina al vibe coding riguarda la necessità o meno di imparare i linguaggi di programmazione. La risposta onesta è che non devi saperli scrivere, ma devi capire a cosa servono. Questa distinzione è fondamentale: come un regista non ha bisogno di saper operare personalmente ogni macchina da presa, ma deve capire cosa può e cosa non può fare una certa inquadratura, tu non devi saper scrivere codice ma devi capire la logica che sta dietro alla struttura di un’applicazione web.

Esistono tre linguaggi fondamentali che costituiscono lo standard del web, definiti e mantenuti da un consorzio internazionale chiamato World Wide Web Consortium. HTML gestisce la struttura di una pagina: definisce cos’è un titolo, cos’è un paragrafo, cos’è una lista, cos’è un form di input. CSS gestisce lo stile visivo: colori, dimensioni, font, spaziature, animazioni. JavaScript gestisce le funzionalità interattive: cosa succede quando premi un bottone, come vengono caricati i dati senza ricaricare la pagina, come si aggiorna l’interfaccia in risposta alle azioni dell’utente.

La ragione per cui questi tre esistono separati, invece di essere un unico linguaggio, riflette una logica di separazione delle responsabilità che facilita enormemente la manutenzione e l’evoluzione di un’applicazione nel tempo: modificare lo stile non richiede di toccare la struttura, aggiungere funzionalità non richiede di toccare il design.

Al di sopra di questi tre linguaggi base esistono i framework, ovvero strutture pre-costruite che risolvono problemi comuni e permettono di costruire applicazioni complesse senza partire da zero ogni volta. Il framework che utilizziamo in questo percorso si chiama Next.js ed è costruito sopra React, che a sua volta è costruito sopra JavaScript standard. Questo layering è perfettamente normale e non devi capirne i dettagli interni: l’agente AI conosce perfettamente questi strumenti e li utilizzerà correttamente. Quello che devi sapere è che Next.js è lo standard industriale attuale per costruire applicazioni web moderne, ed è il framework su cui i principali modelli AI sono stati addestrati più estensivamente, il che significa che le risposte che ottieni sono generalmente di qualità più alta.

Il Database: Rendere la Memoria Persistente

Una delle prime limitazioni che incontri quando la tua applicazione inizia a funzionare in locale è la mancanza di persistenza dei dati. Ogni volta che chiudi e riapri l’applicazione, tutti i dati inseriti durante la sessione precedente scompaiono. Questo è ovviamente inaccettabile per un prodotto reale: i tuoi utenti devono poter ritrovare i loro dati ogni volta che accedono alla piattaforma.

La soluzione è un database, e il modo più intuitivo per capire cos’è un database è immaginarlo come un foglio Excel sofisticato: una struttura organizzata in righe e colonne dove ogni riga rappresenta un record e ogni colonna rappresenta un attributo di quel record. La differenza rispetto a un foglio Excel sta nella capacità del database di gestire simultaneamente milioni di record, di rispondere a query complesse in millisecondi, di garantire la coerenza dei dati anche quando molti utenti accedono contemporaneamente, e di implementare regole di sicurezza granulari su chi può vedere e modificare cosa.

Esistono due grandi categorie di database. I database relazionali, detti anche SQL, organizzano i dati in tabelle con struttura fissa dove ogni riga ha esattamente gli stessi campi. Sono ideali quando la struttura dei dati è stabile e prevedibile, come nel caso di una tabella utenti con nome, email e password, o una tabella ordini con data, stato e numero di lead estratti. I database non relazionali, detti NoSQL, sono più flessibili nella struttura e permettono di avere record con campi diversi all’interno della stessa collezione. Sono più adatti quando la struttura dei dati è variabile o quando si lavora con dati fortemente gerarchici o non strutturati.

Per la nostra SaaS utilizziamo Supabase, una piattaforma che offre un database PostgreSQL, che è uno degli standard del settore per i database relazionali, con un’interfaccia visiva intuitiva, un sistema di autenticazione integrato e strumenti di sicurezza avanzati. La scelta di Supabase non è casuale: è una delle piattaforme meglio supportate dall’ecosistema AI attuale, il che significa che gli agenti AI hanno accesso a documentazione dettagliata e a esempi di integrazione di alta qualità.

I Sette Problemi di Sicurezza che Devi Conoscere

La sicurezza è probabilmente l’aspetto più sottovalutato da chi si avvicina al vibe coding per la prima volta. Costruire un’applicazione che funziona è una cosa: costruire un’applicazione che funziona in modo sicuro è un’altra, e la differenza può avere conseguenze economiche e reputazionali significative. Non devi diventare un esperto di cybersecurity, ma devi capire i sette problemi più comuni e sapere come gestirli.

Il primo problema riguarda l’esposizione delle chiavi API. Le chiavi API sono le credenziali che la tua applicazione usa per accedere a servizi esterni: la chiave di Stripe per i pagamenti, la chiave di Anthropic per la generazione di testi, la chiave di Apify per lo scraping. Se queste chiavi sono scritte direttamente nel codice dell’applicazione invece di essere conservate in variabili di ambiente protette, chiunque riesca a vedere il codice può usarle a tue spese. La regola è semplice: nessuna chiave API deve mai apparire direttamente nel codice. Devono essere sempre in un file di configurazione separato che non viene mai condiviso o pubblicato.

Il secondo problema riguarda la mancanza di validazione lato server. Quando un utente inserisce dati nella tua applicazione, questi dati vengono elaborati inizialmente nel browser dell’utente. Se il controllo di validità avviene solo a questo livello, un utente malintenzionato può manipolare il processo di validazione dal lato del browser e inviare dati non validi o non autorizzati al server. La soluzione è garantire che tutti i controlli critici avvengano nel server, non solo nel browser.

Il terzo problema riguarda la mancanza di row level security nel database. Questo concetto, fondamentale in Supabase, stabilisce che ogni utente può leggere e modificare solo i propri dati, non quelli degli altri utenti. Senza questa configurazione, un utente che conosce la struttura del database potrebbe teoricamente accedere ai dati di altri utenti.

Il quarto problema riguarda l’autenticazione mancante sulle route API. Ogni pagina e ogni endpoint della tua applicazione deve verificare che l’utente sia autenticato prima di rispondere. Senza questo controllo, chiunque conosca l’indirizzo diretto di una pagina può accedervi senza fare login, bypassando completamente il sistema di autenticazione.

Il quinto problema riguarda la divulgazione di informazioni tecniche negli errori. Quando un’operazione fallisce, l’applicazione non dovrebbe mai mostrare all’utente i dettagli tecnici dell’errore, come percorsi di file, nomi di variabili o struttura del database. Queste informazioni sono preziose per chi vuole attaccare l’applicazione. Gli errori mostrati agli utenti devono essere sempre messaggi generici, mentre i dettagli tecnici devono essere loggati solo internamente.

Il sesto problema riguarda le allucinazioni nei pacchetti e le vulnerabilità delle dipendenze. Quando chiedi all’agente AI di aggiungere una funzionalità che richiede una libreria esterna, c’è il rischio che il modello suggerisca il nome di una libreria inesistente, o il nome leggermente sbagliato di una libreria esistente. Gli hacker sfruttano questo comportamento prevedibile creando pacchetti con i nomi che i modelli AI tendono a inventare, contenenti codice malevolo. La soluzione è verificare sempre l’esistenza e la legittimità di ogni dipendenza esterna prima di installarla.

Il settimo problema riguarda l’assenza di rate limiting. Senza un limite sul numero di richieste che un singolo utente o indirizzo IP può fare in un determinato periodo di tempo, la tua applicazione è vulnerabile ad attacchi di tipo brute force o a utilizzi abusivi che potrebbero generarti costi molto elevati se i servizi che usi fatturano a consumo.

Il Processo Iterativo di Verifica: Delegare con Intelligenza

Uno dei principi più importanti del vibe coding efficace riguarda il modo in cui strutturi il ciclo di lavoro con l’agente. Non si tratta semplicemente di dare un compito e aspettare il risultato: si tratta di costruire un ciclo di delega, verifica e correzione che garantisce progressivamente una qualità sempre più alta.

Il ciclo corretto funziona così: descrivi il compito all’agente in modo preciso e dettagliato, includi nella descrizione anche una modalità di auto-verifica, ovvero chiedigli esplicitamente di testare il risultato dopo averlo implementato e di non considerare il compito completato finché il test non ha dato esito positivo. Questo semplice accorgimento riduce drasticamente il numero di iterazioni manuali necessarie e insegna all’agente a non fermarsi al primo risultato ma a verificare autonomamente la qualità di ciò che ha prodotto.

Per i compiti di sicurezza in particolare, utilizza prompt di audit specifici che istruiscono l’agente a controllare il codice per ogni categoria di vulnerabilità, a produrre un report con risultati per ogni punto e a correggere immediatamente qualsiasi problema trovato. Questo approccio di audit sistematico è molto più efficace delle correzioni spot: garantisce copertura completa su tutta la codebase invece di fidarsi che i problemi siano stati risolti solo dove hai guardato tu.

Tra i concetti più utili da interiorizzare c’è anche quello del bias di posizione nel prompt. Gli agenti AI tendono a prestare maggiore attenzione alle istruzioni che si trovano all’inizio e alla fine di un testo, mentre le informazioni nel mezzo rischiano di ricevere meno peso. Per questo motivo, le istruzioni più critiche devono sempre essere ripetute sia all’inizio che alla fine del prompt, specialmente quando stai fornendo documenti o esempi lunghi in mezzo al testo.

Costruire l’Interfaccia con Dribble: Prendere Ispirazione invece di Inventare

Uno degli errori più comuni nel vibe coding è chiedere all’agente di “creare qualcosa di bello” senza fornire un riferimento visivo concreto. La qualità estetica di un’interfaccia generata da AI senza riferimenti è generalmente mediocre: funzionale ma priva di carattere, coerente ma priva di personalità. La soluzione è sempre partire da un’ispirazione reale.

Dribble è una piattaforma dove designer professionisti pubblicano i loro lavori, organizzati per categoria e stile. Cerca il tipo di applicazione che stai costruendo, sfoglia i risultati, identifica l’estetica che ti convince di più, fai uno screenshot di ciò che ti piace, e fornisci quell’immagine all’agente come riferimento visivo. L’agente non copierà l’interfaccia che vedi, ma si ispirerà allo stile, alla palette di colori, alla tipografia, al modo in cui sono organizzati gli elementi.

Antigravity supporta anche l’utilizzo di immagini annotate: puoi prendere uno screenshot della tua applicazione, disegnarci sopra delle frecce o cerchi per indicare elementi specifici che vuoi modificare, e fornire questa immagine annotata come input. Questo tipo di input visuale è spesso molto più preciso di una descrizione testuale per comunicare modifiche di design, perché elimina l’ambiguità su quale elemento ti stai riferendo.

Il Database Supabase: Configurazione e Prima Integrazione

Una volta completato lo sviluppo del nucleo funzionale dell’applicazione in locale, il passaggio successivo è connettere questa interfaccia a un database persistente. Supabase semplifica enormemente questo processo: crei un progetto sulla piattaforma, ottieni le credenziali di accesso, le fornisci all’agente insieme alla struttura dei dati che vuoi conservare, e l’agente si occupa di creare le tabelle appropriate e di aggiornare il codice dell’applicazione per usarle.

Per la nostra SaaS, le tabelle fondamentali sono tre: una per i profili utenti, che conterrà email, password hashata e tipo di abbonamento attivo; una per gli ordini, che registrerà ogni estrazione richiesta con i parametri usati, il timestamp di creazione e lo stato corrente; e una per i lead estratti, che conterrà tutti i dati relativi a ogni singolo contatto trovato, incluso l’icebreaker personalizzato generato da Claude.

Un aspetto tecnico importante riguarda la configurazione iniziale del database. Supabase offre un sistema di sicurezza a livello di riga chiamato Row Level Security che, una volta abilitato, blocca di default l’accesso a tutti i dati finché non vengono definite esplicitamente le policy che stabiliscono chi può vedere e modificare cosa. Questo comportamento può creare confusione iniziale: l’applicazione sembra funzionare ma non riesce a leggere o scrivere nessun dato nel database. La soluzione è fornire all’agente le politiche di accesso corrette in SQL, che lui poi eseguirà nell’editor SQL di Supabase.

Autenticazione, Pagamenti e Landing Page: Il Layer Commerciale

Una volta verificato che il nucleo funzionale dell’applicazione funziona correttamente, è il momento di aggiungere tutto ciò che serve perché diventi un prodotto commerciale reale: la pagina di presentazione, il sistema di registrazione e login, e l’integrazione con il sistema di pagamento.

La landing page è il primo punto di contatto tra il tuo prodotto e i potenziali clienti. Deve comunicare chiaramente cosa fa il prodotto, a chi è destinato, e perché vale i soldi che chiedi. I componenti essenziali sono una hero section con headline principale e sottotitolo che spiegano il valore in una frase, una sezione che mostra come funziona il prodotto con passaggi chiari, una sezione con le testimonianze o i case study se disponibili, e una sezione con i piani di abbonamento e i rispettivi prezzi.

Stripe è lo standard industriale per i pagamenti online, usato da aziende di ogni dimensione per la sua facilità di integrazione, la sua affidabilità e la sua gestione completa di tutte le complessità legate ai pagamenti internazionali, alle tasse e alle frodi. Per lo sviluppo e il testing utilizzerai l’ambiente sandbox di Stripe, che ti permette di simulare pagamenti con dati di carte di credito fittizi senza muovere denaro reale. Solo quando passi al deployment in produzione userai le credenziali dell’ambiente live.

Il flusso completo che dobbiamo implementare è: utente atterra sulla landing page, sceglie un piano, viene reindirizzato alla pagina di registrazione, crea un account con email e password, viene reindirizzato alla pagina di pagamento Stripe, completa il pagamento, e viene reindirizzato alla dashboard con il suo abbonamento attivo. Ogni passaggio di questo flusso ha potenziali punti di fallimento che devono essere testati con cura.

GitHub e Versioning: La Macchina del Tempo del Codice

Man mano che il tuo progetto cresce, diventa sempre più importante avere la possibilità di tornare a versioni precedenti del codice in caso di problemi. Questa capacità si chiama version control, e GitHub è la piattaforma più diffusa al mondo per gestirla.

Il concetto fondamentale è il commit: una fotografia dello stato completo del tuo progetto in un momento specifico. Ogni commit ha un messaggio che descrive cosa è cambiato rispetto al commit precedente, e puoi tornare a qualsiasi commit precedente in qualsiasi momento. È esattamente come avere infiniti punti di checkpoint salvati durante una sessione di gioco: se qualcosa va storto, ricarichi dall’ultimo checkpoint sicuro invece di ricominciare da capo.

Il secondo concetto importante è il branch, o ramo. Quando vuoi provare una modifica significativa che potrebbe destabilizzare qualcosa che già funziona, crei un branch separato in cui sperimentare. Se l’esperimento funziona, lo integri nel branch principale. Se l’esperimento fallisce, elimini il branch senza aver toccato nulla nel codice principale. Questo approccio è particolarmente prezioso nel vibe coding, dove è frequente dover esplorare soluzioni alternative per problemi complessi.

L’integrazione tra il tuo progetto di vibe coding e GitHub avviene attraverso un token di autenticazione che fornisci all’agente: lui si occuperà automaticamente di fare i commit dopo ogni sessione di lavoro significativa, garantendo che tu abbia sempre uno storico aggiornato e recuperabile del tuo progetto.

Vercel e il Deployment: Da Locale a Produzione

Tutto il lavoro fatto fino a qui è avvenuto in locale, ovvero sul tuo computer. Per rendere l’applicazione accessibile al mondo, devi deployarla su un server accessibile da internet. Vercel è la piattaforma di deployment più integrata con l’ecosistema Next.js e permette di pubblicare la tua applicazione in pochi minuti, gestendo automaticamente l’infrastruttura tecnica sottostante.

Il processo è semplice: colleghi il tuo repository GitHub a Vercel, configuri le variabili di ambiente con le tue chiavi API, e la piattaforma costruisce e pubblica automaticamente la tua applicazione. Ogni volta che fai un commit su GitHub, Vercel re-deploya automaticamente la versione aggiornata. Questo significa che passare da un aggiornamento locale a una versione live in produzione richiede letteralmente un singolo comando.

Il punto critico che devi aspettarti è che il deployment in produzione quasi sempre rivela problemi che non erano visibili in locale. Questo non è un fallimento: è una parte normale e attesa del processo. Le variabili di ambiente potrebbero non essere configurate correttamente, alcune integrazioni potrebbero comportarsi diversamente in un ambiente di produzione rispetto a quello locale, e configurazioni di sicurezza più stringenti potrebbero bloccare comportamenti che in locale erano permessi. Ogni problema che emerge in questa fase va affrontato con lo stesso processo iterativo usato durante lo sviluppo: descrivi il problema all’agente con il maggior dettaglio possibile, includi gli errori esatti che vedi, e chiedigli di risolverlo in modo sistematico.

Il Modello Economico: Come Prezzare una SaaS AI

Arrivato al punto in cui hai una SaaS funzionante e deployata, la domanda più importante non è più tecnica ma economica: quanto devo farla pagare, e a chi la vendo? La risposta a questa domanda determina se il tuo prodotto diventa un business sostenibile o rimane un esperimento interessante senza futuro economico.

Esistono due filosofie di pricing fondamentalmente diverse. Il pricing basato sui costi parte dal calcolo di quanto ti costa erogare il servizio e aggiunge un margine. Questo approccio è semplice da calcolare ma quasi sempre sbagliato, perché porta a prezzi che non riflettono il valore che stai creando per il cliente.

Il pricing basato sul valore parte invece da una domanda diversa: quanto valore crei per il tuo cliente? E questo valore ha due componenti. La prima è il costo risparmiato: se la tua SaaS permette a un team di vendita di risparmiare dieci ore al mese a persona nella ricerca e personalizzazione manuale dei messaggi di outreach, e queste persone costano venti euro all’ora, il risparmio mensile per un’azienda con cento persone nel team commerciale è duecentomila euro. La seconda componente è il ricavo aggiuntivo abilitato: se quelle stesse dieci ore liberate permettono a ciascun commerciale di chiudere due clienti aggiuntivi al mese con un valore medio di cinquecento euro, l’incremento di fatturato mensile è centomila euro.

Sommando risparmio di costi e incremento di ricavi, ottieni il valore totale che stai generando per quel cliente. Una percentuale di questo valore, tipicamente nell’ordine dell’uno o due percento, è il prezzo che puoi ragionevolmente richiedere mantenendo un rapporto valore-prezzo estremamente favorevole per il cliente. Questo metodo porta a prezzi molto più alti rispetto al pricing basato sui costi, ma anche a clienti molto più soddisfatti perché il rapporto tra ciò che pagano e ciò che ricevono è evidentemente vantaggioso.

La Distribuzione: Il Vero Vantaggio Competitivo

Costruire una SaaS funzionante è diventato, con il vibe coding, qualcosa che qualsiasi persona motivata può fare in una giornata. Questo significa che il software in sé non è più un vantaggio competitivo difendibile nel tempo: è diventato una commodity. Il vantaggio competitivo reale sta interamente nella tua capacità di distribuire il prodotto, di farlo conoscere alle persone giuste e di convincerle a pagare per usarlo.

La distribuzione si costruisce attraverso due canali fondamentalmente diversi con dinamiche temporali opposte. L’outbound è il canale che porta risultati rapidamente, perché sei tu che vai attivamente a cercare i potenziali clienti. Email, messaggi diretti su LinkedIn, chiamate a freddo: queste strategie iniziano a produrre risposte e opportunità in settimane, non in anni. Il limite dell’outbound è che è connesso al tempo disponibile: più cresce il numero di contatti che fai, più tempo richiede, fino a raggiungere un plateau determinato dalla tua capacità operativa.

L’inbound è il canale che porta risultati lentamente ma in modo scalabile, perché sono i potenziali clienti che ti trovano attraverso il contenuto che hai creato. Un canale YouTube, un profilo LinkedIn autorevole, un blog specializzato, una community di settore: questi strumenti richiedono mesi o anni per produrre un flusso significativo di opportunità, ma una volta costruiti funzionano in modo quasi automatico e non dipendono dal tuo tempo operativo.

La strategia ottimale per chi sta partendo da zero è usare l’outbound per generare i primi clienti e le prime entrate rapidamente, e investire contemporaneamente nel costruire un asset di inbound che nel tempo riduca progressivamente il peso dell’outbound sul tuo calendario.

Esiste anche una terza strada, spesso trascurata ma estremamente efficace: iniziare con i servizi prima delle SaaS. Vendere consulenza e implementazione a aziende ti permette di costruire un network di clienti, capire i problemi reali del mercato, e identificare quali automazioni e prodotti hanno più valore economico. Quando poi costruisci una SaaS, non stai più indovinando cosa vuole il mercato: stai costruendo qualcosa per cui hai già visto le aziende pagare, con clienti che ti conoscono già e si fidano di te.

La Regola dell’Ottanta Venti per il Tuo Tempo

Una delle considerazioni più importanti per chi vuole fare business con il vibe coding riguarda come distribuire il proprio tempo tra le diverse attività. La risposta che emerge chiaramente dall’esperienza pratica è controintuitiva per chi è abituato a pensare al prodotto come al centro di tutto: al massimo il cinque percento del tuo tempo dovrebbe essere dedicato alla costruzione e al miglioramento tecnico della SaaS. Il restante novantacinque percento deve essere dedicato al marketing, alle vendite e alla distribuzione.

Questo non significa che il prodotto non sia importante: significa che il prodotto è la condizione necessaria ma non sufficiente per il successo. Un prodotto mediocre che viene conosciuto e comprato da molte persone genera molto più valore di un prodotto eccellente che nessuno sa che esiste. La qualità tecnica del software ti porta al livello di ingresso nel mercato: è la tua capacità di comunicare il valore e raggiungere i clienti giusti che determina il risultato economico.

Questo principio, che potrebbe sembrare specifico al mondo delle SaaS, è in realtà universale. In qualsiasi area del business, che si tratti di costruire un’agenzia di servizi, lanciare un corso, creare un prodotto fisico o sviluppare un software, la distribuzione è sempre il moltiplicatore che determina il risultato. Il vibe coding ha eliminato la barriera tecnica della costruzione, ma non ha eliminato la necessità di saper vendere, comunicare e distribuire.

L’Integrazione con il Modello Adattiva: Tecnologia al Servizio della Visione

Il percorso che hai esplorato in questo approfondimento è molto più di una guida tecnica su come usare strumenti di intelligenza artificiale per costruire software. È una dimostrazione concreta di come la tecnologia, quando viene compresa e utilizzata con metodo e intenzione, possa abbattere barriere che sembravano insuperabili e aprire opportunità che prima erano accessibili solo a chi aveva anni di formazione specialistica alle spalle.

Il vibe coding non è per chi vuole giocare con la tecnologia. È per chi ha una visione di qualcosa che vuole costruire, un problema che vuole risolvere, un valore che vuole creare, e ha bisogno di strumenti che accelerino il percorso dalla visione alla realizzazione senza che la complessità tecnica diventi un ostacolo insuperabile. Usato in questo modo, diventa un moltiplicatore di produttività straordinario, ma solo se inserito in un contesto più ampio fatto di chiarezza strategica, disciplina operativa e capacità di vendere ciò che costruisci.

In Adattiva questa è esattamente la visione che guida ogni cosa: la tecnologia non è mai il fine, ma il mezzo. Il fine è costruire un progetto professionale e di vita coerente, in cui business, benessere, relazioni e mentalità si integrano in modo armonico per produrre risultati che siano non solo economicamente validi ma anche personalmente significativi.

Se senti che questo approccio integrato alla crescita, in cui ogni strumento serve un obiettivo più grande e ogni competenza si inserisce in una visione più ampia, risuona con il tuo modo di pensare al tuo futuro professionale, scopri il modello Adattiva su www.adattiva.net: un percorso strutturato che unisce business, benessere, relazioni e mentalità in un’unica visione coerente di evoluzione consapevole, pensato per chi vuole costruire qualcosa di solido, duraturo e realmente suo.