Transferência de app criado por IA: passos claros para assumir com segurança

O que pode dar errado quando você assume o app

A maioria das tomadas dá errado por motivos chatos: você na verdade não tem controle. Um freelancer pode ter configurado tudo usando o e-mail pessoal, conta na nuvem ou um workspace temporário. Quando ele some (ou fica ocupado), você perde acesso, e até pequenas mudanças ficam impossíveis.

O código é outro problema comum. Você pode receber um arquivo zip, mas não o histórico completo do repositório, não as configurações de ambiente e não os passos exatos para build e deploy. É assim que você acaba com um app que “funciona no laptop deles” mas não pode ser reproduzido quando você precisa corrigir um bug.

Surpresas na fatura doem porque aparecem silenciosamente. Protótipos gerados por IA frequentemente dependem de vários serviços de terceiros: hospedagem, bancos de dados, e-mail, armazenamento de arquivos, analytics e uma ou mais APIs de IA. Se essas contas permanecerem no nome do freelancer, você pode ser bloqueado enquanto continua sendo cobrado. Ou o app cai porque um trial acabou ou o cartão falhou e ninguém viu o alerta.

Problemas de segurança também são comuns, e código gerado por IA pode ser especialmente frágil aqui. Frequentemente você encontra chaves de API hardcoded, autenticação fraca, acesso de admin amplo demais ou atalhos “temporários” que nunca foram limpos. Quando a propriedade muda, esses atalhos viram riscos reais.

Uma transferência limpa de um app criado por IA é simples de descrever: você consegue fazer login em todos os lugares, consegue reconstruir o app do zero em uma máquina nova e consegue provar que o que está rodando em produção bate com o código que você tem.

Ao final de uma boa transferência, você deve conseguir mostrar:

• Acesso de proprietário a todas as contas das quais o app depende (não senhas compartilhadas)
• Um inventário escrito de serviços, custos e quem os controla
• A codebase completa em um repositório que você possui, além do método de deploy
• Prova de que o app pode ser implantado de novo (build limpo e deploy bem‑sucedido)
• Uma lista curta de problemas conhecidos e riscos a serem corrigidos a seguir

Antes de começar: concorde sobre escopo e cronograma

Uma entrega limpa começa com um acordo: exatamente o que você vai receber. Muitos “apps” são na verdade protótipos que funcionam bem em demos, mas não estão prontos para usuários reais. Se você tratá‑lo como produção no primeiro dia, corre risco de quedas, perda de dados e correções de emergência.

Escreva o objetivo em palavras simples. Você quer manter o app atual funcionando como está por um mês, lançá‑lo para usuários pagantes ou usá‑lo como ponto de partida para reconstruir? Cada objetivo muda o que você precisa do freelancer e quanto tempo reservar.

Defina uma data clara de entrega, além de uma janela curta de suporte após a entrega. Essa janela serve para tirar dúvidas, transferir contas e resolver qualquer problema do tipo “só funciona na máquina dele”. Limite o tempo para que isso não vire uma dependência aberta.

Mesmo que o app esteja bagunçado, peça uma lista escrita dos sistemas. Você não está julgando. Está evitando surpresas. Um documento simples ou uma mensagem já basta, desde que nomeie cada serviço que pode te travar depois.

O acordo deve cobrir:

• Em que estágio está: protótipo, beta ou pronto para produção
• O que significa “concluído”: login funcionando, pagamentos, painel admin, passos de deploy, etc.
• Data de entrega e janela de suporte (por exemplo, 7–14 dias)
• Lista de sistemas usados: repositório de código, hospedagem, banco de dados, auth, e-mail, analytics, APIs de IA
• Quem paga o quê até a transferência ser concluída

Exemplo: você planeja “lançar semana que vem”, mas o freelancer diz que é um protótipo e usa a própria conta na nuvem e chaves de API pessoais. Isso ainda não é um plano de lançamento. É primeiro um plano de transferência.

Faça um inventário de todas as contas ligadas ao app

Uma entrega limpa começa com um único deliverable simples: uma lista completa de todas as contas das quais seu app depende. Em uma transferência de app construído por IA, o código é só metade da história. A outra metade é o acesso.

