Lovable è un servizio che genera applicazioni web a partire da una descrizione testuale. L’utente fornisce ciò che serve, il servizio crea interfaccia, dati e sistema di login, e pubblica l’app con un solo click su un dominio del tipo nome.lovable.app. Il modello di fatturazione è basato sui crediti, non sugli utenti, perciò la formulazione del prompt influisce direttamente sui costi e sul risultato.

Le tre regole fondamentali di un prompt per Lovable

Un prompt valido deve contenere tre informazioni essenziali: cosa deve essere costruito, dove nella struttura dell’app e cosa deve restare invariato. Questa è la regola indicata nella documentazione ufficiale e si applica anche al primo messaggio di un progetto, dove la “posizione” diventa lo schermo e l’“invariato” il frame dell’app.

Modi operativi di Lovable

Lovable dispone di tre modalità distinte, ciascuna pensata per una fase specifica del processo di sviluppo:

    • Chat: discussione delle funzionalità senza modificare codice o dati; ogni risposta costa una frazione di credito.
    • Plan: analisi del progetto e generazione di un piano strutturato da revisionare prima di qualsiasi scrittura di codice; ogni messaggio costa 1 credito più eventuali costi dei sub‑agent.
    • Build: modalità predefinita per scrivere, verificare e correggere le modifiche; può consumare fino a 10 ore di lavoro per messaggio, con addebito basato sul tempo effettivo impiegato.

Le cinque fasi della metodologia

La sequenza consigliata per ottenere risultati ottimali è composta da cinque fasi, ognuna focalizzata su un singolo cambiamento:

    • Project instructions (istruzioni di progetto) e contenuti reali
    • Primo prompt
    • Componenti (frontend)
    • Backend con sicurezza
    • Correzione errori

Le fasi si basano sulla documentazione di Lovable (Prompt‑Guide, Prompt‑Library, modalità, istruzioni, crediti, sicurezza) e su un caso studio concreto: un’app di prenotazione di una stanza di prova per band.

Fase 1 – Istruzioni di progetto

Le istruzioni (denominate “Instructions”) sono un testo che Lovable legge prima di ogni messaggio. Esistono a due livelli: quello del workspace (condiviso tra tutti i progetti) e quello specifico del progetto. Il limite è di 10.000 caratteri per livello; in caso di conflitto, prevalgono le istruzioni del progetto.

È consigliato scrivere le istruzioni come un onboarding per un nuovo sviluppatore: poche righe, concrete, senza storia di background. Dovrebbero includere:

    • Decisioni permanenti (lingua, stile, regole di lavoro)
    • Contenuti reali (nomi, prezzi, testi definitivi)
    • Vincoli di non modificare schemi dati senza conferma

Esempio di file project‑instructions.txt per l’app “Proberaum”:

Projekt: Proberaum, Buchungs‑App für einen Musik‑Proberaum im Viertel.


Nutzer: Musiker (buchen) und ein Betreiber (gibt frei, sperrt Zeitfenster).


Sprache der Oberfläche: Deutsch. Uhrzeiten im 24‑Stunden‑Format, Zeitzone Europe/Berlin.


Zeitfenster: Blöcke von 2 Stunden, von 10:00 bis 24:00 Uhr, sieben Tage die Woche.


Stil: nüchtern, heller Hintergrund, nur eine Akzentfarbe (Tannengrün), keine Animationen.


Arbeitsregeln: eine Änderung nach der anderen. Das Datenschema nicht ändern, ohne mich zu fragen.


Inhalte: realistische Namen und Texte (Instrumente, Preise in Euro), niemals Platzhalter.

Queste istruzioni forniscono un quadro chiaro su lingua, formato orario, blocchi di tempo, stile visivo e regole operative, evitando ambiguità future.

Fase 2 – Il primo prompt

Il primo prompt stabilisce il “fondamentale” dell’app. Deve specificare:

    • Gli utenti (musician, operator)
    • Gli schermi (calendario settimanale, modulo di richiesta, area operatore)
    • I dati da memorizzare (data, slot, nome band, numero persone, stato)
    • Le limitazioni (slot da 2 ore, orario 10‑24, ecc.)

Esempio di file primo‑prompt.txt:

Erstelle eine Web-App zum Buchen eines Musik-Proberaums. Sie heißt Proberaum.



Wer sie nutzt


  • Der Musiker: sieht den Kalender, wählt ein freies Zeitfenster, schickt die Anfrage ab.
    • 

  • Der Betreiber: sieht alle Anfragen, bestätigt oder lehnt sie ab, sperrt die Zeitfenster, in denen der Raum geschlossen ist.
    • 



Bildschirme


