A checklist de produção que as apps criadas com IA chumbam (7 coisas que se partem depois da demo)

Construiu uma app com um app builder com IA, ou fê-la em vibe coding, prompt a prompt, ao longo de algumas noites. Funciona. Mas repare nas condições em que funciona: o seu telemóvel, o seu Wi-Fi, a sua conta, dados que introduziu à mão, um build gerado há uma hora. Uma demo é uma app testada exclusivamente em condições amigáveis.

Pronta para produção significa o contrário: a app continua a funcionar quando as condições amigáveis desaparecem. Desconhecidos em vez de si, um revisor em vez de uma audiência, meses em vez de uma tarde.

Já escrevemos sobre a origem deste fosso: o nosso artigo sobre os sete muros entre um protótipo e as lojas mapeia a distância estrutural, e o nosso texto sobre criar uma app versus operá-la dá nome ao trabalho que começa depois do lançamento. Esses artigos terminam em perguntas que vale a pena fazer a si mesmo. Este transforma as perguntas em experiências: sete verificações, cada uma com um procedimento concreto e uma condição de aprovação que não deixa margem para discussão, todas executáveis esta semana. Se uma verificação lhe parecer aborrecida, é exatamente essa a ideia. A produção é onde vivem os bugs aborrecidos.

1. Um desconhecido consegue criar uma conta, sair e voltar

A demo nunca termina sessão. Construiu a app já autenticado, num dispositivo que o reconhece, por isso toda a maquinaria das contas ficou por testar: o email de confirmação que aterra no spam, a reposição de palavra-passe que nunca chega, a sessão que morre a cada reinício, a conta que existe no seu telemóvel e em mais lado nenhum. As contas são a primeira coisa em que um desconhecido toca e a última que uma demo testa.

A verificação: num dispositivo que nunca viu a sua app (o telemóvel de um familiar serve, e, para uma web app, uma janela de navegação privada), crie uma conta com um endereço de email que seja seu mas que nunca tenha usado com ela. Confirme-a. Termine sessão. Reponha a palavra-passe. Volte a iniciar sessão. Feche a app e regresse no dia seguinte.

Passa quando: todos os passos funcionam sem que tenha de tocar num dashboard, reenviar o que quer que seja à mão ou explicar uma forma de contornar o problema.

2. A app sobrevive vazia, offline e ao duplo toque

A sua demo corre sobre dados que introduziu à mão, com boa ligação, conduzida pela única pessoa que sabe onde não clicar. Um utilizador real começa sem nada disso: uma conta acabada de criar vê zero conteúdo, o metro corta a ligação a meio de uma ação e um polegar impaciente toca duas vezes no botão de pagamento. São os estados aborrecidos, e as apps geradas tendem a não os tratar, porque ninguém os pediu num prompt. A Apple dá com eles antes dos seus utilizadores: pela experiência da nossa equipa de publicação, é rotina uma app ser aberta offline durante a revisão, e o que ela mostra sem rede conta.

A verificação: instale de raiz, ou abra a app numa janela privada, e use-a em modo de avião; corte também a ligação a meio de uma ação. Depois percorra todos os ecrãs com uma conta nova, com zero dados. Depois toque duas vezes, depressa, em todos os botões que criam ou pagam alguma coisa. Mantenha a parte dos pagamentos no modo de teste do seu fornecedor, ou use um artigo barato que reembolsa logo a seguir: o que procura é saber se aparecem duas encomendas, não se o dinheiro se moveu.

Passa quando: nenhum ecrã em branco, nenhum spinner infinito, nenhum crash e nenhuma encomenda duplicada.

3. A App Store e o Google Play vão aceitá-la