Coloque tudo em uma planilha ou documento com quatro colunas: nome do serviço, para que serve, quem é o dono (e‑mail e empresa) e como você faz login (SSO, senha, 2FA, chave de API). Se você não consegue responder às quatro, trate como risco.

A maioria das equipes perde pelo menos um desses grupos:

• Código e colaboração: dono do repo, direitos de admin, contas de CI/CD, onde estão docs/issues
• Hospedagem e tráfego: login do cloud/PaaS, registrador de DNS, e‑mail do domínio, acesso ao pipeline de deploy
• Camada de dados: usuários do banco, buckets de armazenamento, connection strings, backups e permissões de restore
• Infra do produto: provedor de e‑mail/SMS, pagamentos, analytics, logging de erros, APIs de terceiros
• Armazenamento de segredos: onde senhas e chaves vivem (vault, gerenciador de senhas ou um arquivo .env)

Um exemplo realista: um freelancer construiu seu protótipo no GitHub dele, fez deploy pelo Vercel pessoal e conectou o Stripe com o e‑mail dele. Tudo funciona até ele ficar offline e você não conseguir rotacionar chaves ou trocar faturamento. Seu inventário deve tornar isso impossível.

Peça provas, não promessas. Para cada serviço, faça o freelancer abrir a página de admin e confirmar propriedade, papel e contato de faturamento.

Retome o controle dos logins sem quebrar o app

A maioria das falhas na entrega não é sobre código. É sobre identidade: quem tem a caixa de entrada, quem pode resetar senhas e quais credenciais “temporárias” realmente mantêm a produção viva.

Comece movendo todas as contas críticas para e‑mails que você controla (idealmente do seu domínio). Se o app está amarrado ao Gmail do freelancer ou ao gerenciador de senhas dele, você ainda não é o dono. Trate a propriedade do e‑mail como a chave raiz.

Faça a transferência numa ordem segura

Mude o mínimo possível até provar que você ainda tem acesso. Uma sequência confiável é esta:

• Adicione seu e‑mail como admin ou owner primeiro, confirme que consegue fazer login e resetar senhas.
• Ative MFA para contas administrativas e defina opções de recuperação para telefones e e‑mails de backup que você controla.
• Exporte e armazene credenciais em um gerenciador de senhas, não em chat ou docs compartilhados.
• Rotacione senhas, chaves de API e segredos de webhooks só depois de verificar que o app continua rodando.
• Remova o acesso do freelancer apenas depois de testar login, faturamento e um deploy.

Um exemplo simples: seu app usa Google OAuth e um banco gerenciado. Se você rotacionar o client secret do OAuth antes de atualizar as variáveis de ambiente no hosting, os usuários ficarão bloqueados. Se você remover o freelancer da conta na nuvem antes de adicionar seu próprio admin, pode perder a capacidade de reiniciar serviços ou ver logs.

Após a transferência, rotacione segredos de forma controlada. Mude uma coisa, faça deploy e teste o fluxo principal (cadastro, login, pagamento, se houver).

Garanta a codebase completa e um build reproduzível

Uma entrega de app criado por IA não é real até você conseguir buildar e rodar o app do zero usando contas que você controla. Um arquivo zip raramente basta. Você quer um repositório completo, os passos exatos de setup e prova de que o código que recebeu bate com o que está em produção.

Primeiro, coloque o código-fonte em um repositório versionado e garanta que você é o dono. Peça instruções de build que funcionem em uma máquina limpa, não só “rode npm install”. Boas entregas incluem versões fixas (Node/Python), lockfiles e scripts necessários para migrações de banco e seeding.

Colete configurações com segurança. Variáveis de ambiente e chaves de serviço devem ser transferidas por um canal seguro e rotacionadas depois que você confirmar a transferência. Se segredos estiverem hardcoded no código ou compartilhados em um documento, trate‑os como comprometidos.

Peça isso como um pacote:

• O repositório completo com histórico de commits (ou histórico exportado, se preciso)
• Passos exatos para build e execução em local e staging
• Lista completa de env vars necessárias (com descrições, não apenas nomes)
• Lista de ferramentas de IA usadas (Lovable, Bolt, v0, Cursor, Replit) e quaisquer prompts salvos
• O identificador da versão implantada (commit hash/tag) para que você possa comparar