1. Wochenkalender mit den Zeitfenstern zu je 2 Stunden. Ein Zeitfenster kann frei, in Wartestellung, bestätigt oder gesperrt sein.


2. Anfrageformular: Bandname, Anzahl der Personen, anzuschließende Instrumente, Notizen.


3. Betreiberbereich mit den offenen Anfragen, nach Datum sortiert.



Daten


Eine Buchung hat Datum, Zeitfenster, Bandname, Anzahl der Personen, Status (in Wartestellung, bestätigt, abgelehnt).

Il prompt segue il principio della “una modifica significativa per passo”. Prima si costruisce il flusso principale (richiesta, conferma, calendario) e si rimandano a più tardi dettagli estetici o funzionali secondari.

Fase 3 – Componenti (frontend)

Una volta definito il flusso, si passano al modello le componenti UI specifiche. È utile usare un vocabolario preciso: Card, Badge, Modal, Toggle. In questo modo Lovable comprende immediatamente gli elementi da generare.

Esempio di prompt per i componenti:

    • Creare una Card per ogni slot disponibile nel calendario, con colore verde per slot liberi, giallo per in attesa, rosso per confermati.
    • Aggiungere un Badge che mostri il numero di persone nella band.
    • Utilizzare un Modal per il modulo di richiesta, con campi obbligatori e pulsante “Invia”.
    • Inserire un Toggle nell’area operatore per attivare/disattivare lo slot.

Queste specifiche guidano il modello nella generazione di codice HTML/CSS coerente con lo stile definito nella fase 1 (sfondo chiaro, accento verde abete, niente animazioni).

Fase 4 – Backend e sicurezza

Il backend deve gestire le prenotazioni, le autorizzazioni e la protezione dei dati. Lovable offre una modalità di “Build + scan” che esegue anche una verifica di sicurezza (RLS, secrets, scansione di vulnerabilità). Si consiglia di:

    • Definire tabelle PostgreSQL per bookings, users e rooms.
    • Impostare regole Row‑Level Security (RLS) affinché i musicisti possano vedere solo le proprie prenotazioni, mentre l’operatore abbia accesso a tutte.
    • Utilizzare secret management per le chiavi API di pagamento (se integrate).
    • Eseguire una scansione di sicurezza automatica dopo ogni build.

Un prompt tipico per questa fase può includere:

Implementiere ein PostgreSQL‑Schema mit den Tabellen bookings, users und rooms.


Aktiviere Row‑Level‑Security: Musiker können nur ihre eigenen Buchungen sehen.


Füge Secrets für die Zahlungs‑API hinzu und führe einen Security‑Scan nach dem Build aus.

Il risultato sarà una base dati solida e una configurazione di sicurezza che evita esposizioni accidentali.

Fase 5 – Correzione errori

Durante lo sviluppo è normale incontrare errori di compilazione, bug di UI o problemi di permessi. La modalità “Chat” è ideale per segnalare i sintomi, mentre il “Plan” serve a definire una strategia di risoluzione prima di applicare modifiche concrete.

Un ciclo tipico di correzione prevede:

    • Descrivere l’errore nella chat (es. “Il badge non appare in rosso per slot confermati”).
    • Richiedere al modello di porre domande chiarificatrici prima di intervenire.
    • Passare al “Plan” per elaborare un piano di fix (modifica CSS, aggiornamento logica).
    • Eseguire il fix in modalità “Build” e verificare i log.
    • Se necessario, revertire alla versione precedente e ripetere il ciclo.

Questa sequenza evita spese inutili di crediti e garantisce che ogni modifica sia ben motivata.

Consigli pratici per ottimizzare i crediti

Poiché i crediti sono la moneta di scambio, è fondamentale usarli con parsimonia:

    • Usa il piano per ogni cambiamento complesso; riduce il rischio di dover ricostruire intere parti.
    • Limita le domande nella chat: chiedi al modello di raggruppare le proprie richieste in una sola risposta.
    • Monitora i log di Build: interrompi il processo appena il risultato non è più allineato con le aspettative.
    • Sfrutta il gratuito: il piano gratuito offre 5 crediti al giorno (fino a 30 al mese) per sperimentare.

Seguendo queste linee guida, è possibile sviluppare rapidamente applicazioni funzionali, mantenendo sotto controllo i costi.

Riepilogo della metodologia

La chiave del successo con Lovable è una sequenza disciplinata di cinque fasi, ciascuna supportata dal corretto uso dei tre modi (Chat, Plan, Build). Un prompt ben strutturato, che indica chiaramente “cosa”, “dove” e “cosa mantenere”, riduce gli errori e ottimizza l’utilizzo dei crediti. Applicando il modello al caso studio del “Proberaum”, si ottiene una guida pratica pronta a essere adattata a qualsiasi altra tipologia di app web.