Recensione Bolt.new (Verificata ad Agosto 2026)
Bolt.new parte da $25/mese. Scopri a chi si rivolge, i limiti su token e database e quando Lovable, Replit o Cursor sono la scelta migliore.
Bolt.new vale i $25 al mese per un solo founder che deve trasformare un'idea di web app ben definita in un prototipo online ed è disposto a ispezionare il codice generato. È da evitare per un sistema di produzione maturo, per un flusso di lavoro non tecnico incentrato puramente sul design o per qualsiasi progetto il cui database non si possa ripristinare manualmente: il rollback dei progetti di Bolt continua a non ripristinare il database.
Panoramica su Bolt.new: che cos'è
Bolt.new è un app builder utilizzabile da browser che trasforma un brief scritto in codice applicativo modificabile, esegue quel codice in un ambiente di sviluppo online e può aggiungere database, autenticazione e hosting senza costringere ad assemblare questi servizi in anticipo. Si posiziona a metà tra un costruttore no-code e un editor di programmazione con AI: si può lavorare tramite conversazione, ma il risultato resta un codebase trasferibile su GitHub. Questo lo rende particolarmente efficace per prototipi, strumenti interni e prodotti web con un perimetro ridotto, non per delegare ogni decisione tecnica a un prompt.
Il prodotto attuale è sostanzialmente diverso da quello con cui sono partiti molti progetti iniziali. Le note di rilascio di Bolt indicano che il v1 Agent e la Discussion Mode sono stati ritirati il August 3, 2026. I progetti rimasti sono passati a Bolt Agent mantenendo file e cronologia della chat, mentre la Plan Mode è diventata lo spazio in cui ragionare sulla struttura prima di modificare direttamente il codice. È attiva anche la dettatura vocale, con la voce trascritta in un prompt modificabile prima dell'invio.
Recensione Bolt.new: confronto sintetico con le alternative
Bolt.new vince la selezione quando si vogliono prompt, codice, database e primo deployment in un unico flusso di lavoro via browser. Lovable vince quando la cura visiva e la collaborazione senza attrito contano più del controllo a livello di codice. Replit è l'ambiente di sviluppo da browser più ampio e versatile. Cursor è la scelta più indicata quando uno sviluppatore esperto dispone già di una repository e cerca un code editor nativo per l'AI anziché un generatore all-in-one di applicazioni.
La tabella nasconde una distinzione cruciale. Bolt.new, Lovable e Replit possono aiutare ad avviare un'applicazione da zero, mentre Cursor presuppone la piena familiarità con la gestione del codice. Confrontarli solo sul costo dell'abbonamento trascura il costo del passaggio di consegne (handoff). Un founder non tecnico può spendere gli stessi $25 per Lovable Pro ed evitare ore di ispezione del codice. Uno sviluppatore può spendere $20 per Cursor ed evitare di pagare un builder basato su prompt per rileggere un intero progetto a ogni messaggio.
Questa è la regola d'oro della recensione: scegli l'ambiente che mantiene visibile la parte più complessa del tuo progetto. Bolt mantiene visibile l'infrastruttura necessaria per approdare su GitHub. Lovable mantiene visibili design e collaborazione. Replit mantiene visibile il più ampio workspace di sviluppo. Cursor mantiene visibile il codice stesso.
A chi serve Bolt.new e chi dovrebbe evitarlo
Bolt.new è ideale per chi crea progetti attribuendo valore a una prima versione funzionante rapida, senza confondere tale versione con un'architettura definitiva. Il profilo perfetto ha un flusso operativo circoscritto, sa descrivere dati e permessi ed è disposto a ispezionare il codice generato o a coinvolgere chi ne è capace. L'acquirente peggiore arriva con un'idea di prodotto enorme, nessun criterio di accettazione, dati sensibili e l'illusione che aggiungere altri prompt risolverà ogni carenza architetturale.
Ideale: un solo founder che valida un singolo flusso
Bolt.new ha perfettamente senso per un solo founder che intende validare un processo circoscritto prima di assumere un team di sviluppo. Si pensi a un servizio di prenotazione per tutor indipendenti. La prima versione utile richiede profili per i tutor, slot orari disponibili, un modulo di prenotazione, un'email di conferma e una semplice vista di amministrazione. Questi elementi si mappano in modo pulito su un database, un sistema di autenticazione e un'interfaccia online.
Il founder può descrivere i ruoli utente, chiedere a Bolt di creare tabelle e flusso di login, pubblicare un'anteprima privata o pubblica e salvare il codice su GitHub prima di invitare i primi utenti. Il prodotto richiederà comunque test, decisioni sulla privacy e manutenzione, ma Bolt accorcia drasticamente la distanza tra un flusso scritto e un'interfaccia interattiva.
Questo equilibrio salta se il founder non è in grado di capire se un controllo sui permessi spetti all'interfaccia o al database. Un pulsante che scompare per l'utente sbagliato non equivale a una policy sicura a livello di riga (RLS). Bolt può generare entrambe le soluzioni, ma qualcuno deve verificare che siano implementate correttamente.
Ideale: un product manager che dimostra un flusso prima del lavoro dei tecnici
Bolt.new si adatta bene anche al product manager che ha bisogno di un prototipo funzionante e basato su dati reali, anziché dell'ennesimo mockup statico. Uno strumento per l'approvazione dei resi, ad esempio, può includere una coda di richieste, le schede dei clienti, i codici motivo e azioni dedicate per ciascun ruolo. Gli stakeholder possono utilizzare direttamente il flusso e individuare gli stati mancanti prima che inizi lo sprint di sviluppo.
Il product manager dovrebbe considerare l'applicazione generata come un'attività di product discovery eseguibile. Il vero vantaggio non è portare il prototipo in produzione senza modifiche, ma capire se il flusso operativo funziona quando apportare cambiamenti costa ancora pochissimo. Collegare GitHub fornisce un artefatto concreto da far esaminare agli ingegneri, ma non trasforma di per sé il prototipo in un'architettura approvata.
Ideale: una piccola agenzia con una chiara procedura di consegna
Bolt.new può aiutare una piccola agenzia a realizzare strumenti di campagna, calcolatori, portali e prototipi, a patto che ogni progetto segua una rigorosa disciplina di consegna. L'agenzia dovrebbe stabilire fin dall'inizio se l'elaborato rimarrà sull'hosting di Bolt, se passerà a una repository di proprietà del cliente o se diventerà uno sviluppo su misura. Tale decisione determina chi gestirà domini, variabili segrete, ripristino dei database e modifiche future.
Le funzionalità Teams aiutano nella gestione centralizzata degli accessi, nella condivisione aziendale e nell'uso di design system, ma il conteggio per utente incide sui costi. Ciascun membro a pagamento riceve una quota individuale di token, e tali token non sono condivisi. Un'agenzia con uno sviluppatore intensivo e diversi revisori rischia di pagare per capacità inutilizzata mentre lo sviluppatore principale esaurisce la propria.
Evita Bolt.new per un team non tecnico e orientato al design: scegli Lovable
Lovable rappresenta l'alternativa migliore quando il team ricerca interfacce curate, capacità di generazione condivisa e meno decisioni a livello di codice sorgente. Lovable Pro costa $25 al mese con 100 crediti mensili, utenti illimitati, rollover dei crediti, ricariche, domini personalizzati, ruoli, limiti di credito per membro, supporto via email e design system.
Il modello con utenti illimitati contrasta nettamente con Bolt Teams, che richiede $30 per utente al mese. I crediti condivisi di Lovable non sono automaticamente più generosi, e il loro conteggio non è direttamente paragonabile ai token di Bolt. Il vantaggio è organizzativo: un founder, un designer e un marketer possono collaborare all'interno dello stesso spazio Pro senza dover moltiplicare l'abbonamento base per il numero di persone.
Scegli Lovable se la priorità è: “Tutto il team può contribuire a plasmare questa interfaccia?”. Scegli Bolt se la priorità è: “Possiamo ottenere codice funzionante, infrastruttura e consegna su GitHub all'interno dello stesso browser?”. Se nessuno nel team analizzerà il codice, il controllo aggiuntivo offerto da Bolt si rivelerà una funzione che difficilmente verrà sfruttata a dovere.
Evita Bolt.new per un ambiente cloud più esteso: scegli Replit
Replit è la deviazione migliore se cerchi un ambiente di sviluppo completo via browser, agenti simultanei e un percorso più naturale dai piccoli esperimenti a un workspace di sviluppo gestito. Replit Core costa $20 al mese (o $18 al mese con fatturazione annuale) e include due agenti paralleli, workspace illimitati e $20 di credito per i modelli più potenti.
Il confronto più significativo emerge nei piani superiori di Replit. Replit Pro costa $100 al mese (o $90 al mese con fatturazione annuale) e offre dieci agenti paralleli, fino a quindici collaboratori, fino a cinquanta visualizzatori e il rollback del database fino a ventotto giorni. La cronologia delle versioni integrata di Bolt (Version History) non ripristina affatto il database.
Questo non rende Replit superiore in assoluto. Significa semplicemente che se per te sono prioritari l'esecuzione di agenti simultanei o un rollback documentato del database, dovresti anteporre tali esigenze al punto d'ingresso più economico di Bolt a $25. Scegli Bolt per un percorso rapido e diretto da prompt ad applicazione; scegli Replit quando il prodotto che stai acquistando è lo spazio di sviluppo stesso.
Evita Bolt.new per una repository già avviata: scegli Cursor
Cursor è l'alternativa naturale per uno sviluppatore esperto la cui applicazione esiste già. Cursor Individual Pro costa $20 al mese, estende i limiti del proprio Agent e aggiunge modelli di frontiera, MCP, skill, hook e agenti in cloud.
Cursor non elimina la necessità di selezionare hosting, autenticazione o database: ed è esattamente per questo che è preferibile una volta che queste scelte sono già state prese. Lo sviluppatore lavora direttamente sulla repository senza chiedere a un generatore di applicazioni di sincronizzare e reinterpretare l'intero progetto a ogni ciclo.
Passa a Cursor quando l'obiettivo non è più “definire la forma del prodotto”, ma “modificare questo codice noto rispettando l'architettura stabilita e le regole di revisione”. La più ampia guida comparativa tra Codex, Claude Code e Cursor rappresenta la lettura successiva ideale non appena la proprietà diretta del codice torna al centro del lavoro.
Funzionalità 1: prototipi full-stack con database e hosting
La caratteristica più rilevante di Bolt.new non risiede nella generazione di una pagina, ma nel mantenere interfaccia, database, autenticazione e primo deployment sufficientemente vicini da consentire a una sola persona di modellare un flusso di lavoro completo. Ecco perché Bolt risulta decisamente più utile per un portale di raccolta dati o un sistema di prenotazione rispetto a un mockup di marketing che richiede solo schermate accattivanti.
Prendiamo ad esempio un'azienda locale di manutenzioni che intende sostituire un processo di ricezione ordini basato su email e fogli di calcolo. L'applicazione richiede un modulo per i clienti, un archivio richieste, una coda per l'operatore, l'assegnazione a un tecnico e lo storico degli stati. Un flusso efficace su Bolt parte dalla definizione di queste entità e dei relativi permessi, non dalla generica richiesta di “un'app moderna per interventi tecnici”.
Definisci il flusso di lavoro e i ruoli
Descrivi i ruoli di cliente, operatore e tecnico. Specifica gli stati che una richiesta può assumere, cosa può vedere ciascun ruolo e quali azioni ne determinano l'avanzamento. In questo modo si fornisce a Bolt un modello comportamentale e non un'idea vaga.
Richiedi esplicitamente il modello dati
Richiedi tabelle per clienti, richieste di servizio, assegnazioni ed eventi di stato. Bolt può creare un database automaticamente quando il progetto lo richiede, ma un modello esplicito facilita la verifica e riduce il rischio che informazioni critiche rimangano memorizzate solo nello stato dell'interfaccia.
Specifica autenticazione e autorizzazioni
Richiedi registrazione via email, login, recupero password e controllo degli accessi basato sui ruoli. La documentazione di Bolt specifica che l'autenticazione potrebbe non essere aggiunta in automatico, anche in presenza di un database. Verifica gli URL di reindirizzamento e le regole sui permessi prima di esporre un'anteprima pubblica.
Pubblica un'anteprima usa e getta
Sia gli utenti Free che quelli Pro possono pubblicare su un indirizzo
.bolt.host. Mantieni il primo set di dati a livello sacrificabile. Invita un operatore a testare l'inserimento, l'assegnazione e la chiusura della pratica, appuntando ogni stato o comportamento mancante.Esporta il codice prima che i dati diventino critici
Collega GitHub non appena il primo flusso stabile è funzionante. Non aspettare che i record dei clienti acquistino reale valore operativo per scoprire come separare progetto, database e deployment.
Bolt Database semplifica l'avvio: può predisporre un database quando l'app lo richiede, include controlli di autenticazione, mostra log e variabili segrete, e permette di selezionare Supabase in fase di configurazione. La protezione contro le password compromesse (leaked-password protection) è attiva di default quando Bolt genera il database. Se il database viene reclamato o collegato tramite Supabase, tale protezione dipenderà dal piano Supabase adottato (risultando disattivata su Supabase Free).
La vera differenza sta tra funzionalità generata e comportamento verificato. Una schermata di login può sembrare impeccabile, mentre i reindirizzamenti del recupero password puntano all'indirizzo errato. La coda dell'operatore può mascherare i dati di un altro cliente nell'interfaccia, mentre le policy del database ne consentono ancora l'accesso via API. I pannelli di autenticazione di Bolt mostrano URL di base, allowlist di URI, provider e template, ma è indispensabile che qualcuno li controlli.
Anche il percorso di pubblicazione è comodo ma presenta confini precisi. L'hosting Free offre un indirizzo .bolt.host, 10GB di larghezza di banda e 333,333 richieste mensili complessive per l'intero account. L'hosting Pro porta la soglia a 30GB e 1 million di richieste mensili, sblocca i domini personalizzati tramite piano a pagamento e consente traffico pay-as-you-go. Questi limiti bastano per convalidare piccoli progetti, ma essendo conteggiati a livello di account, più progetti attivi concorreranno alla medesima quota.
L'ostacolo principale riguarda il disaster recovery. La Version History dei progetti in Bolt non ripristina il database. Riportare il codice dell'applicazione allo stato di ieri lascia il database nello stato odierno. Questo disallineamento può risultare persino più insidioso della totale assenza di una funzione di ripristino, poiché induce a credere erroneamente che codice e dati avanzino e retrocedano sempre insieme.
Tornando all'esempio dell'azienda di manutenzioni: immagina di ripristinare il codice a una versione precedente alla ridenominazione di un campo di stato, mentre il database conserva già il nuovo schema. Interfaccia e dati smetteranno di comunicare correttamente. Prima che un progetto acquisisca reale importanza operativa, definisci procedure di backup del database, migrazioni di schema e un piano di ripristino testato al di fuori della timeline interna di Bolt.
Funzionalità 2: proprietà del codice tramite GitHub
Bolt.new merita considerazione rispetto ai costruttori no-code proprietari perché l'applicazione può essere sincronizzata con GitHub ed essere migrata su un altro fornitore di hosting o all'interno di un flusso di sviluppo convenzionale. Tuttavia, la portabilità ha valore reale solo se implementata tempestivamente. Affermare che “il codice si può esportare” non costituisce una strategia di ripristino se la repository non è mai stata agganciata e nessuno sa quale commit corrisponda al database di produzione.
La documentazione di GitHub su Bolt chiarisce che una repository generata da un progetto Bolt viene creata come privata sul ramo main. Bolt effettua automaticamente il commit delle modifiche che non causano errori nell'applicazione, monitora GitHub ogni trenta secondi per rilevare aggiornamenti esterni e supporta creazione e cambio di rami (branch).
Un flusso di consegna logico prevede questi passaggi:
Connetti dopo il primo stato stabile
Crea la repository quando il progetto ha ancora dati sacrificabili. Verifica la presenza di tutti i file attesi, dei template di configurazione ambientale e dei manifesti delle dipendenze. Assicurati che le credenziali segrete non vengano incluse nel repository.
Crea un ramo per ogni modifica significativa
Usa un ramo separato per integrare un nuovo sistema di pagamento, modificare le autorizzazioni o rinnovare il layout. Bolt mantiene isolato il contesto di ciascun ramo, riducendo il rischio di contaminare la versione stabile con codice incompleto.
Revisiona e unisci su GitHub
Bolt consente di creare e alternare rami, ma non permette di eseguire il merge all'interno dell'interfaccia. Apri una pull request ed effettua il merge direttamente su GitHub, dove uno sviluppatore può ispezionare le modifiche e dove la decisione resta tracciata nello storico.
Riallinea prima di inviare nuovi prompt
Attendi che lo stato aggiornato dal merge venga sincronizzato con Bolt, apri il ramo corretto e controlla l'anteprima. Bolt esegue un controllo su GitHub ogni trenta secondi, ma un timer automatico non sostituisce la verifica puntuale dello stato prima di ulteriori modifiche.
Questo approccio trasforma Bolt in un punto di partenza flessibile anziché in una gabbia dorata. Uno sviluppatore può sganciarsi da Bolt, lavorare direttamente nel repository, pubblicare l'app altrove e ritornare in un secondo momento. Questa possibilità è preziosa quando il prototipo cresce al punto da richiedere test automatizzati, monitoraggio, revisioni di architettura o un backend dedicato.
Esistono tuttavia due vincoli da considerare prima di considerare questo processo un'esperienza Git tradizionale. In primo luogo, il merge avviene sempre all'esterno di Bolt: un team non tecnico deve quindi comprendere il concetto di pull request o affidarsi a chi ne ha competenza. In secondo luogo, il fornitore segnala un caso limite di concorrenza: se Bolt e GitHub vengono aggiornati quasi nello stesso istante, Bolt accorda priorità alle proprie modifiche locali, sovrascrivendo la versione presente su GitHub.
La risposta corretta non è evitare lo strumento, ma stabilire una governance chiara. Evita di modificare lo stesso ramo contemporaneamente da Bolt e da altri ambienti. Utilizza rami dedicati, gestisci i merge su GitHub e mantieni la repository come unica fonte di verità per le revisioni. Se un progetto ha raggiunto una fase in cui più programmatori vi lavorano costantemente, Bolt deve diventare uno dei contributori del flusso, non l'arbitro finale.
Funzionalità 3: app mobile tramite Expo
Bolt.new può impostare un'applicazione mobile multipiattaforma tramite Expo, ma è la formulazione del prompt iniziale a stabilire se il percorso sarà fluido. La guida di Bolt su Expo evidenzia come un progetto nato per il web non possa essere convertito agevolmente in mobile. L'istruzione “rendilo mobile” costituisce una modifica strutturale d'architettura, non un semplice comando di rifinitura grafica.
Prendiamo come esempio un'app per la pianificazione dei pasti. Il primo prompt deve chiarire esplicitamente che si tratta di un'app mobile per iOS e Android, specificando il modello per la gestione delle ricette, i nuclei familiari e le modalità di interazione tipiche da smartphone. A quel punto Bolt configurerà Expo, framework che permette a un unico codebase di indirizzare sia i dispositivi mobili che il web.
La fase di test intermedio è molto accessibile: aprendo il progetto mobile e selezionando Device Preview, basta inquadrare il codice QR con l'app Expo Go per interagire subito con l'applicazione sul proprio dispositivo. Questo consente di identificare tempestivamente criticità relative a layout, tastiera virtuale, navigazione e gesture tattili che un browser desktop tenderebbe a nascondere.
Il rilascio definitivo non avviene però all'interno di Bolt. La pubblicazione sugli app store ufficiali richiede il download locale del codice sorgente, l'apertura in un editor, una macchina con Node.js LTS e Git, la configurazione di Expo Application Services e account sviluppatore registrati presso Apple o Google. La compilazione finale può incontrare problemi legati a certificati, librerie specifiche di piattaforma o normative dei singoli store.
Questo confine è utile perché evidenzia le reali competenze necessarie. Un founder può sfruttare Bolt per validare rapidamente un'interfaccia mobile senza conoscere Swift o Kotlin, ma avrà comunque bisogno di una figura responsabile dei processi di rilascio, gestione dei profili di firma, schede dello store, informative sulla privacy, log di crash e approvazioni. Expo ottimizza lo sviluppo su più sistemi, ma non azzera la gestione operativa del ciclo di vita dell'app.
Il flusso di lavoro consigliato è il seguente:
Dichiara la natura mobile fin dal primo prompt
Esplicita fin dall'inizio il supporto a iOS e Android, l'interazione touch principale, il funzionamento offline e l'eventuale ricorso a fotocamera, notifiche push o geolocalizzazione prima che il codice venga generato.
Esegui i test su un dispositivo reale
Usa Expo Go sin dalle prime fasi. Testa il flusso completo più essenziale: selezione delle ricette, compilazione degli ingredienti e persistenza dei dati alla riapertura dell'applicazione.
Esporta il progetto prima delle pratiche di pubblicazione
Sincronizza il codice su GitHub e predisponi un ambiente locale prima di configurare le credenziali per i negozi di app. Il repository deve costituire l'elemento sottoposto a revisione prima del rilascio.
Individua il responsabile delle consegne
Definisci chiaramente chi gestirà i certificati di firma, i test su TestFlight o Google Play, le note di versione, i requisiti di privacy e l'analisi dei crash. Senza questa figura, il progetto resta un prototipo interattivo, non un prodotto pronto per gli utenti finali.
Adotta Bolt per il mobile se l'obiettivo attuale è dimostrare la validità del flusso applicativo. Evitalo come unico strumento se le maggiori complessità del progetto riguardano già comportamenti nativi del sistema operativo, servizi in background, integrazioni hardware profonde o un processo rigoroso di pubblicazione sugli store.
Funzionalità 4: sviluppo in team guidato da design system
La gestione dei design system in Bolt.new si rivela determinante per i team che dispongono già di librerie di componenti, griglie di spaziatura e linee guida di marca formalizzate. La piattaforma non trasforma magicamente una bozza di stile generica in elementi di produzione riutilizzabili: è l'accuratezza della fonte a determinare se Bolt integrerà una vera libreria di componenti o se si limiterà a replicarne colori e font.
La personalizzazione dei design system richiede la sottoscrizione del piano Teams. Il team può collegare Bolt a un repository GitHub, a un pacchetto NPM, a un'istanza Storybook, a un sito di documentazione o a file caricati direttamente. Bolt analizza queste fonti e genera uno Storybook interno in modo che chi sviluppa possa consultare i componenti interpretati dal sistema.
Il caso d'uso più solido riguarda le aziende software B2B che distribuiscono già i propri componenti per pulsanti, form, navigazione e tabelle sotto forma di pacchetto NPM. Il team importa il pacchetto, collega lo Storybook di supporto e fornisce all'agente istruzioni puntuali, come l'esclusione di componenti deprecati o l'adozione di un tema specifico. In questo modo, un product manager può generare un prototipo basato direttamente sui componenti aziendali approvati anziché su elementi grafici generici.
La documentazione ufficiale di Bolt è trasparente riguardo alla qualità delle fonti fornite: repository GitHub e pacchetti NPM offrono in genere risultati superiori rispetto alla sola consultazione di un sito di documentazione. Un portale con catture di schermata e note illustrative comunica l'impostazione visiva, ma un pacchetto di componenti fornisce a Bolt l'effettiva implementazione riutilizzabile.
Sussistono alcune limitazioni d'uso: i team a pagamento possono aggiungere o sincronizzare un massimo combinato di dieci design system alla settimana. I caricamenti locali accettano fino a dieci file (PDF, immagini o altri formati). Linee guida contrastanti, componenti obsoleti o framework eterogenei riducono la precisione del risultato: aumentare le fonti a disposizione non produce automaticamente codice migliore.
Seleziona la sorgente ufficiale dei componenti
Parti dal repository o dal pacchetto NPM che il team di sviluppo considera come riferimento autorevole. Evita di mescolare librerie legacy e correnti all'interno del medesimo set di sorgenti.
Fornisci documentazione funzionale, non puramente estetica
Allega indicazioni che chiariscano quando utilizzare ciascun componente, vincoli di accessibilità e regole tematiche. Gli screenshot grafici da soli non spiegano all'agente la logica comportamentale del componente.
Imposta istruzioni precise per l'agente
Indica a Bolt il framework da utilizzare, il tema prescelto, la versione esatta del pacchetto e i componenti da ignorare. Un'istruzione esplicita di esclusione risulta spesso più efficace di una cartella ricca di esempi generici.
Realizza un primo flusso di prova
Genera un form, gli stati di validazione, uno stato vuoto e la visualizzazione dei risultati. Valuta la conformità dei componenti e dei comportamenti generati rispetto al design system aziendale prima di estendere il flusso all'intero progetto.
Questa funzionalità giustifica il costo di Bolt Teams quando disporre di prototipi fedeli alle linee guida aziendali evita rilavorazioni e l'organizzazione possiede già una libreria di codice strutturata. Al contrario, non giustifica una spesa di $30 per utente per un founder che dispone solo di un logo, una palette di colori e nessun componente riutilizzabile. Lovable Pro include il supporto ai design system a $25 con utenti illimitati; il sovrapprezzo di Bolt trova riscontro solo se il controllo delle sorgenti a livello di componente e l'ambiente di compilazione integrato rappresentano fattori determinanti.
Prezzi di Bolt.new: tutti i piani attuali e costo per risultato
La struttura pubblica dei prezzi mensili di Bolt.new è lineare: piano Free a $0, Pro a $25, Teams a $30 per membro ed Enterprise con tariffazione personalizzata. L'aspetto critico consiste nel calcolare in che modo l'uso dei token, le quote di hosting condivise e il numero di collaboratori trasformino il canone base nel costo effettivo di ciascun prototipo completato.
I prezzi e le soglie operative riportati di seguito sono stati verificati sulla pagina ufficiale dei prezzi di Bolt il August 27, 2026. Il portale evidenzia inoltre un risparmio fino al 28% optando per la fatturazione annuale. Poiché la dicitura “fino al” non costituisce una percentuale uniforme applicata a ogni livello, la tabella mensile rappresenta il metro di paragone più oggettivo, fermo restando che il preventivo mostrato in fase di checkout fa fede per gli accordi annuali.
Il piano Free è una prova di prodotto con hosting utilizzabile
Il piano Free consente progetti pubblici e privati, database illimitati, distribuzione su dominio .bolt.host, 1 million di token mensili e una soglia giornaliera di 300,000 token. Risulta sufficiente per acquisire familiarità con le funzioni di pianificazione, generazione e rilascio di Bolt. Non costituisce tuttavia una soluzione affidabile per completare un'applicazione che richiede numerosi prompt, poiché il limite giornaliero può bloccare i lavori prima dell'esaurimento della quota mensile.
I vincoli di hosting comportano effetti più rigidi: il livello Free include 10GB di banda e 333,333 richieste mensili complessive per l'account. Raggiunto il limite mensile, i siti ospitati cessano di rispondere fino al ripristino del periodo successivo. Questo comportamento è sostenibile per una demo usa e getta, ma non per un servizio che deve garantire continuità operativa.
Il piano Pro è la scelta predefinita per lo sviluppatore singolo
Il piano Pro costa $25 al mese e mette a disposizione 10 million di token di base senza limitazioni giornaliere. Rimuove il badge di Bolt, eleva gli upload a 100MB e introduce condivisione privata, domini personalizzati, ottimizzazione SEO Boost, selezione del fornitore di database ed elaborazione di immagini con AI. La quota di hosting comprende 30GB di banda e 1 million di richieste al mese a livello di account.
I token acquistati e non consumati vengono trasferiti al mese successivo, mantenendo validità fino a due mesi consecutivi a fronte di una sottoscrizione regolarmente attiva. Questo aggiornamento smentisce una convinzione diffusa secondo cui i token a pagamento di Bolt andrebbero sempre persi a fine mese. I token del piano Free non sono invece cumulabili.
Gli abbonati Pro possono preservare la continuità del servizio oltre le soglie base tramite consumo a consumo (pay-as-you-go) per traffico e richieste, impostando un tetto massimo di spesa. La documentazione pubblica non indica la tariffa unitaria applicata: è possibile definire un massimale di protezione, ma non calcolare preventivamente il costo di un picco di traffico basandosi esclusivamente sui dati della pagina prezzi.
Anche le ricariche dei token presentano vincoli specifici: Bolt specifica che l'acquisto di quote aggiuntive è riservato a chi possiede il piano mensile Pro con dotazione massima o un qualsiasi piano Pro annuale. Il costo per ricarica varia a seconda del piano e viene comunicato all'interno dell'account: il canone iniziale di $25 non copre quindi da solo uno scenario di utilizzo continuativo ad alta intensità.
Il piano Teams applica tariffe per persona, non su plafond condiviso
Il piano Teams richiede $30 per utente ogni mese. Ciascun membro a pagamento ottiene una propria dotazione di token, vincolata al singolo account e non condivisibile con il resto dell'organizzazione. Gestire la fatturazione in modo centralizzato non si traduce quindi in un monte crediti comune.
Questo meccanismo risulta conveniente se tutti i componenti del team generano codice con regolarità. Diventa dispersivo quando una sola persona sviluppa e gli altri svolgono compiti di supervisione. Un gruppo di quattro persone comporta un costo di $120 al mese, pari a $1,440 all'anno, a cui vanno sommati eventuali costi per traffico extra, token aggiuntivi o integrazioni esterne.
Lovable Pro offre collaboratori illimitati a fronte di $25 al mese ($300 l'anno), a fronte dei $1,440 annui richiesti dal quartetto su Bolt. Il divario è di $95 ogni mese ($1,140 all'anno). Le metriche di riferimento non sono sovrapponibili: gli utenti di Lovable attingono a un fondo comune di 100 crediti, mentre i membri di Bolt dispongono di token individuali uniti a un ambiente di compilazione e infrastruttura proprietario. Il confronto chiarisce comunque la natura dell'investimento: il canone per postazione si giustifica unicamente se più persone sviluppano attivamente su Bolt o se i controlli di team e i design system riducono significativamente i costi di revisione del codice.
Il piano Enterprise risponde a esigenze formali di governance
La formula Enterprise adotta un modello di prezzo personalizzato. Introduce controlli di sicurezza avanzati, autenticazione SSO, log di tracciamento (audit log), supporto per adempimenti normativi, flussi e SLA su misura, criteri dedicati di conservazione e tutela dei dati, sessioni di inserimento guidate e supporto prioritario continuativo 24/7.
Le organizzazioni soggette a tali vincoli procedurali non dovrebbero formulare budget partendo dal costo di $30 previsto per il piano Teams nell'auspicio di estendere le garanzie a posteriori. È consigliabile richiedere una quotazione Enterprise fin dalla fase pilota se i criteri di conformità rientrano tra i requisiti bloccanti per l'adozione.
Il calcolo del costo per singolo risultato
Stimare il costo effettivo dell'abbonamento per ciascun prototipo completato è semplice: basta dividere la spesa fissa per il quantitativo di progetti che superano un test di accettazione predefinito. Il volume dei prompt inviati misura unicamente il livello di attività, non l'efficacia del lavoro svolto.
Per un professionista su piano Pro, il canone base ammonta a $300 l'anno. Se in un mese quattro prototipi superano i criteri di accettazione, l'incidenza dell'abbonamento corrisponde a $6.25 per prototipo validato. Qualora solo un progetto raggiunga il medesimo traguardo, l'incidenza sale a $25 per prototipo. Tale formula esclude le spese accessorie legate a traffico, database, servizi di terze parti e lavoro umano, ma evidenzia la metrica cruciale: la percentuale di completamento.
Per un team di quattro membri con una spesa di $120 mensili, otto prototipi approvati portano l'incidenza dell'abbonamento a $15 per unità. Con due soli prototipi approvati, il costo sale a $60 per ciascuno. Il software non è diventato più oneroso: è l'efficienza operativa del team ad aver generato meno risultati fruibili.
I limiti determinanti per la scelta d'acquisto
I vincoli di Bolt.new non sono semplici dettagli secondari. Emergono tipicamente nello stesso momento: quando il prototipo assume valore strategico, diverse persone vi mettono mano, il database diventa indispensabile e la spesa complessiva deve rimanere prevedibile. In tale contesto, l'acquisto di un pacchetto di token più ampio rischia spesso di nascondere una criticità d'architettura facendola passare per un problema di risorse.
1. Il consumo di token cresce con le dimensioni del progetto
Bolt chiarisce che la gran parte dei token viene assorbita dalla lettura e sincronizzazione dei file dell'applicazione: ne consegue che un codebase più esteso consuma più token per singolo messaggio. La medesima istruzione testuale risulterà sensibilmente più costosa nelle fasi avanzate di sviluppo rispetto alle battute iniziali.
Questo comportamento rende complessa la pianificazione dei consumi basandosi sul solo numero dei prompt. Un intervento limitato di formattazione grafica può esigere la lettura di un ampio contesto di file. Una richiesta di funzionalità poco dettagliata può innescare cicli di pianificazione, modifiche e correzioni su numerosi componenti. Il meccanismo di rollover dei piani a pagamento mitiga l'impatto dei periodi di inattività, ma non rende lineari i consumi di un'applicazione che cresce.
Per arginare questo fenomeno occorre formulare richieste mirate, strutturare l'applicazione in modo modulare e delegare la manutenzione ordinaria a un code editor tradizionale quando descrivere l'intervento a parole richiede più risorse dell'esecuzione manuale. Incrementare la quota di token è una scelta sensata se il lavoro rimane ben perimetrato; diventa uno spreco se l'agente perde continuamente il quadro architetturale o riscrive parti di codice stabili.
2. Il ripristino del progetto non coinvolge il database
La funzione di Version History di Bolt ripristina i file sorgente, ma non interviene sul database. Riportare l'applicazione a uno stato precedente lascia inalterato il database attuale. Questa rappresenta la limitazione più critica per chi scambia la promessa di un “builder full-stack” per una procedura di “ripristino full-stack”.
Codice e struttura dei dati si evolvono in modo parallelo. Se una modifica automatica rinomina una colonna, aggiorna una regola di autorizzazione o converte i dati, ripristinare solo il codice genera una divergenza di versione insanabile. Un contesto di produzione esige backup del database, tracciamento delle migrazioni e collaudi di ripristino che considerino congiuntamente codice e schema.
Va segnalato anche un vincolo d'esercizio minore: i database non pubblicati e poco utilizzati possono andare in pausa dopo sei o più giorni di inattività, richiedendo alcuni minuti per la riattivazione. I database pubblicati non sono soggetti a questa sospensione. Tale misura tutela le risorse dei server, ma può creare imprevisti a chi intende mostrare una demo dal vivo riaprendo un prototipo fermo da tempo.
3. La sincronizzazione con GitHub non sostituisce un flusso Git completo
Bolt supporta la creazione e il cambio di rami, ma non consente di effettuare merge dall'interfaccia: l'unione dei rami va eseguita direttamente su GitHub. Questa impostazione favorisce buone pratiche di sviluppo, poiché la revisione deve avvenire nel repository, ma contrasta con l'idea che un utente non tecnico possa gestire l'intero ciclo applicativo senza mai uscire da Bolt.
Il comportamento in caso di modifiche simultanee richiede particolare attenzione: Bolt verifica la presenza di aggiornamenti esterni ogni trenta secondi, ma se un commit su GitHub e un salvataggio su Bolt avvengono in modo quasi concomitante, Bolt privilegia i propri dati locali sovrascrivendo quanto presente sul repository remoto. I team devono evitare di modificare lo stesso ramo in parallelo da ambienti diversi. È opportuno lavorare su rami distinti, affidarsi a una sola sorgente di verità e assegnare a una figura specifica la gestione dei merge.
4. Lo sviluppo mobile parte con semplicità ma si conclude negli strumenti per sviluppatori
Bolt ricorre a Expo quando il primo prompt richiede un'app mobile, ed Expo Go permette di collaudare rapidamente il risultato sul proprio telefono. Un progetto impostato originariamente per il web non può tuttavia essere convertito con facilità in un'applicazione mobile: la scelta architetturale deve essere compiuta fin dall'avvio.
La fase di pubblicazione negli app store esce dalla semplicità del browser. Il codice deve essere scaricato in locale e gestito con Node.js LTS, Git, gli strumenti da riga di comando di Expo, account sviluppatore attivi, certificati digitali e procedure di revisione dei marketplace. Questo flusso resta più accessibile rispetto alla scrittura di due app native separate, ma è lontano dall'essere una pubblicazione mobile con un solo clic.
5. L'hosting può interrompersi o presentare costi difficilmente quantificabili
I siti associati al piano Free smettono di erogare contenuti una volta esaurita la soglia mensile condivisa a livello di account. Il piano Pro consente di gestire il traffico eccedente tramite tariffazione a consumo con un tetto di spesa prefissato, ma la documentazione non indica la tariffa applicata per singola unità di traffico. Chi gestisce il progetto può limitare il rischio economico una volta autenticato, ma non ha modo di calcolare con esattezza l'impatto economico di un picco di accessi prima dell'acquisto.
Le quote di traffico sono inoltre condivise sull'intero profilo. La pubblicazione contemporanea di diverse demo per clienti o pagine promozionali fa sì che un progetto con traffico intenso riduca i margini a disposizione degli altri. Le agenzie dovrebbero separare la proprietà degli account dei clienti o monitorare con costanza l'uso aggregato, anziché dare per scontato che ciascuna istanza disponga di risorse isolate.
6. L'assistenza tecnica è strutturata in base alla gravità del disservizio
Bolt garantisce agli utenti Free il supporto tramite la community Discord. Gli abbonati ai piani a pagamento possono accedere all'assistenza via email dal lunedì al venerdì durante l'orario d'ufficio. Il piano Enterprise include invece supporto prioritario 24/7 e un referente di contatto dedicato.
Questa suddivisione è consueta per i prodotti software, ma incide direttamente sulle scelte di utilizzo. Un'applicazione in produzione che richieda tempi certi di intervento durante la notte o nel fine settimana non è compatibile con le tutele del piano Pro a $25 o del piano Teams a $30. Un simile requisito operativo impone il passaggio alle condizioni personalizzate di Enterprise o la migrazione a un'infrastruttura gestita autonomamente.
7. Governance aziendale e costi per postazione non viaggiano di pari passo
Il piano Teams offre controlli di gestione utili, il supporto ai design system e la fatturazione unica, ma i requisiti di conformità più vincolanti indicati nel listino ricadono sotto il piano Enterprise: autenticazione SSO, log di tracciamento, assistenza per la conformità normativa, criteri di data retention e SLA personalizzati. Di conseguenza, un'azienda potrebbe trovarsi ad aver bisogno delle tutele Enterprise prima ancora che il numero dei propri sviluppatori renda conveniente il passaggio a Teams.
L'assegnazione individuale dei token introduce un'ulteriore rigidità: i revisori non possono cedere la propria capacità inutilizzata a chi programma a tempo pieno. Prima di sottoscrivere l'abbonamento, il team deve verificare quante siano le figure effettivamente operative sul codice, stabilire come coinvolgere i revisori e confrontare i costi totali con soluzioni a plafond condiviso.
- Il piano Pro a $25 unisce generazione guidata da prompt, database, opzioni di autenticazione, hosting e un canale d'uscita verso GitHub.
- Il codice sorgente può essere gestito al di fuori di Bolt, facilitando il passaggio di consegne a un programmatore o a un altro fornitore di hosting.
- Bolt Database e la distribuzione su domini .bolt.host consentono di convalidare un flusso completo senza dover creare account su piattaforme terze.
- Il supporto a Expo offre una via concreta per realizzare prototipi mobile multipiattaforma, mentre i design system di Teams utilizzano codice reale anziché mere imitazioni grafiche.
- I token a pagamento non consumati restano validi per un ulteriore mese, smentendo una credenza diffusa su scadenze più rigide.
- Il consumo di token cresce con l'aumentare dei file del progetto, rendendo il piano base inadatto a stimare i costi di un'applicazione complessa.
- La cronologia delle versioni (Version History) non include il ripristino dei database.
- Il merge dei rami su GitHub deve essere eseguito all'esterno della piattaforma, e sincronizzazioni quasi simultanee possono sovrascrivere la versione su GitHub.
- La pubblicazione di app mobile richiede strumenti locali e account dedicati sui singoli store.
- Le tariffe orarie e a consumo del traffico extra non sono esplicitate chiaramente nella pagina dei piani di hosting.
- Il supporto per il piano Free è limitato alla community; l'assistenza via email opera solo nei giorni feriali, mentre l'assistenza h24 prioritaria è riservata a Enterprise.
Verdetto: Bolt.new è una solida piattaforma per prototipi con uscita rapida
Bolt.new giustifica il proprio prezzo se una persona deve trasformare un flusso operativo ben definito in codice sorgente verificabile e ospitato online, all'interno di un'organizzazione che prevede un rapido passaggio di consegne su GitHub. Il piano Pro a $25 costituisce il punto di partenza corretto per questo scopo, poiché i limiti giornalieri e l'arresto improvviso dell'hosting del piano Free non garantiscono continuità a un ciclo di lavoro serio.
La valutazione cambia se l'iniziativa dispone già di un'architettura strutturata, coinvolge più ingegneri, gestisce dati critici o deve soddisfare accordi di servizio vincolanti. Cursor risulta più efficace per intervenire direttamente su repository preesistenti. Replit è preferibile se le priorità sono un workspace cloud più completo, l'esecuzione di agenti paralleli o un ripristino certificato del database. Lovable rappresenta l'opzione migliore quando la collaborazione orientata al design e il coinvolgimento di utenti illimitati contano più della gestione manuale di codice e infrastruttura.
La regola di arresto è altrettanto chiara: non rispondere a ricorrenti incongruenze d'architettura, difficoltà di ripristino o conflitti di sincronizzazione acquistando pacchetti di token più grandi. Se il progetto richiede frequenti revisioni manuali del codice, allineamento coordinato dei rami, migrazioni controllate dei dati e una gestione operativa continua, trasferisci il cuore dello sviluppo su un flusso basato su repository tradizionale. Bolt potrà continuare a essere utilizzato per generare prototipi o contribuire a singoli rami, ma non dovrà più fungere da gestore centrale dell'intero sistema.
La tabella di marcia della prima settimana
Dedica una settimana lavorativa per valutare l'adeguatezza dello strumento su un flusso sacrificabile, tenendolo lontano dal database aziendale di produzione.
Lunedì: definisci un singolo risultato misurabile
Indica chiaramente l'utente finale, lo stato di partenza, il risultato atteso, le informazioni da salvare e gli accessi da interdire. Scegli un'operazione sufficientemente circoscritta affinché possa essere portata a termine dall'inizio alla fine da una sola persona.
Martedì: avvia lo sviluppo indicando l'infrastruttura esatta
Richiedi esplicitamente la creazione di database, meccanismi di autenticazione, ruoli utente e procedure di recupero credenziali. Utilizza il piano Free finché i dati rimangono di prova, annotando quali richieste generano errori o riscritture.
Mercoledì: collega il repository GitHub
Crea il repository privato, apri un ramo di sviluppo secondario ed effettua il merge tramite l'interfaccia di GitHub. Controlla che l'anteprima su Bolt e lo stato del repository coincidano perfettamente al termine dell'operazione.
Giovedì: metti alla prova i casi di errore critici
Esegui test simulando un ruolo non autorizzato, una sessione scaduta, un link di reindirizzamento non valido, una modifica strutturale allo schema dati e la riattivazione di un database in pausa. Traccia con precisione quali passaggi di ripristino impongono interventi manuali al di fuori della schermata generata.
Venerdì: applica la regola decisionale
Passa al piano Pro solo se il flusso ha superato tutti i controlli, se il responsabile tecnico approva la qualità del codice e se il consumo dei token si dimostra commisurato al valore ottenuto. In caso contrario, orientati verso una delle piattaforme alternative specializzate nella specifica area critica riscontrata.
Per una panoramica più articolata delle opzioni disponibili, consulta la guida aggiornata ai migliori strumenti per il vibe coding. Qualora Replit rappresenti l'opzione di riferimento ma i suoi abbonamenti risultino fuori portata, la selezione di alternative a Replit per creare app AI gratis consentirà di perfezionare la scelta successiva.
Domande frequenti
Bolt.new è un sito web affidabile e legittimo?
Sì. Bolt.new è un prodotto commerciale operativo sviluppato da StackBlitz, dotato di listino pubblico, documentazione dettagliata, note di rilascio periodiche e canali di supporto ufficiali. Questo garantisce l'affidabilità dell'azienda fornitrice, ma non certifica di per sé l'idoneità del codice generato per qualsiasi contesto d'uso. Collega tempestivamente GitHub, controlla la gestione delle autorizzazioni e predisponi procedure per il ripristino dei dati prima di elaborare informazioni di reale valore operativo.
Bolt.new funziona davvero?
Bolt implementa percorsi documentati e funzionanti per applicazioni web, database, autenticazione utente, hosting, integrazione con GitHub e progetti mobile su tecnologia Expo. È pertanto in grado di produrre sistemi operativi e non semplici bozze visive. Questa recensione si basa sull'analisi delle specifiche contrattuali e architetturali del servizio senza l'esecuzione di benchmark empirici, motivo per cui non fornisce percentuali di successo predeterminate né garantisce che architetture complesse siano pronte per la produzione in assenza di revisione tecnica.
Bolt.new è migliore di Cursor?
Bolt è superiore per convertire un brief sintetico in una prima applicazione funzionante online con infrastruttura pronta all'uso, gestendo ogni passaggio nel browser. Cursor risulta invece preferibile per consentire a sviluppatori esperti di lavorare direttamente su un codebase strutturato esistente. Utilizza Bolt prima che l'impianto architetturale sia consolidato; passa a Cursor quando il controllo minuzioso del codice e la gestione della repository rappresentano l'attività prevalente.
Bolt.new è sicuro?
Bolt mette a disposizione controlli di autenticazione, allowlist di URI, protezione contro l'uso di password compromesse, pannelli di sicurezza e policy di governance per il piano Enterprise. Il grado effettivo di sicurezza dipende tuttavia dalla correttezza delle regole di autorizzazione implementate, dalla gestione delle variabili d'ambiente segrete, dalle dipendenze adottate, dalla struttura del database e dalle routine di backup. La mancanza di una funzione di ripristino del database nella Version History impone di configurare le procedure di salvataggio in modo autonomo.
Bolt.new è completamente gratuito?
Bolt propone un piano Free a $0 che consente la gestione di progetti pubblici e privati, 1 million di token mensili con soglia di 300,000 token giornalieri, database illimitati e funzioni di hosting. Questa versione include il marchio di Bolt, fissa il limite di caricamento a 10MB e sospende l'erogazione delle pagine non appena viene raggiunta la quota complessiva di 10GB di traffico o le 333,333 richieste mensili a livello di profilo.
Bolt.new è gratis per un anno intero?
Il listino pubblico attuale prevede una versione Free a costo zero senza presentarla come una promozione annuale limitata per un piano a pagamento. La dotazione gratuita rimane vincolata a restrizioni su token, dimensioni dei file, loghi visibili e volumi di traffico. Le capacità avanzate a pagamento partono dal piano Pro a $25 al mese con fatturazione mensile.
Quali sono i prezzi di Bolt.new?
I prezzi attuali di Bolt prevedono il piano Free a $0, il piano Pro a $25 al mese, il piano Teams a $30 per utente al mese e il piano Enterprise su preventivo concordato. Il listino riporta un risparmio fino al 28% scegliendo il pagamento su base annuale. Il piano Pro mette a disposizione una base di 10 million di token mensili; la quota di token a pagamento non consumata può essere trasferita al mese seguente, mantenendo validità fino a due mesi consecutivi a fronte di una sottoscrizione attiva.
Meglio Bolt.new o Lovable?
Scegli Bolt se cerchi un processo rapido di generazione da prompt a codice sorgente dotato di Bolt Database, hosting ed esportazione anticipata verso GitHub. Scegli Lovable per progetti orientati alla cura del design e al lavoro di squadra: il piano Pro a $25 accoglie collaboratori illimitati all'interno del medesimo monte crediti. Nei team composti da più figure operative, Bolt richiede $30 per ciascun membro: il numero di postazioni complessive può quindi ribaltare la convenienza economica anche a fronte di un costo identico per utente singolo.
Scarica la checklist per l'audit dei flussi aziendali con IA
La checklist gratuita AI Business Workflow Audit Checklist ti aiuta a isolare un singolo processo aziendale, stimarne i dati e il costo del mancato funzionamento, identificare un responsabile operativo e fissare una chiara regola di arresto prima di acquistare un altro software di sviluppo guidato da prompt. Iscriviti per ricevere la prossima edizione verificata.
3 set 2026
Preferisca questo sito su Google
Segni omidsaffari.com come fonte preferita e Google lo mette in evidenza per lei in Top Stories, AI Overviews e AI Mode.
