Avaliação do Bolt.new: Análise Completa de Recursos e Preços (2026)
O Bolt.new custa a partir de $25/mês. Analisamos limites de tokens, banco de dados e quando escolher Lovable, Replit ou Cursor.
O Bolt.new vale os $25 por mês para um fundador solo que precisa transformar uma ideia delimitada de web app em um protótipo hospedado e está disposto a inspecionar o código gerado. Pule a ferramenta se o seu caso for um sistema maduro em produção, um fluxo de trabalho não técnico focado em design ou qualquer projeto cujo banco de dados você não possa se dar ao luxo de recuperar manualmente: o rollback de projeto do Bolt ainda não restaura o banco de dados.
O que é o Bolt.new em resumo
O Bolt.new é um construtor de aplicativos no navegador que transforma um briefing textual em código editável de aplicação, executa esse código em um ambiente de desenvolvimento online e pode adicionar banco de dados, autenticação e hospedagem sem exigir que você configure esses serviços antes. Ele fica entre um construtor no-code e um editor de código com IA: você trabalha por meio de conversação, mas o resultado final continua sendo uma base de código pronta para ir para o GitHub. Isso o torna excelente para protótipos, ferramentas internas e produtos web bem delimitados, não para terceirizar cada decisão de engenharia a um prompt.
O produto atual é materialmente diferente daquele com o qual muitos projetos anteriores começaram. As notas de lançamento do Bolt afirmam que o v1 Agent e o Discussion Mode foram descontinuados em August 3, 2026. Os projetos restantes migraram para o Bolt Agent mantendo seus arquivos e histórico de chat, enquanto o Plan Mode se tornou o espaço para estruturar o raciocínio de uma construção sem alterar o código imediatamente. O recurso de ditado por voz também está ativo, transcrevendo a fala em um prompt editável antes do envio.
Comparativo: Bolt.new vs alternativas em resumo
O Bolt.new se destaca quando você quer reunir prompt, código, banco de dados e o primeiro deploy em um único fluxo no navegador. O Lovable vence quando refinamento visual e colaboração de baixo atrito importam mais do que o controle no nível do código. O Replit é o ambiente de desenvolvimento em nuvem mais abrangente. Já o Cursor é a escolha ideal quando um desenvolvedor experiente já possui um repositório e prefere um editor de código nativo em IA em vez de um construtor de apps tudo-em-um.
Essa tabela esconde uma distinção importante. Bolt.new, Lovable e Replit conseguem dar o pontapé inicial em uma aplicação, enquanto o Cursor pressupõe que você se sinta confortável manipulando código diretamente. Compará-los apenas pelo preço da assinatura ignora o custo do repasse técnico. Um fundador não técnico pode pagar os mesmos $25 pelo Lovable Pro e economizar horas de revisão de código. Um desenvolvedor pode pagar $20 pelo Cursor e evitar pagar um gerador de prompts para reler um projeto inteiro a cada nova mensagem.
Essa é a regra central desta análise: escolha o ambiente que mantém a parte mais difícil do seu projeto visível. O Bolt mantém a infraestrutura visível o suficiente para migrar para o GitHub. O Lovable mantém o design e a colaboração visíveis. O Replit mantém o ambiente geral de desenvolvimento visível. O Cursor mantém o próprio código visível.
Para quem o Bolt.new é indicado e quem deve evitá-lo
O Bolt.new foi feito para criadores que valorizam ter uma primeira versão funcional com rapidez, mas não confundem essa versão com um sistema finalizado. O perfil ideal de comprador possui um fluxo de trabalho bem definido, sabe descrever os dados e permissões e vai inspecionar o código gerado ou envolver alguém capaz de fazer isso. O pior perfil chega com uma ideia grandiosa de produto, sem critérios de aceitação, com dados sensíveis e a ilusão de que basta enviar mais prompts para solucionar qualquer problema de arquitetura.
Boa escolha: fundador solo validando um fluxo de trabalho específico
O Bolt.new faz sentido para um fundador solo que precisa validar um fluxo de trabalho delimitado antes de contratar uma equipe de desenvolvimento. Imagine um sistema de agendamento para professores particulares autônomos. A primeira versão útil exige perfis de professores, horários disponíveis, formulário de reserva, e-mail de confirmação e um painel administrativo simples. Essas peças se conectam com precisão a um banco de dados, autenticação e uma interface hospedada.
O fundador consegue descrever as funções de usuário, pedir ao Bolt que crie as tabelas e o fluxo de login, publicar uma prévia pública ou privada e enviar o código para o GitHub antes de convidar os primeiros usuários. O produto ainda precisará de testes, decisões de privacidade e manutenção, mas o Bolt encurta a distância entre um fluxo descrito em texto e algo clicável.
O encaixe se perde quando o fundador não sabe distinguir se uma checagem de permissão deve ficar na interface ou no banco de dados. Um botão que some para o usuário errado não equivale a uma política de segurança segura no nível da linha (RLS). O Bolt pode gerar ambas, mas alguém precisa verificar as duas.
Boa escolha: gerente de produto provando um fluxo antes do compromisso da engenharia
O Bolt.new também atende bem ao gerente de produto que precisa de um protótipo convincente e baseado em dados reais, e não de mais um mockup estático. Uma ferramenta de aprovação de devoluções, por exemplo, pode incluir uma fila de solicitações, cadastro do cliente, códigos de motivo e ações restritas por função. Os stakeholders podem interagir com o fluxo e identificar lacunas antes do início de uma sprint de engenharia.
O gerente de produto deve encarar a aplicação gerada como um discovery de produto executável. O ganho real não é colocar o protótipo diretamente em produção sem alterações. O ganho é descobrir se o fluxo faz sentido enquanto mudar as coisas ainda é barato. Conectar ao GitHub gera um artefato prático para um engenheiro avaliar, mas isso não transforma o protótipo em uma arquitetura aprovada.
Boa escolha: pequena agência com uma política clara de entrega técnica
O Bolt.new pode ajudar uma pequena agência a criar ferramentas para campanhas, calculadoras, portais e protótipos, desde que cada projeto siga uma disciplina de encerramento rigorosa. A agência deve definir já no início se a entrega continuará na hospedagem do Bolt, se irá para um repositório do cliente ou se será refeita como desenvolvimento sob medida. Essa definição determina quem gerencia domínios, segredos de ambiente, recuperação de banco de dados e futuras alterações.
Os recursos do plano Teams ajudam no acesso centralizado, compartilhamento organizacional e contexto com design systems, mas a cobrança por usuário precisa ser monitorada. Cada usuário pago recebe sua cota individual de tokens, e esses tokens não são compartilhados. Uma agência com um desenvolvedor pesado e vários revisores pode acabar pagando por capacidade ociosa enquanto o construtor principal fica sem tokens.
Pule o Bolt.new se a equipe não for técnica e focar em design: escolha o Lovable
O Lovable é o caminho mais recomendado quando o objetivo principal é obter interfaces visuais refinadas, capacidade de criação compartilhada e menos decisões voltadas a código. O Lovable Pro custa $25 por mês e inclui 100 créditos mensais, usuários ilimitados, acúmulo de créditos não utilizados, recargas extras, domínios personalizados, funções de acesso, limites de crédito por membro, suporte por e-mail e design systems.
Esse modelo de usuários ilimitados contrasta diretamente com o Bolt Teams a $30 por membro mensalmente. Os créditos compartilhados do Lovable não são necessariamente mais generosos, e a sua métrica não se traduz diretamente em tokens do Bolt. A grande vantagem é organizacional: fundador, designer e profissional de marketing conseguem colaborar dentro de um único espaço Pro sem multiplicar a assinatura básica pela quantidade de pessoas.
Prefira o Lovable quando a pergunta inicial for: “Toda a nossa equipe consegue moldar esta interface?”. Prefira o Bolt quando a questão for: “Podemos ter uma base de código funcional, infraestrutura e entrega no GitHub a partir do mesmo navegador?”. Se ninguém do time for inspecionar o código, o controle extra oferecido pelo Bolt será uma capacidade pouco aproveitada.
Pule o Bolt.new se precisar de um workspace mais amplo em nuvem: escolha o Replit
O Replit se torna a melhor alternativa quando você procura um ambiente abrangente de desenvolvimento em nuvem, concorrência de múltiplos agentes e uma transição suave entre pequenos testes e uma infraestrutura completa de desenvolvedor. O Replit Core custa $20 por mês ou $18 mensais no faturamento anual e oferece dois agentes paralelos, workspaces ilimitados e $20 aplicáveis aos seus modelos mais avançados.
A diferença fica ainda mais evidente nos planos superiores do Replit. O Replit Pro custa $100 mensais ou $90 por mês no plano anual e inclui dez agentes simultâneos, até quinze colaboradores, até cinquenta visualizadores e rollback de banco de dados de até vinte e oito dias. Já o Version History nativo de projetos do Bolt simplesmente não restaura o banco de dados.
Isso não significa que o Replit seja superior para qualquer caso. Apenas aponta que um comprador que valoriza a atuação simultânea de agentes ou rollback garantido de banco de dados deve colocar essas exigências acima do plano inicial mais acessível de $25 do Bolt. Fique com o Bolt para um fluxo objetivo de prompt para app. Fique com o Replit quando o ambiente de desenvolvimento em si for o produto que você deseja contratar.
Pule o Bolt.new se o repositório já existe: escolha o Cursor
O Cursor é a melhor saída para um desenvolvedor experiente cuja aplicação já existe e está estruturada. O plano Cursor Individual Pro custa $20 por mês e expande os limites do seu Agent, além de fornecer modelos de ponta, MCPs, skills, hooks e agentes em nuvem.
O Cursor não elimina a necessidade de definir hospedagem, autenticação ou banco de dados — e é exatamente por isso que ele se destaca depois que essas decisões já foram tomadas. O desenvolvedor edita diretamente o repositório em vez de depender de um gerador de apps para reinterpretar e sincronizar o projeto completo repetidas vezes.
Adote o Cursor quando o trabalho deixar de ser “definir a forma do produto” e passar a ser “alterar esta base de código estabelecida dentro de regras claras de arquitetura e revisão”. Nossa análise comparativa detalhada sobre Codex, Claude Code e Cursor é o próximo passo ideal de leitura assim que a gestão direta do código assumir o papel central do seu dia a dia.
Recurso 1: protótipos full-stack com banco de dados e hospedagem
A maior força do Bolt.new não está em desenhar uma tela. Está em aproximar a interface, o banco de dados, a autenticação e o primeiro deploy a ponto de uma única pessoa conseguir modelar um fluxo completo. É por essa razão que o Bolt entrega mais valor para um portal de atendimento ou ferramenta de reservas do que para um mockup de marketing que exige apenas telas bonitas.
Considere uma empresa de serviços residenciais substituindo um fluxo manual baseado em e-mails e planilhas. A solução precisa de formulário para clientes, registro de chamados, fila de triagem, atribuição para técnicos e histórico de status. O fluxo ideal no Bolt começa definindo essas entidades e regras de acesso de forma detalhada, em vez de pedir um genérico “aplicativo moderno de serviços”.
Defina o fluxo de trabalho e os papéis
Descreva com clareza os papéis de cliente, atendente e técnico. Aponte os estados pelos quais um chamado pode passar, o que cada função tem permissão para visualizar e quais ações avançam a solicitação. Isso entrega ao Bolt um modelo funcional de comportamento, não apenas uma expectativa estética.
Solicite explicitamente o modelo de dados
Peça a criação de tabelas para clientes, solicitações de serviços, atribuições e eventos de status. O Bolt provisiona o banco de dados automaticamente quando o projeto requer, mas um modelo explícito facilita a inspeção e impede que dados essenciais fiquem salvos apenas no estado da interface.
Especifique autenticação e regras de acesso
Exija cadastro por e-mail, login, fluxo de recuperação de senha e controle de acesso baseado em funções (RBAC). A documentação oficial alerta que a autenticação pode não ser configurada de forma automática, mesmo quando o banco de dados é provisionado. Valide as URLs de redirecionamento e as políticas de acesso antes de abrir o link para testes externos.
Publique uma prévia descartável
Tanto usuários do plano Free quanto do Pro podem publicar em um endereço
.bolt.host. Use dados descartáveis nessa etapa inicial. Chame um atendente real para simular a triagem, atribuição e encerramento, anotando cada lacuna encontrada no fluxo.Mova o código antes que os dados se tornem críticos
Vincule o GitHub logo após alcançar o primeiro fluxo funcional e estável. Não espere até ter cadastros reais de clientes para descobrir de que maneira o projeto, o banco de dados e o deploy devem ser desacoplados.
O Bolt Database reduz a fricção de configuração. Ele consegue instanciar um banco quando o sistema necessita, traz controles de autenticação, expõe logs e segredos de ambiente e permite conectar uma conta Supabase diretamente na etapa inicial. A proteção contra senhas vazadas vem ativada por padrão quando o Bolt gera o banco. No entanto, se o banco for vinculado ou reivindicado via Supabase, esse recurso passa a depender do plano contratado no Supabase, ficando desativado no plano Supabase Free.
O ponto crítico aqui é diferenciar funcionalidades geradas de comportamentos validados. Uma tela de login pode parecer operacional enquanto os redirecionamentos de redefinição de senha apontam para o lugar errado. Uma fila de triagem pode esconder os registros de outros clientes na interface, mas manter uma política no banco que ainda permite o acesso indevido. O painel do Bolt traz campos para URLs do site, listas de permissão de URI, provedores e modelos de e-mail, mas a conferência humana continua indispensável.
A hospedagem embutida segue a mesma lógica: é muito prática, porém tem limites claros. A hospedagem no plano Free oferece domínio .bolt.host, 10GB de largura de banda e 333,333 requisições mensais compartilhadas por toda a conta. No Pro, esse teto sobe para 30GB e 1 milhão de requisições mensais, adiciona suporte a domínios personalizados e permite tráfego excedente sob demanda (pay-as-you-go). São limites adequados para validar a maioria das ideias iniciais, mas são compartilhados entre todos os projetos da mesma conta.
O grande gargalo aparece na recuperação de desastres. O Version History do Bolt restaura arquivos do projeto, mas não recupera o banco de dados. Voltar o código da aplicação para o estado de ontem manterá o banco de dados no estado de hoje. Essa assimetria pode ser mais arriscada do que a ausência total de um botão de rollback, pois cria a falsa sensação de que código e dados regridem juntos.
No exemplo dos serviços residenciais, imagine reverter o código para uma versão anterior à renomeação de um campo de status, enquanto o banco continua com o esquema novo. Interface e banco de dados entrarão em conflito imediato. Antes que o projeto assuma operações reais, estabeleça rotinas de backup, migrações de esquema e um procedimento de recuperação comprovado fora da linha do tempo do Bolt.
Recurso 2: propriedade do código via integração com GitHub
O Bolt.new se posiciona acima de ferramentas no-code proprietárias justamente porque a aplicação pode ser sincronizada com o GitHub e transferida para outro provedor de hospedagem ou ambiente de desenvolvimento a qualquer momento. No entanto, a portabilidade só é útil de verdade se for adotada desde o início. Dizer que “o código pode ser exportado” não serve como plano de contingência se o repositório nunca foi conectado e ninguém faz ideia de qual commit corresponde ao banco de dados em execução.
A documentação de Git do Bolt detalha que repositórios criados a partir do Bolt iniciam como privados na branch main. O sistema realiza commits automáticos das alterações que não quebram o projeto, verifica o GitHub a cada trinta segundos em busca de modificações externas e suporta a criação e troca de branches.
Um fluxo seguro de trabalho e entrega segue estes passos:
Conecte logo após atingir o primeiro estado estável
Crie o repositório enquanto o projeto ainda utiliza dados de teste. Verifique se os arquivos esperados, os exemplos de variáveis de ambiente e os arquivos de dependências estão no lugar certo. Chaves e segredos confidenciais jamais devem entrar no repositório.
Crie uma branch para cada alteração relevante
Isole em uma nova branch o desenvolvimento de fluxos de pagamento, ajustes de permissões ou redesigns. O Bolt mantém o contexto das branches isolado, o que diminui o risco de misturar trabalho inacabado com a versão em produção.
Revise e faça o merge dentro do GitHub
O Bolt permite criar e alternar entre branches, mas não realiza merges pela interface. Abra o pull request e conclua a junção diretamente no GitHub, permitindo que um desenvolvedor revise o código e registre formalmente o histórico de mudanças.
Sincronize antes de enviar novos prompts
Aguarde a atualização do merge ser refletida no Bolt, abra a branch correta e confira a prévia. A ferramenta pesquisa o GitHub a cada trinta segundos, mas esse intervalo automatizado não substitui a verificação manual do estado do código antes de novas edições.
Esse formato transforma o Bolt em uma plataforma de partida, não em um aprisionamento tecnológico. Um engenheiro pode sair do Bolt, editar o código diretamente no repositório, subir em outra infraestrutura e voltar mais tarde. Isso se torna muito vantajoso conforme o protótipo evolui e passa a demandar testes automatizados, monitoramento, revisão de arquitetura ou uma camada diferente de backend.
Existem duas restrições que precisam ficar claras antes de classificar esse fluxo como um “Git tradicional”. Primeiro: o merge precisa ser feito fora do Bolt. Usuários sem bagagem técnica ainda precisarão entender o conceito de pull requests ou contar com o apoio de quem entenda. Segundo: existe uma condição documentada de conflito. Se houver alterações quase simultâneas no Bolt e no GitHub, o Bolt prioriza as suas próprias modificações e sobrescreve o conteúdo do GitHub.
A solução não é deixar de usar, mas manter a governança. Evite editar a mesma branch no Bolt e em outro editor ao mesmo tempo. Trabalhe com branches, use o GitHub para aprovar merges e estabeleça o repositório como a fonte oficial da verdade. Se o projeto atingir um estágio em que vários desenvolvedores realizam commits diários, o Bolt deve atuar como colaborador pontual, e não como o núcleo central do fluxo.
Recurso 3: criação de aplicativos móveis com Expo
O Bolt.new possibilita iniciar aplicativos móveis multiplataforma por meio do Expo, mas o prompt inicial determina o sucesso dessa jornada. O guia de Expo do Bolt pontua com clareza: um projeto iniciado com foco em web não pode ser convertido para mobile de forma simples. Portanto, o comando “transforme este app em mobile” representa uma reestruturação arquitetural completa, e não um simples ajuste visual.
Pense em um aplicativo de planejamento de refeições. O prompt de abertura já deve definir que a aplicação será um app móvel para iOS e Android, detalhar as entidades de receitas e usuários, além de indicar as interações de toque mais importantes. Com isso, o Bolt inicializa a estrutura sobre o Expo, framework que viabiliza o compartilhamento de uma mesma base de código entre web e sistemas móveis.
A checagem do app no celular é bastante fluida. Basta abrir o projeto móvel, clicar em Device Preview, escanear o QR code pelo aplicativo Expo Go e interagir com o app no próprio aparelho físico. Isso antecipa problemas de comportamento do teclado virtual, toque em botões, telas pequenas e navegação que passariam despercebidos no navegador do computador.
O fluxo de publicação nas lojas, contudo, não ocorre inteiramente dentro do Bolt. Publicar na Google Play Store e Apple App Store exige baixar o código, abri-lo em um editor local, utilizar um computador com Node.js LTS e Git instalados, configurar o Expo Application Services (EAS) e manter contas ativas de desenvolvedor na Apple e no Google. O processo de build também pode esbarrar em exigências de certificados, incompatibilidade de bibliotecas nativas ou diretrizes das lojas.
Esse limite ajuda a determinar quem deve conduzir cada etapa. O fundador pode perfeitamente usar o Bolt para validar uma ideia mobile sem precisar programar em Swift ou Kotlin. Ainda assim, será preciso alguém responsável pela entrega para lidar com assinaturas digitais, painéis das lojas, relatórios de falhas, termos de privacidade e revisões de diretrizes. O Expo elimina a necessidade de programar duas vezes; ele não elimina a complexidade operacional das plataformas móveis.
Adote este passo a passo:
Defina o escopo mobile logo no primeiro prompt
Mencione explicitamente iOS e Android, a interação mobile primária, suporte offline e necessidades de câmera, geolocalização ou notificações antes da geração de código.
Valide a experiência em um smartphone físico
Utilize o Expo Go desde os primeiros momentos. Teste o caminho crítico completo, como cadastrar ingredientes, planejar refeições e confirmar se os dados persistem após fechar e reabrir o app.
Exporte os arquivos antes de preparar a publicação
Faça o push do código para o GitHub e configure o ambiente local antes de manipular credenciais das lojas de aplicativos. O repositório revisado deve ser a fonte das builds de distribuição.
Defina o responsável pela entrega técnica
Defina com antecedência quem cuidará dos certificados, testes via TestFlight ou faixas de teste da Google Play, notas de versão e tratamento de crashes. Sem essa definição, o projeto continua sendo apenas um protótipo, não um lançamento mobile real.
Escolha o Bolt para projetos mobile quando o foco imediato for validar a aceitação do fluxo de telas. Evite torná-lo o único ambiente quando recursos avançados de hardware, serviços em segundo plano ou automações complexas de deploy em lojas já fizerem parte do desafio central.
Recurso 4: desenvolvimento orientado por design system para equipes
O suporte a design systems no Bolt.new traz grandes vantagens para empresas que já possuem biblioteca de componentes, regras de espaçamento e manuais de marca consolidados. A ferramenta não transforma um guia de estilos genérico em código pronto por mágica: a qualidade da fonte define se o Bolt conseguirá utilizar componentes reais ou se apenas tentará imitar cores e fontes.
A conexão de design systems próprios exige a assinatura do plano Teams. A equipe pode alimentar o Bolt com links para repositórios no GitHub, pacotes NPM, instâncias do Storybook, portais de documentação ou arquivos locais. O Bolt analisa esses materiais e instancia um Storybook interno para que os membros visualizem exatamente quais componentes a IA compreende.
O melhor caso de uso é o de empresas de software B2B que já distribuem botões, formulários, componentes de dados e layouts como um pacote NPM. O time importa esse pacote, conecta a documentação de apoio do Storybook e inclui diretrizes para o agente, orientando-o a priorizar temas específicos e descartar componentes obsoletos. Assim, o gerente de produto cria novos protótipos montados com o design system da empresa, em vez de recorrer a elementos de interface genéricos.
A documentação da ferramenta é honesta em relação aos dados de entrada: pacotes NPM e repositórios no GitHub oferecem resultados muito superiores aos de um simples site de documentação. Páginas com prints e explicações conceituais podem ensinar o padrão estético, mas os pacotes de componentes entregam a implementação real que o modelo precisa reaproveitar.
Há limites operacionais estabelecidos. Cada equipe no Teams pode cadastrar ou sincronizar até dez design systems por semana. O upload de fontes locais aceita até dez arquivos (como PDFs ou imagens). A inserção de frameworks concorrentes ou bibliotecas legadas misturadas degrada a assertividade do modelo, mostrando que adicionar arquivos demais sem critério pode ser contraproducente.
Defina uma fonte canônica de componentes
Utilize o repositório ou o pacote NPM que a equipe de engenharia já reconhece como padrão oficial. Nunca misture pacotes descontinuados com versões modernas na mesma configuração.
Insira documentação voltada a decisões técnicas
Adicione diretrizes que expliquem o momento correto de utilizar cada elemento, exigências de acessibilidade e variações de temas. Prints de tela não ensinam à IA como o componente reage a eventos e dados.
Configure instruções enxutas para o agente
Especifique ao Bolt quais frameworks, versões e bibliotecas de componentes devem ser seguidos, além de quais itens devem ser explicitamente ignorados. Uma restrição curta e precisa costuma ser mais eficiente do que pastas repletas de exemplos visuais.
Construa um fluxo representativo como teste
Gere uma tela de cadastro, estados de validação, telas vazias (empty states) e listagens de dados. Compare a fidelidade do código gerado com o sistema original antes de liberar o fluxo para toda a organização.
Esse recurso justifica o investimento no plano Bolt Teams quando protótipos consistentes com a marca evitam retrabalho recorrente e o time já possui uma biblioteca de código mantida. Por outro lado, ele não compensa o custo de $30 por usuário para quem possui apenas um logotipo, uma paleta de cores e nenhum componente em código. O Lovable Pro já oferece suporte a design systems por $25 com usuários ilimitados; a cobrança extra do Bolt só faz sentido quando o controle de componentes via repositório e o ecossistema integrado de build forem indispensáveis.
Preços do Bolt.new: planos atuais e métrica de custo por entrega
A estrutura pública de cobrança do Bolt.new segue quatro faixas: $0 no plano Free, $25 no Pro, $30 por usuário no Teams e propostas sob medida no Enterprise. A dificuldade real consiste em entender como o consumo de tokens, os limites compartilhados de hospedagem e o volume de assentos contratados influenciam o custo real de cada protótipo entregue.
Os valores e restrições a seguir foram verificados na página oficial de preços do Bolt em August 27, 2026. A empresa sinaliza descontos de até 28% na cobrança anual. Como “até” não reflete uma taxa fixa para todos os casos, a tabela com valores mensais serve como a base mais precisa de comparação, devendo o checkout da plataforma ser consultado para propostas anuais consolidadas.
O plano Free serve para testes e oferece hospedagem limitada
O plano Free contempla projetos públicos e privados, criação livre de bancos de dados, deploy em subdomínio .bolt.host, 1 milhão de tokens mensais e uma limitação diária de 300,000 tokens. Essa franquia é suficiente para explorar a geração de código e as ferramentas de planejamento. Entretanto, não sustenta o desenvolvimento de aplicações complexas, visto que o limite diário pode paralisar as atividades antes do encerramento do saldo mensal.
As regras de tráfego também trazem impactos operacionais: o Free disponibiliza 10GB de largura de banda e 333,333 requisições por mês por conta. Caso esse teto seja atingido, as aplicações vinculadas saem do ar imediatamente até o ciclo seguinte. O modelo atende protótipos descartáveis, mas inviabiliza projetos comerciais que necessitam de estabilidade contínua.
O Pro é a porta de entrada recomendada para criadores individuais
O plano Pro sai por $25 mensais e entrega a partir de 10 milhões de tokens sem restrição diária. Elimina o selo do Bolt, eleva o limite de uploads para 100MB, libera compartilhamento privado, domínios próprios, SEO Boost, escolha do provedor de banco de dados e edição de imagens com IA. A hospedagem no Pro expande os limites para 30GB de transferência e 1 milhão de requisições por mês para a conta.
Tokens pagos que não foram utilizados acumulam para o mês seguinte (rollover) e podem continuar utilizáveis por até dois meses enquanto a assinatura estiver ativa. Essa regra atualizada substitui a restrição antiga que não permitia o acúmulo de tokens. Saldos do plano Free continuam sem direito a rollover.
Assinantes Pro podem manter suas páginas ativas mesmo ultrapassando o volume de acessos incluído ativando a cobrança sob demanda com limite máximo de gastos. Contudo, a página pública não divulga os custos unitários por giga ou requisição excedente, o que impede estimar com exatidão despesas de picos de acessos antes da contratação.
A compra de recargas adicionais também impõe condições: o Bolt libera a contratação de tokens extras apenas no plano Pro individual de valor mais elevado ou em qualquer modalidade anual do Pro. Como o valor das recargas muda conforme a assinatura e fica visível apenas no painel interno, a taxa de entrada de $25 não reflete o custo total para quem prevê uso intenso.
O Teams cobra individualmente por usuário, sem saldo unificado
O plano Teams adota a cobrança de $30 por pessoa ao mês. Cada membro contratado conta com uma cota própria de tokens, sem agrupamento compartilhado entre os integrantes. A centralização ocorre no faturamento e na administração, mas não na capacidade operacional de uso da IA.
Essa distribuição funciona quando todos os integrantes codificam com frequência. Por outro lado, gera ineficiência caso um profissional centralize a programação e os demais participem como avaliadores. Um grupo de quatro usuários gera um custo de $120 mensais ou $1,440 anuais, sem computar possíveis despesas de tráfego excedente, recargas de tokens ou integrações externas.
Em contrapartida, o Lovable Pro libera acessos ilimitados por $25 mensais ($300 anuais), frente aos $1,440 anuais da estrutura de quatro pessoas do Bolt. Isso representa uma diferença de $95 mensais e $1,140 ao ano. Os modelos de entrega são distintos: no Lovable a equipe divide 100 créditos, enquanto o Bolt disponibiliza cotas individuais por membro e um ferramental completo de infraestrutura. Ainda assim, a comparação evidencia a decisão de compra: só vale assumir a taxa por usuário se vários membros forem programar ativamente ou se os recursos de governança e design systems economizarem horas reais de desenvolvimento.
O Enterprise é onde os requisitos de conformidade são atendidos
O plano Enterprise trabalha sob proposta comercial customizada. Adiciona segurança avançada, autenticação via SSO, relatórios de auditoria, consultoria de conformidade, fluxos operacionais personalizados, SLAs rígidos, governança e retenção de dados, onboarding assistido e suporte dedicado 24/7.
Empresas que dependem desses recursos não devem balizar seu orçamento pelos $30 do plano Teams imaginando que a área de compras poderá solicitar esses adicionais mais tarde. Vale solicitar uma cotação formal do Enterprise logo no início caso seu projeto exija garantias corporativas que só esse plano entrega.
Como calcular o custo real por entrega
A avaliação do custo de assinatura por protótipo concluído é simples: divida o valor total pago pela quantidade de projetos que atingiram todos os critérios de aceitação previstos. O volume de prompts mede apenas esforço bruto, não entregas de valor.
Para um criador independente no Pro, o investimento base é de $300 anuais. Caso quatro protótipos atinjam os critérios de aceitação em um único mês, o custo de assinatura por entrega fica em $6.25. Se apenas um projeto for aprovado no período, o custo sobe para $25 por resultado. Essa conta desconsidera tráfego extra, serviços de terceiros e horas de trabalho, mas escancara o fator determinante da equação: a taxa de finalização de projetos.
Em um ambiente Teams com quatro assentos, a despesa mensal é de $120. A aprovação de oito protótipos representa um custo de software de $15 por entrega. Se apenas dois forem concluídos com sucesso, o custo unitário salta para $60. O preço da ferramenta não mudou; a eficiência da esteira de entregas é que caiu.
Os limites que definem a contratação
Os gargalos do Bolt.new não são detalhes visuais secundários. Eles costumam se manifestar todos juntos no mesmo instante: no momento em que o protótipo ganha tração, mais colaboradores começam a editar, o banco de dados assume dados sensíveis e os custos precisam ser previsíveis. É exatamente aí que comprar planos maiores de tokens pode mascarar problemas de arquitetura como se fossem apenas limitações de franquia.
1. O consumo de tokens aumenta junto com a base de código
O Bolt esclarece que boa parte do uso de tokens é gasta na leitura e sincronização dos arquivos do projeto. Como consequência, aplicações maiores gastam mais tokens a cada interação. O mesmo ajuste solicitado no início do projeto custará consideravelmente mais se for pedido em um estágio avançado de desenvolvimento.
Isso torna a previsão de gastos muito difícil usando apenas o volume de mensagens como métrica. Um pequeno detalhe de estilização pode exigir a releitura de múltiplos arquivos. Um comando pouco preciso pode forçar correções em cascata por toda a base de código. O acúmulo de tokens não utilizados ajuda a aliviar meses de menor atividade, mas não impede a escalada de consumo em projetos grandes.
Para contornar esse problema, envie prompts detalhados e curtos, preserve a modularidade da aplicação e transfira manutenções triviais de arquivos para um editor de código local assim que descrever o ajuste passar a consumir mais esforço do que aplicá-lo manualmente. Comprar pacotes maiores de tokens se justifica quando a demanda está bem planejada; vira desperdício caso o agente se perca com frequência na arquitetura e reescreva trechos de código funcionais sem necessidade.
2. O rollback do projeto não restaura o banco de dados
O Version History nativo do Bolt reverte unicamente os arquivos da aplicação, deixando o banco de dados exatamente onde está. Essa é uma das principais armadilhas para quem acredita que um “gerador de aplicações full-stack” ofereça recuperação total do ecossistema.
Código e tabelas evoluem juntos. Se uma alteração automática modificar o nome de uma coluna, reestruturar permissões de RLS ou alterar a modelagem de dados, reverter apenas o código criará uma quebra imediata de compatibilidade. Ambientes em produção demandam rotinas de backup dedicadas, controle de versões de migrações e baterias de testes de restauração que cubram banco e aplicação simultaneamente.
Há também uma particularidade no ambiente de testes. Bancos de dados não publicados e com baixa atividade podem entrar em suspensão preventiva a partir do sexto dia, demandando alguns minutos para restabelecer o serviço. Bancos com deploy publicado operam normalmente sem pausas. Embora seja uma gestão aceitável de recursos ociosos, isso pode pegar alguém de surpresa minutos antes de demonstrar um protótipo antigo para clientes.
3. A integração com o GitHub não cobre o ciclo completo do Git
O Bolt viabiliza a criação e troca entre branches pela interface, mas não conclui processos de merge. Toda unificação de ramificações deve acontecer diretamente na interface do GitHub. Essa separação é positiva para a governança de código, mas quebra a expectativa de quem buscava realizar todas as tarefas técnicas sem sair do Bolt.
O tratamento de conflitos simultâneos requer atenção redobrada. Embora a ferramenta cheque o GitHub a cada trinta segundos, caso alterações ocorram ao mesmo tempo no Bolt e no repositório remoto, o Bolt sobrescreve a versão do GitHub com a sua cópia local. Equipes não devem trabalhar na mesma branch de forma concomitante em locais diferentes. Adote branches isoladas, eleja o repositório como autoridade máxima e defina quem aprova os merges.
4. O desenvolvimento mobile começa fácil e termina em ferramentas locais
O Bolt se apoia no Expo para gerar aplicações móveis a partir do primeiro prompt, e o Expo Go permite testar o resultado rapidamente na tela do celular. Contudo, transformar uma aplicação web em um projeto mobile posteriormente não é um caminho suportado; essa escolha técnica precisa ser feita no momento zero da criação.
O processo de envio para as lojas de aplicativos também não acontece pelo navegador. O código-fonte precisa ser clonado localmente para ser processado com Node.js LTS, Git, CLI do Expo, credenciais de desenvolvimento, emissão de certificados e submissão aos comitês da Apple e do Google. O processo é muito mais acessível do que construir dois apps nativos do zero, mas está longe de ser um deploy em um clique.
5. A hospedagem pode ser interrompida ou ter custos imprevisíveis
Páginas no plano Free saem do ar assim que o consumo coletivo de banda ou requisições da conta atinge a cota mensal. O plano Pro até oferece tráfego adicional pago sob demanda com definição de teto financeiro, mas os preços unitários não são descritos abertamente no site. O usuário consegue se proteger contra sustos na fatura pelo painel, mas não consegue projetar cenários exatos de escala antes da compra.
Outro ponto crítico é o compartilhamento dos recursos por toda a conta. Publicar protótipos de vários clientes ou páginas de eventos na mesma assinatura faz com que um projeto de grande volume drene a capacidade dos outros. Agências devem alocar projetos em contas separadas dos próprios clientes ou monitorar o uso geral com rigor para evitar indisponibilidades cruzadas.
6. O suporte técnico é escalonado exatamente no momento em que problemas acontecem
Usuários do plano Free contam apenas com a comunidade no Discord para tirar dúvidas. Assinantes de planos pagos têm direito a suporte por e-mail em dias úteis e horário comercial. Já o atendimento ininterrupto 24/7 com suporte prioritário é reservado unicamente aos clientes do plano Enterprise.
Esse arranjo é padrão na indústria de SaaS, mas deve pesar na decisão de uso. Um aplicativo de missão crítica que necessita de garantias de resposta a incidentes nas madrugadas ou finais de semana não está protegido pelas condições do Pro de $25 ou do Teams de $30. Essa demanda exige a contratação do Enterprise ou a migração da aplicação para uma infraestrutura gerida por equipe própria.
7. Governança e viabilidade financeira nem sempre andam juntas
Embora o plano Teams agregue opções convenientes de gestão, design systems e centralização de faturas, os itens mais importantes de segurança e controle estão restritos ao plano Enterprise: SSO, auditoria avançada, conformidade legal, políticas de retenção de dados e SLAs contratuais. Dessa forma, uma organização pode necessitar de controles corporativos bem antes de atingir um volume de colaboradores que justifique o custo de licenças do Teams.
A regra de cobrança de tokens por usuário acentua esse descompasso. Membros que apenas revisam telas não conseguem ceder seus saldos de tokens excedentes para quem está programando intensamente. As lideranças devem avaliar quem realmente criará aplicações com frequência, verificar o papel dos revisores e comparar os custos com ferramentas de créditos agrupados antes de bater o martelo.
- O plano Pro a $25 reúne criação orientada por IA, banco de dados, opções de login, hospedagem e entrega de código no GitHub em um único painel.
- O código gerado é totalmente desvinculado da plataforma, facilitando o repasse para outros desenvolvedores ou migração de provedor.
- A união do Bolt Database com deploys sob o domínio .bolt.host viabiliza protótipos full-stack funcionais sem configurações manuais de serviços externos.
- A compatibilidade com Expo agiliza a validação de aplicações móveis, e a integração de design systems no Teams aceita componentes reais em código.
- Tokens pagos não consumidos acumulam para o mês seguinte, afastando a antiga limitação de perda imediata da franquia.
- O custo em tokens se eleva conforme a base de arquivos se expande, tornando o plano básico instável para prever orçamentos de projetos extensos.
- O Version History de projetos não realiza o rollback do banco de dados.
- O merge de branches do Git é obrigatoriamente manual no GitHub, e edições concorrentes podem fazer o Bolt sobrescrever o código do repositório.
- A publicação de aplicativos móveis em lojas requer ferramentas locais de desenvolvimento e contas de publicação ativas.
- As tarifas de tráfego adicional pay-as-you-go não são exibidas na tabela oficial de planos.
- Usuários Free dispõem apenas de auxílio comunitário, assinantes pagos têm atendimento limitado a dias úteis e o suporte 24/7 é exclusividade do Enterprise.
Veredito: o Bolt.new é excelente para prototipagem com prazo curto de entrega técnica
A assinatura do Bolt.new vale o investimento quando um criador individual precisa transformar uma especificação clara em um sistema funcional, hospedado e com código auditável, mantendo a disciplina de enviá-lo ao GitHub rapidamente. O plano Pro a $25 é o ponto de partida mais acertado nesse cenário, já que a trava diária de tokens e os bloqueios de tráfego do plano Free inviabilizam rotinas produtivas contínuas.
O panorama muda quando o sistema já conta com arquitetura pronta, uma equipe ativa de desenvolvedores, dados que exigem conformidade estrita ou demandas operacionais rígidas. O Cursor se posiciona como alternativa superior para trabalhar dentro de repositórios consolidados. O Replit se destaca quando o foco recai sobre um ambiente em nuvem mais completo, atuação de agentes simultâneos ou rollbacks seguros de banco de dados. O Lovable se mostra mais vantajoso quando a facilidade de colaboração visual e a presença de membros ilimitados superam o controle direto sobre arquivos e infraestrutura.
A regra de parada é fundamental: não responda a problemas repetidos de arquitetura, falhas de recuperação de dados ou conflitos de sincronização apenas adquirindo mais tokens. Se a aplicação começou a exigir code reviews frequentes, merges complexos, migrações supervisionadas e esteiras contínuas de entrega, transfira o núcleo da operação para um fluxo tradicional de desenvolvimento via repositório. O Bolt ainda poderá ser útil para criar protótipos pontuais ou sugerir novas branches, mas não deve mais ser a fonte primária da verdade da sua engenharia.
O plano prático de cinco dias
Reserve uma semana de trabalho para validar a ferramenta em um projeto experimental, sem expor sua base real de clientes.
Segunda-feira: estabeleça um critério claro de sucesso
Documente os papéis de acesso, estados do sistema, fluxos de telas, informações necessárias e regras de segurança. Foque em um escopo enxuto o bastante para ser modelado do início ao fim por uma única pessoa.
Terça-feira: construa a infraestrutura explicitamente
Peça na criação do projeto a modelagem exata do banco de dados, fluxo de login, perfis e telas de redefinição de senha. Mantenha os testes no plano Free enquanto lidar com dados descartáveis e registre comandos que gerem correções desnecessárias.
Quarta-feira: integre ao GitHub
Crie um repositório privado, suba uma nova branch para uma funcionalidade específica e aprove o merge na interface do GitHub. Confirme se as telas no Bolt continuam perfeitamente alinhadas com a versão principal do repositório.
Quinta-feira: teste cenários de falha
Force acessos indevidos com perfis errados, sessões expiradas, links quebrados de redirecionamento, ajustes manuais no banco e retorno de instâncias inativas. Mapeie quais ações exigem trabalho manual fora da aplicação gerada.
Sexta-feira: execute a regra de decisão
Assine o plano Pro apenas se o fluxo tiver sido concluído sem fricção, se o responsável técnico validar o código e se o consumo de tokens estiver compatível com os resultados entregues. Do contrário, adote a ferramenta alternativa mais preparada para mitigar o gargalo específico do seu projeto.
Caso queira comparar mais opções, explore nosso guia de ferramentas de vibe coding. Se a sua equipe tende a escolher o Replit, mas os planos pagos fogem do orçamento, nossa análise sobre alternativas gratuitas ao Replit para desenvolvimento com IA pode esclarecer a decisão correta.
Perguntas frequentes
Is Bolt New a legit website?
Sim, o Bolt.new é uma plataforma legítima mantida pela StackBlitz, contando com documentação pública, notas oficiais de versão, planos comerciais claros e suporte ativo. Esses pontos comprovam a solidez da empresa e do produto, mas não garantem por si sós que o código gerado esteja pronto para todo tipo de aplicação. Recomenda-se integrar a base ao GitHub, auditar permissões de acesso e estruturar rotinas próprias de backup antes de lidar com informações importantes.
Does Bolt New actually work?
O Bolt entrega funcionalidades reais para a montagem de aplicações web, bancos de dados, fluxos de login, deploys em nuvem, integração ao GitHub e estrutura móvel via Expo. Ele é capaz de ir além de protótipos estáticos. Como esta análise é uma verificação técnica e não um teste prático de bancada, não apontamos índices independentes de precisão nem asseguramos que sistemas complexos possam ir a produção sem validação de engenharia.
Is Bolt new better than Cursor?
O Bolt se destaca ao transformar um briefing conciso em uma aplicação completa no ar, reunindo interface e serviços de infraestrutura no navegador. O Cursor é superior para engenheiros de software que precisam atuar de forma cirúrgica diretamente no código de repositórios consolidados. O Bolt atende melhor a etapa em que o produto ainda não tem arquitetura fixa, enquanto o Cursor se sobressai quando a evolução precisa do código se torna a tarefa essencial.
Is Bolt New safe?
A ferramenta oferece proteções como validação de URIs, filtros de segurança contra vazamento de senhas, permissões granulares e governança no plano Enterprise. A segurança de fato, no entanto, depende da forma como a aplicação gerada trata regras de RLS, variáveis sensíveis, dependências externas, modelagem de dados e procedimentos de backup. Como o Version History do projeto não faz restauração de bancos de dados, é crucial ter uma estratégia de recuperação independente.
Is Bolt New completely free?
O Bolt disponibiliza um plano Free a $0 com suporte a projetos públicos e privados, 1 milhão de tokens por mês, teto diário de 300,000 tokens, além de hospedagem e banco de dados sem custos. Em contrapartida, aplica marca d'água nas aplicações, limita uploads a 10MB e paralisa as páginas públicas caso a conta esgote os 10GB de tráfego ou o limite de 333,333 requisições mensais.
Is Bolt.new free for 1 year?
A página de planos do Bolt oferece uma opção gratuita contínua a $0, sem qualquer indicação de que se trate de uma promoção temporária de um ano para planos pagos. O uso gratuito permanece limitado por cotas de tokens, uploads, marca visual e restrições de hospedagem. Planos profissionais pagos iniciam com o Pro a $25 mensais.
Bolt new pricing
Atualmente a plataforma disponibiliza o plano Free a $0, Pro a $25 por mês, Teams a $30 mensais por usuário e plano Enterprise com negociação sob medida. Há menção a economias de até 28% no ciclo anual. A assinatura Pro começa com 10 milhões de tokens mensais e permite transferir saldos não consumidos para o mês seguinte enquanto a assinatura se mantiver ativa.
Bolt new vs Lovable
Adote o Bolt se você precisa de um fluxo com foco em código, banco de dados integrado, hospedagem imediata e repasse rápido para o GitHub. Fique com o Lovable caso o projeto priorize refinamento visual de interface e trabalho conjunto com a equipe: o plano Lovable Pro de $25 suporta assentos ilimitados compartilhando os créditos da conta. Já o Bolt Teams impõe a cobrança de $30 para cada usuário, fazendo com que o número de assentos torne o custo total bem superior, ainda que as opções individuais tenham preços parecidos.
Baixe o Checklist de Auditoria de Fluxos com IA
Nosso Checklist de Auditoria de Fluxos com IA para Empresas ajuda você a isolar um processo, precificar os riscos de falha, indicar um responsável e estabelecer um critério claro de parada antes de contratar novos construtores. Assine para receber a próxima edição verificada.
3 de set. de 2026
Prefira este site no Google
Marque omidsaffari.com como fonte preferida e o Google destaca o site para você em Top Stories, AI Overviews e AI Mode.
