Seu app de IA só é seu quando você consegue reconstruí-lo fora da plataforma

Um app pode continuar no ar e, ao mesmo tempo, sair do controle de quem o criou.

O aviso de retirada do GitHub Spark tornou essa diferença bem concreta. Segundo o anúncio, os apps existentes podem continuar publicados, mas o código precisa ser exportado até 31 de agosto de 2026 para continuar editável. Quem usou a função llm() também terá de escolher outro provedor e assumir a própria chave de API e a cobrança.

A primeira reação costuma ser baixar o código e respirar aliviado. Só que um repositório exportado prova que você recebeu arquivos. Ele ainda não prova que o produto volta a funcionar sem o painel em que nasceu.

Eu gosto de plataformas que deixam uma ideia chegar ao primeiro usuário sem exigir uma semana de infraestrutura. Esse ganho é real. O cuidado começa quando runtime, autenticação, dados, inferência e custos ficam misturados numa caixa-preta que ninguém mapeou. Nessa hora, uma promessa de "zero lock-in" ajuda pouco; um teste de reconstrução mostra o que você realmente consegue recuperar.

Um app no ar ainda pode estar fora do seu controle

Existem pelo menos três situações diferentes que parecem iguais enquanto tudo funciona:

1. o deploy atual continua respondendo;
2. o projeto ainda pode ser editado no ambiente original;
3. o time consegue instalar, configurar, executar e manter o sistema por conta própria.

O fato de o app estar acessível cobre apenas a primeira. Se o ambiente de edição desaparecer ou uma integração proprietária for desligada, você pode continuar com uma URL viva e ainda assim perder a capacidade de corrigir um bug, trocar um provedor ou alterar o fluxo principal.

Em vez de parar em "consigo exportar?", verifique se uma pessoa com acesso ao repositório e às contas certas consegue recuperar o produto num ambiente limpo, seguindo instruções versionadas.

Essa mudança de pergunta tira o debate do campo abstrato do lock-in. Em vez de discutir se uma plataforma é aberta ou fechada, você passa a observar dependências concretas e decide quais riscos fazem sentido para o estágio do projeto.

O ZIP contém código, não a operação inteira

Antes de migrar qualquer coisa, faça um inventário curto. Para cada item, marque uma destas condições:

• próprio: está no seu repositório ou numa conta administrada por você;
• substituível: depende de um serviço externo, mas existe uma fronteira conhecida para trocá-lo;
• preso à plataforma: não há exportação, documentação ou caminho de substituição testado.

O inventário de um app de IA costuma incluir:

Parte do sistema	Pergunta de reconstrução
Runtime	A versão e o comando de execução estão registrados?
Build	Uma máquina limpa consegue instalar e compilar o projeto?
Configuração	Existe um .env.example que explica as variáveis sem expor segredos?
Inferência	O provedor de IA está atrás de uma integração identificável?
Dados e arquivos	Há exportação, esquema e destino conhecido para restauração?
Autenticação	Usuários e sessões dependem de qual conta ou serviço?
Domínio	Quem controla DNS, certificados e redirecionamentos?
Custos	API, armazenamento e tráfego têm conta, limite e responsável definidos?
Observabilidade	Logs mostram falhas, consumo e rate limits fora do painel original?

Nem toda dependência precisa ser eliminada. Serviços gerenciados existem justamente para poupar trabalho. O problema aparece quando ninguém sabe onde a dependência começa, quem é dono da conta e o que acontece se ela mudar de preço ou disponibilidade.

Faça o teste em um ambiente realmente limpo

A melhor documentação para esse caso é um procedimento que alguém já executou. Use uma pasta vazia, uma máquina descartável ou um ambiente efêmero e tente reconstruir o fluxo principal.

Um teste enxuto pode seguir seis passos:

1. Exporte o projeto e registre o código no repositório que o time controla.
2. Clone esse repositório em um ambiente sem caches e configurações locais antigas.
3. Instale as dependências e gere o build usando apenas as instruções salvas no projeto.
4. Preencha as variáveis a partir de um template, buscando os segredos no lugar correto.
5. Substitua integrações proprietárias por adaptadores explícitos, começando pelo provedor de IA exigido pelo fluxo principal.
6. Execute um smoke test que percorra a entrega de valor do início ao fim.

O smoke test precisa olhar para o produto, não apenas para o processo de build. Se o app recebe um prompt, gera um artefato e permite baixá-lo, esse caminho completo deve funcionar. Uma tela inicial carregando com status 200 diz muito pouco sobre a reconstrução.