Depois verifique. Suba uma cópia em staging e confirme que o código mais recente bate com o que está em produção (mesmo commit, mesma forma de configuração, mesmas migrações aplicadas). Se você não consegue reproduzir o build, você não tem o app de verdade.

Pare cobranças surpresa: faturamento, limites de uso e cancelamentos

Um freelancer pode entregar “o app” e ainda assim deixar você exposto a cobranças que você não vê. Antes de convidar mais usuários, mapeie cada serviço pago para uma funcionalidade real do produto. Essa é a forma mais rápida de evitar acordar com uma fatura inesperada.

Comece encontrando onde o dinheiro pode vazar. Os culpados usuais são ferramentas cobradas por uso que continuam rodando mesmo com pouco tráfego: chamadas à API de IA, envios de e‑mail/SMS, logging em alta, crescimento de banco/armazenamento e add‑ons de hospedagem.

Em seguida, confirme quem é o dono das contas de faturamento e do método de pagamento. Se o freelancer é o dono da conta, você pode perder acesso durante uma disputa, ou ele pode esquecer de renovar um cartão e derrubar seu app. Transfira o faturamento para uma conta controlada pela empresa e mantenha pelo menos dois admins.

Estabeleça limites para que erros não virem caros. Use budgets e alertas quando possível. Se limites rígidos não estiverem disponíveis, configure múltiplos alertas (por exemplo em 50%, 80% e 100% do alvo mensal) e garanta que eles vão para sua equipe.

Cancele com cuidado. Não delete coisas “porque parecem não usadas” até confirmar que nada depende delas. Um padrão mais seguro é pausar ou fazer downgrade primeiro, observar o app por um dia e então remover.

Ações rápidas que você pode fazer hoje:

• Exportar assinaturas e faturas de cada provedor
• Relacionar cada cobrança a uma funcionalidade que usuários podem nomear
• Ativar alertas de orçamento e e‑mails diários de uso
• Adicionar um segundo admin e transferir propriedade para sua empresa
• Pausar ou fazer downgrade de um serviço “não usado” e monitorar antes de deletar

Verificação rápida de segurança antes de liberar a mais usuários

Antes de abrir o app para mais usuários, faça uma passagem rápida de segurança. O objetivo não é perfeição. É pegar problemas que podem causar dano em um dia: chaves vazadas, login falso e portas admin abertas.

Comece caçando segredos expostos. Verifique o código, arquivos de configuração, settings de deploy e quaisquer logs de build ou servidor que você consiga acessar. Se você vir chaves de API, senhas de banco, client secrets de OAuth ou tokens “temporários”, assuma que estão comprometidos e rotacione‑os.

Depois verifique se a autenticação é real. Muitos protótipos usam auth placeholder (ou uma flag de “admin” hardcoded) que funciona na demo. Confirme que:

• Usuários precisam fazer login para acessar páginas privadas e APIs
• Acesso admin é limitado a contas específicas, não a um toggle no front‑end
• Reset de senha e verificação por e‑mail (se usados) não podem ser abusados
• Sessões expiram e logouts realmente revogam acesso
• Não existe um /admin público ou painel de debug exposto

Em seguida, identifique riscos comuns de correção rápida. Procure por queries SQL cruas montadas com concatenação de strings (SQL injection), uploads de arquivo sem restrição e endpoints que aceitam input do usuário sem validação.

Finalmente, reveja quem pode acessar dados de usuários. Quem pode ler dados de produção (contas do freelancer, logins compartilhados, dashboards de terceiros)? Backups estão habilitados e você sabe onde eles ficam?

Uma forma prática de manter isso gerenciável é ordenar os achados em três grupos:

• Corrigir agora: rotacionar segredos vazados, restringir admin, fechar endpoints de debug públicos
• Corrigir em breve: adicionar rate limits, apertar validação, melhorar logging e alertas
• Corrigir depois: refinar regras de retenção, fluxos de exportação/exclusão de dados, revisão de segurança completa

Processo passo a passo para uma entrega limpa (simples e repetível)

Uma entrega limpa de app criado por IA é basicamente sobre controle. Você precisa possuir as contas, o código e as chaves, e precisa provar que consegue fazer deploy sem o freelancer.

Comece com uma chamada rápida de screenshare (30–45 minutos). Peça ao freelancer que faça login ao vivo para que você veja onde tudo está hospedado, quais serviços são usados e qual conta é a proprietária de fato.