É aqui que o resultado do seu builder encontra o mundo exterior. As lojas querem binários nativos assinados, contas de programador (99 USD por ano na Apple, uma taxa única de 25 USD na Google), metadados de loja e declarações de privacidade que não existiam há uns anos: a secção Data safety do Google Play é obrigatória desde julho de 2022, os privacy manifests da Apple desde maio de 2024. Muitas ferramentas prompt-to-app geram aplicações web, porque uma web app é o que um prompt consegue publicar num único passo, por isso este muro tende a chegar tarde. Uma web app é uma superfície legítima (o GoodBarber entrega uma Progressive Web App a par do nativo), mas abdica da distribuição das lojas e, para a maioria dos utilizadores de iOS, do push. E depois vem a revisão: das primeiras submissões que a nossa equipa de publicação tratou nos 12 meses até abril de 2026, cerca de 42% voltaram da Apple rejeitadas, e isso é a linha de base de uma equipa preparada, não uma penalização para principiantes.

A verificação: três perguntas, respondidas com nomes e não com palpites. A sua ferramenta consegue produzir binários iOS e Android assinados? Tem contas de programador na Apple e na Google? Consegue dizer, hoje, que dados a app recolhe, onde ficam armazenados e que serviços de terceiros lhes tocam?

Passa quando: três sins, por escrito, antes de marcar a data de lançamento.

4. Um push agendado esta noite está no ecrã de bloqueio amanhã

O push é a razão pela qual uma app ganha a um website em retenção, e é também a funcionalidade que uma demo finge melhor: parece tudo ligado até ao primeiro telemóvel bloqueado. A entrega é binária, e é por isso que esta verificação é uma experiência de uma noite e não uma pergunta. Desde o iOS 16.4 (março de 2023), o iOS só entrega web push a web apps que o utilizador adicionou deliberadamente ao ecrã principal; no browser, não toca nada. Ou seja, uma web app criada com IA pode parecer idêntica a uma app nativa no seu ecrã e ficar muda no momento em que o telemóvel bloqueia. Se nem sequer consegue encontrar onde, na sua ferramenta, se agenda uma notificação push, já tem a resposta: a verificação falhou.

A verificação: agende uma notificação push para o seu próprio telemóvel para as 7:00 de amanhã e bloqueie o telemóvel esta noite.

Passa quando: a mensagem está no ecrã de bloqueio quando acorda.

5. Consegue nomear todos os serviços de que a app depende, e todas as faturas

Uma app gerada é uma app montada. Debaixo da demo está uma stack que o prompt escolheu por si: alojamento aqui, uma base de dados ali, um serviço de envio de emails, armazenamento de imagens, estatísticas, talvez um processador de pagamentos. Cada um tem um login, um plano gratuito que acaba, chaves que expiram e uma fatura que cresce segundo a sua própria curva. A demo esconde tudo isto porque, para um utilizador numa única tarde, está tudo grátis e ainda nada avariou. A produção faz uma pergunta mais dura: quando a app estiver em baixo às 2 da manhã, qual destes serviços verifica primeiro, e quem atende?

A verificação: escreva o inventário, começando por onde um não-programador realmente consegue: procure na caixa de entrada todas as mensagens “Welcome to” e “Verify your email” recebidas enquanto construía, acrescente todos os logins que criou pelo caminho, todos os débitos recorrentes no extrato do cartão e o que as páginas de integrações e de faturação do seu builder listarem. Para cada linha: quem é o dono da conta, quanto custa com 1.000 utilizadores e se renova em silêncio.

Passa quando: cada linha tem um dono e um preço. Se montar a lista o surpreendeu, a surpresa é a conclusão.

Este inventário tem ainda uma segunda utilidade. Os serviços que estão nele são também aquilo que teria de substituir se um dia saísse do seu builder, e é aí que mora o verdadeiro lock-in: desmontámos essa questão em ser dono da app não é o mesmo que conseguir sair dela.

6. Uma alteração sai sem arrastar o resto consigo