Registre também o que falhou. Um passo manual esquecido, uma permissão herdada da conta do criador ou uma variável cujo significado ninguém conhece são resultados úteis. O objetivo do teste é encontrar dependências enquanto ainda existe tempo para entendê-las.

Exemplo: um gerador de imagens para posts

Imagine um protótipo que recebe um prompt, chama um modelo de imagem e entrega uma peça pronta para redes sociais. À primeira vista, o repositório parece conter o produto. Na prática, o fluxo atravessa vários limites:

prompt
  -> regra de negócio
  -> provedor de geração
  -> arquivo gerado
  -> pós-processamento
  -> armazenamento ou download
  -> publicação

A reconstrução começa pela entrada. Registre onde o prompt é validado, qual modelo gera a imagem e qual conta paga por essa chamada. Depois, confirme se o app guarda o arquivo ou entrega uma URL temporária e se o usuário ainda consegue baixar o resultado sem o serviço original de armazenamento.

O pós-processamento também merece uma fronteira própria. Depois da geração, uma opção externa como Resize Image for Instagram pode preparar os formatos no navegador sem enviar os pixels para processamento remoto. Isso mantém redimensionamento, recorte, preenchimento, prévia e exportação fora do backend do app, mas o navegador e o dispositivo do usuário passam a definir os limites de desempenho e compatibilidade dessa etapa.

Esse recurso não substitui o gerador. O app ainda precisa cuidar do prompt, do provedor de IA, do estado da tarefa, da entrega do arquivo e dos erros. O exemplo é útil justamente porque deixa cada responsabilidade visível. Se amanhã outra ferramenta assumir o pós-processamento, o restante do fluxo não deveria precisar ser reescrito.

Evite construir uma arquitetura imaginária

Existe um risco no sentido oposto: tentar abstrair tudo antes de saber se o produto terá um segundo usuário.

Criar interfaces universais para cinco provedores, manter dois bancos sincronizados e executar deploy em duas nuvens pode custar mais que a dependência que você queria evitar. A saída precisa ser proporcional ao estágio do projeto.

Para um protótipo, eu começaria com controles bem modestos:

• repositório sincronizado fora da plataforma;
• versões de runtime e dependências registradas;
• template de configuração sem segredos reais;
• mapa curto de serviços, contas e responsáveis;
• um adaptador estreito no ponto mais difícil de substituir;
• smoke test do fluxo que entrega valor.

Se o app ganhar usuários, dados importantes ou receita, o teste pode crescer. Aí faz sentido documentar recuperação de dados, limites de API, rotação de credenciais, domínio, observabilidade e rollback. A arquitetura acompanha a consequência de uma falha, em vez de antecipar cenários que talvez nunca existam.

Também não é necessário manter duas operações completas o tempo todo. Isso duplica custo e atenção. Reconstruir periodicamente em um ambiente descartável costuma oferecer uma evidência melhor: mostra se o caminho de saída ainda funciona sem obrigar uma equipe pequena a operar dois produtos em paralelo.

Projete a saída enquanto ainda não há urgência

A pior hora para descobrir a arquitetura real é durante uma retirada com prazo. Nesse momento, cada variável sem descrição e cada conta pessoal viram uma investigação concorrendo com a migração.

Alguns hábitos baratos reduzem bastante essa pressão:

• exporte e versione o código desde cedo, quando a plataforma permitir;
• anote quem controla cada serviço externo;
• deixe a configuração necessária visível num template;
• isole integrações proprietárias onde a troca seria cara;
• teste a reconstrução depois de mudanças relevantes no runtime ou nos provedores;
• guarde o procedimento ao lado do código e corrija as instruções quando elas falharem.

Código exportado também não leva automaticamente dados, credenciais, documentação, domínio ou ações já executadas em serviços externos. O teste deve dizer o que é recuperável, o que precisa de migração separada e o que simplesmente não pode ser desfeito.

Checklist antes de chamar o app de portável

Use estas perguntas numa revisão curta:

• O repositório compila fora da plataforma de origem?
• As versões de runtime e dependências estão registradas?
• Existe um template de variáveis sem segredos reais?
• Dados, arquivos, autenticação e domínio têm donos conhecidos?
• A integração de IA pode ser substituída sem reescrever toda a regra de negócio?
• Custos, rate limits e falhas aparecem em logs acessíveis?
• Um ambiente limpo consegue concluir o fluxo principal?
• O procedimento foi executado recentemente por alguém além de quem criou o app?

Uma plataforma pode ser a escolha certa para validar uma ideia e ainda exigir um plano de saída. Não há contradição nisso. Ela compra velocidade para a primeira decisão; o teste de reconstrução preserva a capacidade de tomar a próxima.

Fonte

• Upcoming deprecation of GitHub Spark