1. Freeze nas mudanças por um dia. Concordem em uma janela curta sem novas features. Isso evita confusão do tipo “ontem funcionou”.
2. Transfira propriedade, não só acesso. Mova o repositório, o projeto na nuvem, o registrador de domínio, o DNS e o remetente de e‑mail para contas que você controla.
3. Capture segredos, depois rotacione. Copie variáveis de ambiente, chaves de API, client secrets OAuth, senhas de banco e chaves de assinatura de webhooks para seu gerenciador de senhas. Depois de confirmar que o app roda, regenere e atualize-as.

Uma vez que propriedade e segredos estejam sob seu controle, faça um deploy você mesmo. Esse deploy é o momento em que você para de depender de outra pessoa para manter o app vivo.

4. Crie uma cópia de staging primeiro. Clone a configuração de produção em um ambiente de staging e faça deploy lá sob sua conta. Corrija passos de build ou config faltantes antes de tocar a produção.
5. Teste apenas os fluxos que importam. Confira cadastro, login/reset de senha, pagamentos (se houver) e a funcionalidade principal de ponta a ponta com um usuário de teste novo.

Finalize removendo acessos e registrando o estado final. Desabilite contas do freelancer, revogue tokens pessoais, remova chaves SSH e salve uma nota curta: onde fica o repo, como fazer deploy, onde os segredos são guardados e quem é o dono do faturamento.

Armadilhas comuns que causam perda de acesso e quedas

O app pode parecer “pronto” e ainda assim ser frágil. A maioria das quedas durante uma transferência acontece porque a propriedade é confusa, o acesso está espalhado ou o app depende do laptop e das senhas de uma pessoa.

Uma armadilha comum é o app rodar, mas ninguém na sua equipe ter acesso admin verdadeiro à conta na nuvem. Você pode fazer login no app, mas não consegue mudar variáveis de ambiente, escalar, ver logs ou renovar certificados. Na primeira falha, você fica preso esperando o freelancer.

Outra armadilha é código faltando. Projetos gerados por IA muitas vezes ficam espalhados por múltiplos repositórios, copiados entre ferramentas ou só armazenados localmente. Se você não consegue puxar a codebase completa de um repo compartilhado e reconstruí‑la do zero em uma nova máquina, você não é o dono do app.

Esses problemas reaparecem sempre:

• DNS registrado na conta do freelancer, então uma “pequena” mudança vira downtime quando registros não podem ser atualizados rápido.
• Segredos compartilhados em chat e reaproveitados entre serviços, de modo que um valor vazado expõe toda a stack.
• Backups existem só no nome: estão antigos, incompletos ou ninguém testou um restore.
• Arquitetura é spaghetti, então pequenos consertos quebram partes não relacionadas.
• Contas são pessoais (e‑mail do freelancer, cartão pessoal), tornando renovações e mudanças de faturamento arriscadas.

Um exemplo simples: você tenta apontar o domínio para um novo host, mas o login do DNS está na caixa de entrada do freelancer. Enquanto espera, o servidor antigo atinge um limite e sai do ar.

Cenário exemplo: assumir um protótipo de IA feito por freelancer

Maya é uma fundadora solo. Ela pagou um freelancer para construir um protótipo rápido no Replit (história similar com Lovable). A demo ficou ótima, mas quando ela tenta mostrar para usuários reais, as coisas começam a tremer.

A primeira surpresa: não há uma entrega limpa. O freelancer envia um zip e algumas screenshots, mas o app só roda no workspace dele. Quando Maya tenta fazer deploy, o build falha porque variáveis de ambiente chave estão faltando. A connection string do banco, a URL de callback do auth e a chave do provedor de IA nunca foram documentadas.

Em seguida vem o faturamento. Maya checa seus cartões e encontra duas cobranças para a mesma coisa: uma instância de banco não usada e um segundo projeto de hospedagem criado durante testes. A fatura da API de IA também dispara porque o app fica reintentando requisições e entra em loop.

Uma auditoria rápida mostra por que o protótipo servia para demo mas era arriscado para produção:

