Seu app feito no Lovable parou em 80%? O problema não é falta de função, é o que ninguém verificou

Quase todo app que trava não está incompleto. Está sem verificação.

Com Cursor, Lovable, Bolt, v0 ou Replit dá para chegar rápido a uma demo convincente: telas, fluxos, uma chamada ao banco. Depois o app fica semanas em "quase pronto", porque essa demo rodou no notebook de quem construiu, contra um ambiente de preview, e nenhuma das emendas que atravessam um arquivo, um ambiente ou um instante no tempo foi testada.

Eu termino esses apps para viver. Não reescrevendo: pego o código como está, verifico as emendas no ambiente em que ele vai rodar de verdade e coloco no ar. O que costumo encontrar é sempre parecido.

1. Sessão que funciona até o primeiro cold start

Token guardado em variável de módulo, segredo regenerado quando o servidor sobe, cookie sem SameSite direito: tudo isso parece autenticação funcionando. Até a função serverless esfriar, o usuário recarregar em outra aba ou o navegador restaurar a sessão — e aparecer o "me deslogou do nada".

O teste é recarregar, restaurar aba, forçar cold start e encerrar sessão em dois aparelhos diferentes. Se cair, arruma antes de escrever uma linha de funcionalidade nova.

2. Permissão que só confere se existe usuário, não se ele é o dono

O erro mais caro e mais comum: a API checa se há sessão, mas não se aquela linha pertence àquela pessoa. No Supabase ou no Firebase, uma política de Row Level Security mal escrita deixa qualquer um ler pedidos dos outros só trocando o id na URL. Testa-se com duas contas, nunca com uma: a conta A tenta ler, editar e apagar o que é da conta B.

3. Pagamento confirmado por uma tela que o usuário alcança apertando "Voltar"

Pagamento confirmado pela página de retorno, sem webhook com assinatura verificada e sem chave de idempotência, cobra duas vezes ou entrega de graça. No Brasil isso aparece rápido: Pix com webhook que chega repetido, cartão com 3DS que redireciona e perde o estado, boleto compensando dois dias depois enquanto o pedido já foi cancelado. A prova é uma compra real e um estorno real em produção, não o modo de teste.

Conciliação também é código: se o valor do pedido existe em três lugares diferentes (tela, banco, gateway), um deles vai divergir no primeiro cupom ou na primeira taxa.

4. O banco que ninguém sabe como chegou em produção

O banco de produção é resultado de migrations versionadas ou de alguém clicando no painel três semanas atrás? Se for a segunda opção, o próximo deploy quebra alguma coisa e não haverá como reproduzir. Gero a migration inicial a partir do schema real antes de continuar.

5. Variáveis que faltam e só aparecem na chamada errada

Se o app não quebra ao subir quando falta uma variável de ambiente, ele quebra na primeira chamada à API de pagamento, em produção, com cliente na frente. Também confiro o que está exposto ao cliente (NEXT_PUBLIC_, VITE_): chave privada no front é vazamento, não configuração.

6. Ninguém soube que quebrou

Quando o usuário escreve "não está funcionando", existe error boundary, um id de requisição e um canal de alerta que uma pessoa realmente lê? Se a resposta é um e-mail que ninguém abre, o app está operando no escuro.

Como isso vira 3 a 5 dias

A primeira conversa não é comercial, é uma subtração. Escolhemos o único trabalho que o app precisa fazer para o primeiro cliente pagante e escrevemos o que não vai ser construído nesta semana. O que depende de contrato bancário, integração com operadora ou driver de hardware é dito ali, porque isso é semana, não dia.

• Dia 0: escopo fechado, preço fixo, sem entrada.
• Dia 1: as emendas verificadas em condição de produção. É esse dia que decide o prazo.
• Dias 2 e 3: correção, não funcionalidade. Todo dia sobe uma versão funcionando no domínio real do cliente.
• Dias 4 e 5: deploy (domínio canônico, HTTPS, teste com dados móveis e conexão lenta) e entrega: onde está o código, quais variáveis existem, como publicar, como ler os logs e o que vai quebrar primeiro.

Quem faz

Sou o CEO da CPC AI Inc., estúdio de uma pessoa só em Seul. Sem agência, sem gerente de projeto, sem camada de vendas: eu construo e assino o contrato com você. Empresa registrada na Coreia do Sul (registro comercial 771-88-03539), com nota fiscal oficial.

Não é discurso: a mesma equipe publica produtos próprios. O CPC AI é um app de leitura de mercado de cripto com dados em tempo real e chat com IA. Cannon King é um jogo de artilharia por turnos com 48 tanques, mais de 20 mapas destrutíveis e 53 níveis, publicado no Google Play, na App Store e como mini app no Toss. Também produzimos vídeo com IA e publicamos automaticamente em várias contas.

O site que você está lendo foi feito em um dia, do planejamento ao deploy — e o processo com cliente é o mesmo.

O que eu não prometo

Três a cinco dias bastam para um MVP web ou mobile focado, cujas integrações já existem, porque o trabalho é verificação e acabamento, não arquitetura. Não bastam para integração bancária, marketplace com compliance dos dois lados ou jogo cujo conteúdo ainda precisa ser desenhado. Se o seu escopo for o segundo tipo, a primeira conversa tem que dizer isso — e a resposta certa é um plano mais longo, não uma promessa mais rápida.

Nada é pago antes de contratar: orçamento e revisão de código são gratuitos, a entrada é paga quando começamos e o restante só depois que você vê o resultado funcionando. Se não gostar, reviso sem custo até ficar bom.

• Site em inglês (com formulário de orçamento): https://cpcai-studio.netlify.app/en/
• Formulário direto: https://cpcai-studio.netlify.app/en/#inquiry
• E-mail: [email protected]

Se você construiu algo com ferramenta de IA e faz tempo que está "quase pronto", a pergunta útil não é qual funcionalidade falta. É qual emenda nunca foi verificada fora do seu notebook.