A primeira atualização é o teste mais difícil que uma app criada com IA enfrenta, porque no lançamento começam a correr dois relógios. O primeiro é o seu: os utilizadores encontram bugs, e corrigi-los por prompt pode reescrever em silêncio partes que já funcionavam, aquilo a que chamamos regeneration drift (a deriva de regeneração). Numa base de código gerada, o ciclo de mudar uma etiqueta tem uma forma particular: altera a etiqueta, regenera, e depois descobre qual dos ecrãs em que não tocou mudou na mesma. O segundo relógio pertence à Apple e à Google: cada uma lança uma nova versão principal do seu sistema operativo todos os anos, a Google sobe anualmente a versão mínima de Android que uma app tem de visar, e a Apple remove as apps que passam três anos sem atualização e quase não têm downloads, após um aviso de 90 dias. Uma app que não consegue alterar com segurança é uma app que não consegue manter publicada; escrevemos o que se degrada em silêncio quando uma app deixa de ser atualizada para a versão em câmara lenta.

A verificação: altere um detalhe visível (uma etiqueta, um preço, uma cor) e publique a alteração: como atualização de loja se já está no ar, ou regenerando e voltando a fazer deploy se ainda não está. Depois confirme que três coisas que funcionavam antes continuam a funcionar.

Passa quando: a alteração saiu, os três fluxos testados de novo continuam a funcionar e o ciclo completo demorou uma tarde, não uma semana.

7. Alguém consegue operar a app sem reabrir o builder

Daqui a seis meses, o que a app precisa é operacional, não generativo: publicar o artigo da semana, alterar um preço, responder a um cliente, enviar o push da promoção, ler os números. Se cada uma destas tarefas significa reabrir a ferramenta que gerou a app e voltar a fazer prompts com cuidado à volta do que não pode partir, a app tem um ponto único de falha: quem a criou, no builder, para sempre. Uma app é operável quando as suas tarefas diárias vivem numa interface feita para elas, ou podem ser entregues a outra pessoa: um colega, ou um agente de IA ligado através de um protocolo aberto como o MCP. Quem faz a metade de operar do trabalho, e com que ferramenta, decide mais do futuro da sua app do que qualquer ecrã que tenha gerado.

A verificação: liste as cinco tarefas de que a sua app vai precisar todas as semanas. Para cada uma, diga quem a faz e em que ferramenta.

Passa quando: nenhuma das cinco respostas é “eu, a voltar a fazer prompts no builder e a torcer para que corra bem”.

Pontue com honestidade. Sete aprovações: anuncie o lançamento. Uma ou duas falhas: já sabe qual é o trabalho desta semana. Três ou mais: o que tem é uma ideia validada, o que é genuinamente valioso, e merece uma fundação construída para a parte que vem a seguir.

Eis porque podemos publicar esta checklist sem pestanejar: no GoodBarber, a maior parte dela não é trabalho seu.

As verificações 1 e 2 vêm feitas de origem. Contas, sessões, comportamento offline e estados vazios chegam como componentes nativos, endurecidos ao longo dos milhares de apps ativas que a plataforma aloja, em vez de gerados de fresco para a sua. A verificação 3 é um serviço. O GoodBarber compila binários nativos a sério, Swift para iOS e Kotlin para Android, além de uma Progressive Web App a partir da mesma configuração. As declarações de privacidade que a Apple e a Google pedem partilham a fonte de verdade com o próprio build, as funcionalidades que ativou, pelo que declaração e binário não podem divergir. E se preferir não enfrentar a revisão sozinho, a equipa de publicação que pode assumir a sua submissão recuperou 91% das rejeições da Apple à primeira submissão (acompanhamento interno da equipa de publicação, 12 meses até abril de 2026).

A verificação 4 é infraestrutura: o pipeline de push corre de ponta a ponta na plataforma e move vários milhões de notificações por semana. A verificação 5 encolhe para uma única linha, porque alojamento, base de dados, CMS, push, estatísticas e gateways de pagamento vivem numa única subscrição, com 0% de comissão GoodBarber nas transações de e-commerce. Essa consolidação é grande parte da razão pela qual o custo total de propriedade fica em cerca de um décimo do desenvolvimento à medida. E a verificação 6 é absorvida a montante: quando a Apple ou a Google muda um requisito, o GoodBarber corrige-o uma vez, e a sua atualização seguinte entrega-o.