• Autenticação está parcialmente ligada, mas reset de senha e checagens de sessão estão quebradas.
• Segredos foram expostos em um arquivo de configuração commitado.
• O código tem lógica duplicada em vários arquivos, tornando pequenas mudanças arriscadas.
• Não existe um processo de deploy repetível, então cada release vira um palpite.

Nesse ponto, Maya tem dois caminhos sensatos. Se a ideia central está validada e o código está perto do aceitável, ela estabiliza primeiro (tranca segredos, conserta auth, adiciona build reproduzível) e depois refatora em pequenos passos. Se a base está muito bagunçada, ela reconstrói o núcleo limpo e importa só o que vale a pena manter.

Checklist rápido que você pode usar em 15 minutos

Use isso como um check rápido antes de chamar a entrega de “concluída”. Uma transferência limpa de app criado por IA se resume a propriedade, repetibilidade e saber o que pode te custar dinheiro amanhã.

Propriedade e acesso

• Você consegue fazer login como owner/admin no repositório de código e adicionar/remover usuários.
• Você controla a hospedagem e o dashboard de runtime com sua própria conta admin.
• Você controla o DNS e pode alterar registros sem pedir ao freelancer.
• Você consegue acessar o banco de dados com papel de admin e sabe onde ele está hospedado.
• O faturamento da nuvem e dos serviços do app está em seu nome, com método de pagamento que você controla.

Se qualquer um desses for “não”, pause trabalho em features. Conserte acesso primeiro ou você corre risco de bloqueios e downtime.

Build, segurança e custo

• Você consegue fazer deploy a partir do repositório usando passos escritos, sem o freelancer na chamada.
• Segredos do app (chaves de API, tokens) estão em um gerenciador de segredos apropriado ou variáveis de ambiente, não no código ou em logs de chat.
• Após a transferência, você rotaciona as chaves mais sensíveis (banco, auth, pagamento, envio de e‑mail).
• Backups existem e você já testou um restore ao menos uma vez (mesmo que em ambiente temporário).
• Você tem uma lista simples de todos os serviços pagos e o que gera a fatura (usuários, requests, armazenamento, assentos).

Anote os cinco principais problemas para corrigir a seguir (por exemplo: login quebrado, chaves expostas, erros no checkout). Essa lista curta evita que você fique mudando de lado.

Próximos passos: estabilize agora, depois decida reparar ou reconstruir

Depois da transferência, o objetivo é simples: garantir que você consegue rodar o app com segurança hoje e então decidir se vale a pena melhorar o código atual ou começar do zero onde dói mais.

Estabilizar funciona quando o app basicamente funciona, mudanças são pequenas e você consegue enviar correções sem quebrar fluxos principais. Reconstruir faz mais sentido quando qualquer mudança gera novos bugs, a estrutura está emaranhada ou problemas de segurança continuam aparecendo.

Sinais de que reconstruir (ou reconstruir parcialmente) é a opção mais segura:

• Você não consegue explicar como auth, pagamentos ou armazenamento de dados funcionam ao ler o código
• Deploys são manuais e frágeis, e ninguém consegue reproduzir o build de forma confiável
• Segredos estão espalhados por arquivos, chats ou dashboards
• Correções simples levam horas porque uma mudança quebra três áreas diferentes
• Custos são imprevisíveis porque limites de uso e faturamento são obscuros

Para evitar deriva, defina um plano de 7 dias com resultados concretos:

• Dia 1–2: trancar propriedade (acesso admin, MFA, gerenciador de senhas, e‑mails de recuperação)
• Dia 2–3: conseguir um deploy limpo que você repita (passos de build, env vars, backups)
• Dia 3–4: corrigir riscos óbvios de segurança (segredos expostos, queries inseguras, auth fraco)
• Dia 4–5: adicionar controles de custo (donos do faturamento, budgets, alertas, cancelar ferramentas não usadas)
• Dia 6–7: adicionar monitoramento básico (erros, checagens de uptime e quem recebe alertas)

Se você herdou um protótipo gerado por IA que já está quebrando em produção, uma equipe de remediação pode encurtar a parte mais dolorosa. FixMyMess (fixmymess.ai) foca em diagnosticar e reparar codebases geradas por IA — coisas como autenticação quebrada, segredos expostos, refatoração e preparação para deploy — para que você possa estabilizar rápido ou reconstruir com um plano claro.