"\"Acabei de fazer sozinho em 8 horas por R$ 97; por que pagar mais?\" A objeção 1, respondida"

"Uma pessoa não técnica não pode simplesmente gastar mais tokens, corrigir os problemas e chegar em um produto bom o suficiente?"

Alguém que não programa escreveu isso num fórum brasileiro. É a mesma pergunta que eu espero ouvir de quem acabou de publicar o primeiro app num sábado, gastando R$ 97 e oito horas: se eu fiz isso sozinho, por que pagaria mais caro pra fazer o resto?

A primeira turma da mentoria ainda não aconteceu, então ninguém me disse isso ainda. Prefiro responder antes, sem preço no meio: o preço fica no fim da página.

A conta faz sentido. O erro é na régua.

A objeção não é burra. Você fez uma coisa real em oito horas, e o natural é medir o resto com a mesma régua.

Só que o que falta é outro tipo de trabalho, e ele não cresce na mesma proporção.

Pensa numa reforma de cozinha num sábado, com o cunhado que entende de obra. Dá pra tirar o armário velho, pôr o novo, passar a primeira demão. Fica lindo na foto. Na segunda-feira aparece o que o sábado não tocou: a fiação atrás do armário, o cano que vaza quando liga a máquina, o disjuntor que cai com o forno ligado. Ninguém acha que o sábado foi inútil. Só que o que vem depois pede outra ferramenta.

O protótipo é o armário novo. O dado do cliente guardado com segurança, o login que protege, a mudança que não quebra o que funcionava, o app que continua no ar enquanto você dorme: isso é a fiação. E fiação não aparece na foto.

O número que as oito horas deixam

Eu fiz o mesmo exercício num projeto de referência: do zero ao link, num dia. Tenho quinze anos de código. Respondendo com honestidade o checklist de dez perguntas que separa protótipo de produto, ele saiu com sete "não".

Não é nota do meu sábado. É o tamanho do que um sábado compra, pra qualquer pessoa. Pelo que eu vejo em protótipo de primeiro dia (é observação minha, não medição), o número fica entre seis e nove. As oito horas compraram um protótipo, e o seu número é a medida exata do que ficou de fora. Ele não diminui sozinho: cada pedido novo à IA, sem ponto de retorno e sem prova, tende a aumentar.

Três cenários, e só um deles é de graça

Olhando friamente, você tem três caminhos daqui a doze semanas:

1. Não entrar. O protótipo continua na plataforma, a mensalidade continua, cada mudança custa crédito e risco. Em doze semanas você tem o mesmo app, com o mesmo número, e três meses de aluguel pagos.
2. Entrar e não concluir. O pior cenário de quem age. Mesmo assim, você sai com o código num repositório seu (é o que acontece na primeira sessão) e o banco no seu nome. Dois "não" viram "sim" antes do primeiro portão.
3. Entrar e concluir. Checklist zerado, app seu, no ar, com gente de fora usando.

A pergunta honesta não é "é caro?". É se o cenário 2, o pior de quem decide, é pior que o cenário 1. Pra mim, não é. Mas quem decide é você, e dá pra decidir melhor com um dos "não" já resolvido. Então vamos resolver um agora.

O que fazer hoje, sem pagar nada: tire o código de lá

O primeiro "não" do checklist é "o código é seu?". Se o seu app está no Lovable, dá pra virar esse "não" em dez minutos, em qualquer plano, inclusive no gratuito. A documentação deles diz que a integração com o GitHub está disponível em todos os planos.

GitHub é um site onde se guarda a cópia do código de um projeto, com o histórico de cada mudança. É de graça pra esse uso.

1. Crie uma conta no GitHub em github.com, com o seu e-mail. O seu, não o do sócio nem o do freelancer.
2. No Lovable, abra o projeto e vá em Project settings → Git → GitHub.
3. Clique em Connect, autorize o acesso e escolha a sua conta. O Lovable cria o repositório (a pasta do projeto dentro do GitHub) sozinho. Pela documentação, ele nasce privado: ninguém vê além de você.
4. Confira. Abra github.com, entre no repositório novo e veja se os arquivos estão lá. A lista de mudanças (em Commits) já começa a contar a história do app.
5. Anote duas coisas que a própria documentação avisa: o Lovable sincroniza um ramo só (a linha principal do projeto), e se você desconectar e conectar de novo, ele cria outro repositório em vez de religar o antigo. Então conecte uma vez e deixe.

Pronto. Cada mudança que a IA fizer vai parar numa conta sua. Se a plataforma sumir amanhã, o código fica.

O que esse passo não resolveu

A mesma página do Lovable é clara: sincroniza só o código. O banco de dados, as contas dos usuários, as chaves, o domínio, nada disso foi pro GitHub. Ter o código não é ser dono, e você acabou de fechar uma das cinco coisas.

As outras têm ordem. O banco vai pro seu nome antes de você mexer em regra de acesso. Teste e produção se separam antes de você testar segurança. Ponto de retorno vem antes de qualquer migração. Feito fora de ordem, cada passo certo vira um problema novo, e é aí que gente muito capaz passa dois fins de semana num erro e conclui que "código de verdade não é pra mim".

Essa sequência tem nome, Construa, Estruture, Opere, e um portão entre cada fase. O que a mentoria vende não é conteúdo que você não acharia: é essa ordem, aplicada no seu app, com alguém do outro lado conferindo cada portão. Se depois do passo de hoje você achar que faz o resto sozinho, ótimo. O blog continua aqui, de graça, e o seu número vai dizer se deu certo.

Fontes

• Lovable — GitHub integration (disponível em todos os planos; caminho Project settings → Git → GitHub; repositório privado por padrão; sincroniza só código, um ramo por vez; reconectar cria repositório novo): https://docs.lovable.dev/integrations/git-integration
• A fala do início está no swipe file da pesquisa deste blog, coletado em fóruns brasileiros de 2025 e 2026 (é a pergunta de uma pessoa, não estatística).