Preços de AI App Builders explicados: créditos, mensagens e o que você realmente paga

Todo AI app builder cobra por alguma abstração — créditos, mensagens, tokens — e quase ninguém explica o que essa abstração significa. O resultado é previsível: o usuário queima metade da cota aprendendo a usar a ferramenta e depois conclui que o modelo de preços é uma armadilha. Geralmente não é. É só mal explicado.

Este post explica pelo que você está pagando de verdade, por que o mercado convergiu para créditos e — o mais útil — como builders experientes tiram três vezes mais app do mesmo orçamento.

O que um crédito realmente compra

Quando você envia um prompt para um AI app builder, você não está pagando pela mensagem. Está pagando por tudo o que o agente faz por causa dela:

• O modelo lê o contexto do seu projeto — arquivos relevantes, o modelo de dados, alterações recentes — para que as edições se encaixem no código existente.
• Ele planeja e escreve código em quantos arquivos a mudança exigir.
• Ele roda o build, lê os erros que aparecem e os corrige, possivelmente várias vezes.
• A plataforma banca a computação por trás disso: as chamadas ao modelo (o custo dominante — modelos de código de fronteira são genuinamente caros), mais o container de preview rodando o seu app.

Ou seja, uma única "mensagem" pode disparar trinta chamadas ao modelo e dois ciclos de build. É por isso que uma funcionalidade grande custa mais do que corrigir um erro de digitação, e por isso que existe o preço por geração: os custos da plataforma escalam com a quantidade de trabalho que o agente faz, e os créditos repassam esse formato para você.

Os modelos de preço alternativos são piores de formas mais sorrateiras. Planos ilimitados de preço fixo limitam você de forma invisível — rate limits, filas mais lentas, modelos mais fracos na margem — porque ninguém consegue vender computação ilimitada de modelos de fronteira por US$ 25/mês e sobreviver. Cobrança por token bruto é honesta, mas imprevisível: ninguém consegue orçar "tokens" para uma funcionalidade. Créditos são o meio-termo do mercado: os custos acompanham aproximadamente o trabalho feito, em unidades que um ser humano consegue contar.

Para onde os créditos realmente vão

Depois de observar muitos projetos sendo construídos, o padrão de gasto é consistente:

A primeira geração é barata em relação ao que você recebe. Estruturar um app inteiro é uma rajada de trabalho grande e eficiente — a fundação costuma custar uma fração pequena do total do projeto.

É na iteração que o orçamento vive ou morre. A diferença entre um builder eficiente e um que desperdiça está quase toda no meio do jogo — e é principalmente uma questão de hábitos de prompt, não da ferramenta:

• Prompts vagos são o maior vazamento. "Deixe melhor" força o agente a adivinhar, produz uma mudança que você meio que gosta e dispara duas rodadas de correção. São três gerações para uma melhoria. "Aumente o espaçamento dos cards e deixe os títulos em negrito" é uma só.
• Prompts empacotados são o segundo vazamento. Cinco mudanças em uma mensagem significam que, quando uma sai errada, você fica re-prompteando em volta das outras quatro. Mensagens pequenas e de propósito único são individualmente baratas e raramente precisam de correção.
• Brigar com uma direção ruim é o terceiro. Se a iteração 12 piorou as coisas, não gaste as iterações 13–16 discutindo com ela. Restaure o checkpoint da iteração 11 e ataque por outro ângulo. Plataformas como a Massvai criam um checkpoint a cada geração justamente para que voltar atrás saia quase de graça.

Espirais de debugging são o risco de cauda. De vez em quando o agente entra num loop de conserta-quebra-conserta. A jogada eficiente em créditos nunca é "tentar de novo" pela quinta vez — é reverter e descrever o objetivo de outra forma.

Como avaliar o preço de um builder antes de pagar

Planos gratuitos existem para que você possa medir, então meça:

1. Construa um projeto de teste de verdade — um modelo de dados e três telas, não uma landing page — e conte os créditos do projeto vazio até "eu apresentaria isso numa demo".
2. Verifique quanto custa iterar. Dez mudanças pequenas no plano gratuito dizem mais sobre o seu custo mensal real do que a página de preços, porque a iteração domina o gasto ao longo da vida do projeto.
3. Leia as condições de estouro. O que acontece quando os créditos acabam no meio do mês — bloqueio total, pacotes avulsos ou upgrade forçado? É aqui que as páginas de preços ficam quietas.
4. Fique de olho na expiração. Créditos não usados acumulam para o mês seguinte? Expiração mensal pune o padrão "um projeto por trimestre" que a maioria dos builders independentes realmente tem.

Sobre a Massvai especificamente: contas novas ganham 100 créditos de boas-vindas sem precisar de cartão, planos pagos adicionam cotas mensais ou anuais de créditos, e a página de preços mostra os números atuais antes de você se comprometer. O teste acima leva uma tarde e responde à única pergunta que importa — quanto custa o seu estilo de construir nesta plataforma?

A comparação que todo mundo esquece

É fácil se ancorar em "este mês gastei US$ 40 em créditos" e esquecer o contrafactual. O custo padrão de um pequeno app web sob medida é um freelancer por US$ 3.000–10.000 e algumas semanas, ou uma ferramenta no-code por US$ 30–100/mês para sempre — com o app trancado dentro dela.

Contra essa referência, o preço por créditos não é a opção cara. A opção cara é o app que você nunca construiu porque o jeito antigo custava demais. Gaste seus créditos como se fossem dinheiro de verdade — eles são — mas gaste.