A verificação 7 é onde a IA volta a entrar, desta vez do lado certo da demo. Qualquer app GoodBarber pode ser operada por um agente de IA através do servidor MCP da plataforma: diga ao seu assistente o que precisa, e o artigo sai, o push fica agendado, o preço muda e os números da semana passada voltam em linguagem corrente, a partir do Claude, do ChatGPT, do Cursor ou de qualquer cliente compatível com MCP. A verificação 7 inteira passa a ser uma decisão de delegação. E agent ready significa que a app pode ser operada por um agente, não que se gere sozinha: as regras e a revisão final continuam do seu lado.

O âmbito do GoodBarber são as apps de conteúdo e o comércio mobile: não cria jogos, e um marketplace assente em lógica personalizada pesada merece uma resposta diferente, que preferimos dar-lhe já. Dentro desse âmbito, esta checklist é aquilo que a plataforma foi construída para carregar. Algures, uma app GoodBarber é descarregada a cada 4 segundos, e os clientes pagantes da plataforma estão espalhados por 152 países. É a este resultado que se chega passando estas verificações, ano após ano.

O que significa “pronta para produção” para uma app mobile?

Uma app pronta para produção sobrevive às três coisas que uma demo nunca contém: utilizadores reais, revisão real nas lojas e tempo real. Em concreto: desconhecidos criam contas sem ajuda, a app trata os estados vazios e offline, as lojas aceitam os seus binários assinados e as suas declarações de privacidade, as notificações push são entregues, cada serviço da sua stack tem um dono identificado, pode ser atualizada sem partir o que já funciona e a sua operação semanal não depende de uma única pessoa.

A minha app criada com IA está pronta para produção?

Faça sete verificações: criação e recuperação de conta num dispositivo que nunca viu a app, estados vazios e offline, submissão às lojas com um binário nativo assinado, entrega de push num telemóvel bloqueado, um inventário com preços de todos os serviços da stack, uma atualização que não muda nada além do que devia mudar e a operação semana após semana fora do builder. Passe as sete e está pronto para anunciar. As falhas mais prováveis são a submissão às lojas, o push e a primeira atualização, porque muitos app builders com IA geram aplicações web em vez de binários nativos assinados, e a geração não cobre a conformidade com as lojas nem a manutenção.

Uma app criada com IA consegue passar na revisão da App Store?

Só como uma verdadeira app nativa. A Apple exige binários assinados, declarações de privacidade preenchidas e uma app que seja mais do que um website reembalado (Guideline 4.2). A rejeição é a norma e não a exceção: a Apple recusou cerca de 42% das primeiras submissões que a equipa de publicação do GoodBarber tratou nos 12 meses até abril de 2026, e 91% dessas rejeições acabaram aceites depois de corrigidas.

O que se parte primeiro depois de lançar uma app criada com IA?

As coisas aborrecidas, mais ou menos por esta ordem: a autenticação (emails de confirmação, reposição de palavra-passe, sessões mortas), depois os estados vazios e offline, depois a entrega de push, depois a primeira atualização, em que corrigir um bug por prompt pode reescrever partes que funcionavam. O padrão por trás de todas é o mesmo: uma demo é testada em condições amigáveis, e a produção retira-as uma a uma.

Preciso de um programador para manter uma app criada com IA a funcionar?

Se a app é código gerado sobre uma stack montada, alguém tem de ser dono desse código e dessa stack, e isso é trabalho de programador, quer o saiba fazer, quer não. Numa plataforma gerida como o GoodBarber, a equipa de engenharia da plataforma mantém o código, o alojamento, a infraestrutura de push e a conformidade com as lojas; opera a app a partir de um back office, ou entrega as tarefas do dia a dia a um agente de IA através do servidor MCP. Fica com o papel de operador, não com o de engenheiro.

Próximo passo: nada do que construiu está perdido. A demo respondeu à pergunta cara, saber se a ideia merece uma app, e os seus ecrãs são agora a especificação. Comece um teste gratuito do GoodBarber, reconstrua a ideia sobre essa especificação e aplique esta mesma checklist ao resultado: as seis primeiras verificações ficam a cargo da plataforma, e a sétima resolve-se com uma frase a um agente.