Ter o código não é ser dono. As outras quatro coisas que seguram seu app.

Boa parte das plataformas hoje deixa você baixar o código ou ligar num repositório. Então a reclamação clássica — "você fica preso, o código não é seu" — envelheceu. O código costuma ser seu, sim.

O problema é outro, e é maior:

Você pode ter todos os arquivos do mundo e mesmo assim não conseguir colocar o seu app no ar amanhã.

Porque um app em produção não é um monte de arquivo. É um sistema com cinco partes, e o botão de exportar copia uma.

Vale a distinção logo de cara: uma coisa é ficar preso ao código, outra é ficar preso à operação. A primeira quase todo mundo já resolveu. A segunda quase ninguém olhou.

As cinco coisas que sustentam um app

1. O código. Os arquivos. As telas, as regras, os botões. É o que o exportar copia, e é a parte que a IA refaz mais fácil se você perder.

2. O banco de dados. Onde moram os cadastros, os pedidos, o histórico. Isso não está no código. E é a única parte que, perdida, não volta: código se regenera, dado de cliente não.

3. O login. As contas dos seus usuários, com as senhas guardadas de um jeito que nem você consegue ler — é assim que tem que ser. Migrar isso pra outro serviço sem obrigar todo mundo a criar senha nova é um procedimento específico, e fazer errado significa mandar um e-mail constrangedor pra base inteira.

4. A publicação. O servidor que atende quem digita o endereço, o domínio, o certificado do cadeado, as variáveis de ambiente com as chaves. Nada disso vem junto no zip.

5. Os fios soltos. O envio de e-mail, o recebimento de pagamento, as tarefas agendadas, os avisos que serviços externos mandam pro seu app. Cada um é uma configuração feita numa tela de painel, quase sempre sem registro em lugar nenhum.

Agora repare: quando você exporta o código, você levou o item 1. Os itens 2, 3, 4 e 5 continuam dentro de uma conta que não tem o seu nome.

O teste do desastre

Tem uma pergunta que separa quem é dono de quem está hospedado. Responda de verdade, agora:

Se a sua conta na plataforma sumisse hoje de manhã, quanto tempo até seu app estar no ar de novo, com os dados dos clientes?

Se a resposta for "não sei", isso não é sinal de descuido. É o estado padrão de quase todo mundo, porque ninguém avisa que essa pergunta existe. O tutorial termina em "seu app está no ar 🎉", e a parte de continuar no ar não estava no roteiro.

Não precisa de nada disso pra brincar. Precisa a partir do primeiro cliente pagante — porque aí o dado não é mais só seu.

O inventário: uma folha de papel

Não é preciso migrar nada hoje. O primeiro passo é bem mais simples e resolve a maior parte do risco: escrever onde cada coisa está.

Abra um documento e preencha:

CÓDIGO
  Onde mora hoje:
  Tenho cópia fora da plataforma?  (sim/não)  Onde:

BANCO DE DADOS
  Serviço e conta:
  A conta está no MEU e-mail?  (sim/não)
  Sei exportar os dados?  (sim/não)
  Quando foi o último backup:

LOGIN
  Serviço:
  Quantas contas de usuário existem hoje:

PUBLICAÇÃO
  Serviço:
  Domínio, e onde foi comprado:
  Onde ficam as variáveis de ambiente:

FIOS SOLTOS
  E-mail:
  Pagamento:
  Outros:

Levar quinze minutos preenchendo isso é a coisa de melhor retorno que você faz no seu app este mês. Não porque o inventário conserta algo — mas porque cada linha em branco é um risco que você não sabia que estava correndo, e agora sabe.

As três perguntas que decidem o resto

Com o inventário na mão, três perguntas ordenam o trabalho. A ordem importa.

1. As contas estão no seu nome?

Essa é a primeira e a mais barata. Se o banco de dados, o serviço de publicação ou o domínio estão numa conta criada pela plataforma, ou no e-mail de outra pessoa, resolva isso antes de qualquer outra coisa técnica.

Não é migração — é titularidade. E é o único item da lista que pode te deixar de fora do próprio negócio por motivo puramente administrativo.

2. Você consegue tirar uma cópia dos dados?

Não estou perguntando se existe backup automático. Estou perguntando se você, sozinho, consegue baixar hoje um arquivo com os seus dados.

Faça agora. Baixe. Abra o arquivo e olhe se os registros estão lá.

E o detalhe que quase todo mundo pula: backup que nunca foi restaurado não é backup, é esperança. A hora de descobrir que o arquivo estava vazio ou incompleto não pode ser a hora em que você precisa dele.

Existe um procedimento simples pra isso, que vale pra qualquer migração ou restauração e que eu chamo de conferência de contagem:

1. Conte os registros na origem     →  1.043 pedidos
2. Migre / restaure
3. Conte os registros no destino    →  1.043 pedidos
4. Só apague a origem quando os dois números baterem

Parece óbvio escrito assim. É a etapa que mais some na prática, e é ela que torna a operação reversível.

3. Está escrito em algum lugar como remontar?

A resposta pro "quanto tempo até estar no ar de novo" não pode morar na sua memória, e muito menos na memória de uma conversa de chat que você fechou.

Um documento curto basta. Que serviços existem, em que ordem ligar, quais variáveis de ambiente precisam existir (os nomes delas — nunca os valores, que não podem estar num documento), onde está o backup, como confirmar que voltou.

Isso tem nome, chama runbook, e é o que separa "quatro horas de trabalho chato" de "duas semanas e talvez a perda dos dados".

O que eu não vou te dizer

Não vou te dizer pra sair da plataforma. Elas são boas no que fazem e resolvem de verdade o começo. Sair na hora errada é trocar um problema que você entende por cinco que você não entende.

O que eu digo é: a decisão de sair, ou de ficar, tem que ser sua e informada. Hoje, pra maioria das pessoas, ela não é nem uma nem outra — é o resultado de nunca ter olhado.

Existe uma ordem natural pra migrar, quando chegar a hora, e ela é ditada por dependência: primeiro o código, depois o banco, depois o login, por último a publicação. Cada um depende do anterior estar de pé. Fazer fora de ordem é onde se perde cadastro.

Mas isso é assunto pra outro post. Hoje o pedido é menor e vale mais:

Preencha o inventário. Quinze minutos.

Depois disso você continua exatamente onde está — só que sabendo onde está. Que é a diferença entre estar hospedado e ser dono.