Em resumo. A maioria das pequenas empresas não precisa de um site maior. Precisa do site certo: fácil de encontrar no Google, capaz de aceitar marcações e entregue como PWA, um site que também se instala como uma app. Uma PWA GoodBarber é renderizada do lado do servidor, por isso posiciona-se no Google como qualquer site, e chega integrada numa app Content: PWA mais apps nativas iOS e Android, a partir de uma única configuração. Vende produtos físicos? Isso é uma app à parte: a app eCommerce da GoodBarber, com o seu próprio catálogo e checkout.Num tópico intitulado are we massively overengineering websites for small businesses? (“estaremos a sobredimensionar massivamente os sites das pequenas empresas?”), publicado no r/nocode em julho de 2026, um criador de sites pergunta por que razão se vendem a um contabilista, a um canalizador ou a um tosquiador de cães do bairro animações à medida, um CMS complexo e dezenas de páginas. A resposta mais votada defende que a maioria desses clientes ficaria mais bem servida com um perfil no Google Business Profile e uma simples página de links do que com o site de oito páginas que vieram encomendar. Outro comentário põe o dedo na doença real: confundimos o que impressiona os programadores com o que é útil aos clientes.O tópico tem razão no problema e fica a um passo da solução. A pergunta útil não é o tamanho que o site deve ter. É que ferramenta faz os três trabalhos que um negócio de serviços tem de verdade: ser encontrado por clientes novos, aceitar marcações sem ping-pong telefónico e continuar presente no telemóvel dos habituais. É uma questão de forma. E há um objeto no mercado com exatamente essa forma.O vocabulário é novo para si? As três definições, a explicação de SEO e a tabela comparativa completa site vs app vs PWA estão reunidas num guia de decisão completo. Este artigo concentra-se no caso da pequena empresa.

A versão curta. Não é o que esperaria. Os principais app builders com IA deixam-no genuinamente exportar o código; à data de agosto de 2026, o Lovable sincroniza com o GitHub em todos os planos, incluindo o gratuito, e a sua documentação afirma que está “never locked in”. O lock-in vive noutro lugar: no backend gerido onde os seus dados residem, no alojamento e na autenticação que teria de substituir, no ciclo de edição por IA que fica para trás e na base de código escrita por IA que passa a ser exclusivamente sua responsabilidade no momento em que se vai embora. Ser dono do código nunca foi o mesmo que conseguir sair.Lock-in costumava significar uma coisa simples: o seu trabalho está preso num formato proprietário e a porta de saída está trancada. Os app builders com IA mudaram a forma do problema. A porta está aberta. A questão é o que cabe por ela.Uma app são três bens diferentes com um único nome: o código-fonte, o sistema em funcionamento que serve utilizadores reais e o negócio que a app transporta. A exportação move a primeira. Não move as outras duas. A frustração que atravessa os tópicos de migração deste verão vem de descobrir essa distinção demasiado tarde.

Contagem regressiva para a volta aos treinos e checklist de preparação memorizada para cada associado: uma seção de app criada com IA para o seu clube esportivo — com o prompt completo para roubar.

Site vs aplicação vs PWA: o que faz cada um, quanto custa manter e como escolher. Uma PWA renderizada no servidor é site e app ao mesmo tempo.

A biblioteca de temas Classic da GoodBarber continua a crescer, e esta leva traz dez novos temas para apps de conteúdo. Cada um é uma direção visual acabada que pode tornar sua, para que a sua app pareça cuidada logo no primeiro ecrã. O mais difícil numa app de conteúdo quase nunca é o conteúdo. É fazer com que tudo pareça intencional, ecrã após ecrã, quando o design não é a sua profissão. Um tema resolve isso ao dar-lhe uma direção visual completa: cores, tipografia, estilo de imagens e layout já funcionam em conjunto. Traz o seu conteúdo e a sua marca; o tema traz o acabamento. E como cada tema assenta no Smart Design, o resultado mantém-se coerente por muito que o personalize.

O que acontece com um app nos três anos seguintes ao lançamento: o que se move ao redor dele, o que a plataforma absorve no seu lugar e a curta lista do que continua no seu nome.

Em resumo: o dia do lançamento é o meio do caminho, não a meta. O verdadeiro trabalho de uma app móvel está nas operações diárias: publicações, campanhas de push, atualizações do catálogo, encomendas. É nesse trabalho diário que um agente de IA se torna genuinamente útil.A conversa em torno da IA está obcecada com a criação. Demos de prompt-to-app, ecrãs gerados, protótipos produzidos de uma só vez. É compreensível: a criação dá demos espetaculares. Mas quem já lançou mesmo uma app conhece a parte incómoda: no dia em que a app chega às lojas, a maior parte do trabalho ainda está à sua frente.Uma app que ninguém opera morre em silêncio. Os conteúdos ficam parados, as campanhas de push cessam, o catálogo perde atualidade e a retenção segue o mesmo caminho. Operamos apps em produção desde 2011, e quinze anos de operações ensinam uma lição: o que decide o destino de uma app não é a forma como foi criada, mas a forma como é gerida. Examinámos esse ponto cego em Os app builders com IA sabem criar uma app. Sabem operá-la?: o setor tornou-se muito bom a gerar apps e manteve um silêncio estranho sobre a forma de as operar.É por isso que uma nova categoria está a ganhar forma: a app operável por agentes. Não uma app criada por IA, mas uma app cujas operações diárias um agente de IA consegue realmente executar, segundo as suas instruções, com salvaguardas. Constrói-se uma vez. Opera-se para sempre. E é na segunda parte que se vive.

A Replit constrói ferramentas de desenvolvimento dentro do navegador desde 2016. No início de 2026 acrescentou uma oferta mobile, sob uma página intitulada «Idea to Mobile App in Minutes» — o que a coloca, pela primeira vez, no terreno dos criadores de apps.Passamos então pela plataforma o nosso briefing habitual: AURORA, o mesmo app de guia de viagem de alto padrão que construímos em cada ferramenta desta série. Não uma lista de funcionalidades, mas um app de verdade, que precisa chegar às lojas, ser atualizado toda semana e ser operado por alguém que não escreve código.O que sai da Replit é sólido. E é também, sem ambiguidade, uma base de código: um projeto React Native, uma nuvem cobrada por uso e um console de desenvolvimento. Toda a comparação cabe nessa frase — a Replit responde em linguagem natural e depois entrega algo que se comporta como um projeto de engenharia. Se isso é um presente ou um problema depende inteiramente de quem vai tocar o app na próxima terça-feira.

Nomeie qualquer secção de conteúdo da sua app no seu prompt, e o AI Extension Builder constrói uma secção que mostra esse conteúdo — com o layout exato que descreveu. Os seus artigos, o seu template, sempre atualizado. Cada secção de conteúdo de uma app GoodBarber vem com uma gama de templates cuidadosamente desenhados. Escolhe um e funciona — é essa a vantagem de uma plataforma integrada. Mas o layout que tem em mente nem sempre está na lista. Talvez imagine os seus últimos artigos em estilo revista: uma grande foto de capa com o título sobreposto, cartões mais pequenos por baixo. Ou os seus eventos numa agenda compacta, só com a data e o local. Até agora, escolhia o template que mais se aproximava.O que muitos utilizadores do AI Extension Builder ainda não descobriram é que esse limite desapareceu. O builder não cria apenas widgets independentes — sabe ler o conteúdo das secções existentes da sua app. E isso torna-o em algo mais interessante do que um gerador de widgets: uma ferramenta para desenhar os seus próprios templates de apresentação.

O posicionamento de uma PWA assenta num princípio simples: para que uma página apareça nos resultados de pesquisa, um motor tem primeiro de a visitar, ler e indexar. Essa passagem — o rastreio (crawl) — não é você que a desencadeia. É o motor que decide quando volta, ao seu próprio ritmo.Para um site estático, essa espera pouco importa. Para uma app cujo conteúdo está vivo — um meio que publica várias vezes por dia, uma loja cujos preços e stock mudam, uma agenda cujos eventos surgem e expiram — é um entrave real. O trabalho já está feito: o conteúdo está online, atualizado, pronto a ser encontrado. Mas fica à espera de um rastreador que ainda não voltou. Entretanto, às vezes é uma versão antiga da página — ou nada de todo — que aparece nos resultados.

Se publicou a sua PWA, ela está a servir um robots.txt neste momento: o primeiro ficheiro que um robô lê, e o que decide o que vem a seguir — que partes do seu site são exploradas, e por quem. O seu diz que sim a toda a gente.Tudo o que se segue diz respeito a essa versão web da sua aplicação. As suas apps iOS e Android não são exploradas por ninguém, e o separador só aparece depois de a PWA ter sido publicada pelo menos uma vez: antes disso não há ficheiro nenhum para configurar.Era uma resposta defensável. Simplesmente não era a sua — e o público a quem responde mudou. Há uns anos, um robô sobre o seu conteúdo era o Google, o Bing ou um aspirador que lhe era indiferente. Hoje, uma parte crescente desse tráfego pertence a empresas de IA, e não querem todas a mesma coisa das suas páginas. Tratá-las em bloco é escolher entre todas e nenhuma.O novo separador divide-as em quatro famílias: Search engines (Google, Bing e os outros motores que referenciam o seu site nos resultados), AI answers (ChatGPT, Claude ou Perplexity quando citam o seu site nas respostas), AI training (os robôs que recolhem o seu conteúdo para treinar os seus modelos) e On-demand reading (quando alguém pede a uma IA que abra e leia uma página específica do seu site). Quatro famílias, porque são quatro acordos diferentes.

Resumo. Um aplicativo móvel que não é atualizado não fica congelado: ele se degrada. As notificações push param de chegar, os novos usuários param de encontrá-lo, e as lojas acabam ocultando ou removendo o app. Na GoodBarber, a plataforma absorve cada mudança dos OS e das lojas e entrega a correção com a sua próxima atualização: um ano de solavancos do mundo mobile chega até você como uma nota de versão. A única coisa que continua com você: atualizar com regularidade.Seu app funciona hoje. Deixe-o um ano sem mexer: ele vai continuar abrindo, continuar bonito, continuar fazendo o trabalho dele no seu próprio telefone. Nada no seu painel avisa você. A armadilha está exatamente aí.Porque enquanto seu app ficava parado, tudo o que o sustenta se moveu. Apple e Google lançaram novos sistemas operacionais, reescreveram as regras das lojas, aposentaram encanamentos antigos. Você percebe meses depois, por sintomas que parecem um problema de marketing: os downloads esfriam, as campanhas push alcançam cada vez menos gente, um usuário fiel escreve dizendo que o app se comporta mal no telefone novo dele. A degradação é real, e não tem nada a ver com a qualidade do seu conteúdo.

Em resumo. Um servidor MCP vale apenas pelo que expõe. Plataformas BaaS como o Back4app e o Supabase expõem o seu backend: tabelas da base de dados, esquemas, queries, cloud code. O servidor MCP da GoodBarber expõe as operações de uma app móvel em produção: publicar um artigo, agendar uma notificação push, atualizar o catálogo, ler as estatísticas. 150 ferramentas tipadas por domínio à data em que escrevemos, condicionadas às funcionalidades ativas, restritas a uma app por OAuth, com read-back verificado em cada escrita. O mesmo protocolo, uma altitude muito diferente.O Model Context Protocol venceu depressa. Apresentado pela Anthropic em novembro de 2024 e doado à Linux Foundation um ano depois, o MCP é hoje a forma padrão de dar ferramentas a um agente de IA, com mais de 9.400 servidores públicos listados no MCP Registry oficial em 2026. O que significa que a frase “temos um servidor MCP” se tornou, discretamente, uma simples caixa de verificação. Qualquer plataforma pode assinalá-la, e esse visto não lhe diz nada.As perguntas que importam estão um nível abaixo. O que é que o servidor permite a um agente ver? O que é que lhe permite alterar? E, quando o agente escreve, o que se interpõe entre um prompt bem formulado e um sistema em produção avariado? As respostas dependem muito menos do protocolo, que é igual para todos, do que da altitude à qual cada plataforma se liga.

Já ninguém duvida de que uma IA consiga gerar código capaz — mesmo «vibe-coded», funciona, às vezes muito bem. Não é essa a pergunta interessante. A pergunta interessante é: uma vez gerada, o que faz realmente essa secção dentro da tua app? Fica como um bloco isolado a um canto, ou aproveita o que o dispositivo e a app já sabem fazer? A forma mais honesta de responder é pegar num prompt e desmontá-lo, linha a linha.É para isso que serve esta nova série. Em cada episódio pegaremos num prompt da biblioteca do AI Extension Builder e desmontá-lo-emos: onde confia na plataforma, onde a força, e o que sabe fazer de facto a secção resultante. Começamos com um dos prompts de exemplo da biblioteca: «onde estacionei».Este é o prompt mais curto que poderias escrever para isto:Build a "remember where I parked" helper.É tudo. Uma frase, não um caderno de encargos. E eis o que sai:Um botão para guardar a tua localização. Uma secção que reencontra esse ponto ao reabrir a app. Um botão para voltar ao carro. Um link discreto para apagar. E, se recusares a localização, um ecrã que o explica em vez de falhar.A surpresa não é que sete palavras desenhem um ecrã. É que esta secção, nascida de uma frase, já aproveita as capacidades do dispositivo: lê o GPS, guarda uma memória, abre o Maps. Não pedimos nenhuma destas três coisas.

Um quiz de personalidade — « Which 2026 Summer Blockbuster Is Your Vibe? » — criado inteiramente ao descrevê-lo ao AI Extension Builder da GoodBarber. O quiz, por que o formato funciona e o prompt exato para roubar.

App builders com IA acertam no protótipo. A produção é outra história: propriedade, lojas, manutenção. Com o GoodBarber, agentes de IA operam a app nativa.

Organizámos um AMA em direto no r/GoodBarber, aberto a qualquer pergunta sobre publicar uma app na App Store: App Review, App Store Connect, contas de programador, tudo. As respostas vieram diretamente da equipa de suporte que gere todos os dias as publicações na App Store e na Google Play, com engenheiros iOS a entrar sempre que uma pergunta se tornava técnica. Aqui fica o resumo. Fazem-nos esta pergunta muitas vezes, por isso analisámos os nossos próprios casos de suporte dos últimos 18 meses. Os motivos de rejeição mais comuns são menos dramáticos do que se pensa:Metadados da App Store incompletos ou incorretos — informação, capturas de ecrã ou descrições em falta ou enganosas.Um formulário de App Privacy mal configurado.Apps que a Apple considera incompletas ou não totalmente funcionais durante a revisão.Além disso, vemos regularmente rejeições ligadas a direitos de conteúdo (sobretudo áudio ou vídeo), apps em setores regulados que não cumprem as expectativas da Apple, ou consideradas demasiado parecidas com algo que já existe.Para uma primeira submissão, tudo começa nos metadados: destaca o valor real da tua app em vez de uma promoção genérica, e segue as guidelines da Apple — são a base de tudo o resto. E se fores rejeitado, não entres em pânico. Uma rejeição não é um beco sem saída, normalmente é só parte do processo. Lê com atenção o feedback da Apple, resolve cada ponto e volta a submeter — já vimos muitas apps serem aprovadas depois de uma, ou várias, rondas de revisão.Se estiveres convencido de que um revisor se enganou, mantém-te nos factos. Explica claramente porque achas que a tua app cumpre a guideline em questão, e sustenta o argumento com tudo o que possa ajudar — capturas de ecrã, uma gravação de ecrã, credenciais de teste, instruções passo a passo se uma funcionalidade não for óbvia. Se a conversa não avançar, podes pedir uma chamada com um representante da Apple através do App Resolution Center no App Store Connect — uma conversa direta costuma esclarecer mal-entendidos mais depressa do que uma troca escrita. Como último recurso, podes recorrer ao App Review Board, onde um membro sénior da equipa da Apple revê o caso. Em qualquer dos casos, o objetivo não é provar que a Apple está errada, mas facilitar ao máximo que o revisor perceba porque é que a tua app cumpre.

O vibe coding transforma uma ideia numa demo funcional em minutos. Publicá-la é outra história: os sete muros entre um protótipo gerado por IA e uma app real nas lojas.

Pedimos ao AI Extension Builder da GoodBarber um jogo de arcada completo: um Flappy Bird jogável com o dedo, em ecrã inteiro, com uma classificação partilhada por todos os jogadores. Aqui fica o resultado, o prompt exato que o gerou e aquilo que esta prova de conceito revela: com o AI Extension Builder, quase tudo o que se consegue descrever pode tornar-se uma secção da sua app. Um videojogo não é aquilo que se espera de um app builder.E é precisamente isso que faz dele um bom teste. Para perceber do que o AI Extension Builder é realmente capaz, mais vale pedir-lhe o improvável do que mais uma secção do costume. Descrevemos-lhe, então, um jogo de arcada completo — jogável com o dedo, em ecrã inteiro, com uma classificação partilhada por todos os jogadores — e ficámos a ver até onde aguentava.Aguentou. A lição não é "publique jogos", mas antes "o teto está muito mais alto do que imagina": o que vale para um Flappy Bird vale também para aquela funcionalidade específica de que a sua app precisa mesmo. Tudo lhe foi descrito por palavras, em alguns parágrafos. Aqui fica o resultado.

As atualizações deste mês concentram-se na visibilidade, na conformidade e na experiência de utilização — novas formas de destacar ações importantes, de proteger os utilizadores mais jovens e de tornar mais fluidas as interações do dia a dia na sua aplicação. Eis as novidades:Novo Floating Button global: destaque uma ação importante em toda a sua aplicação, configurada uma única vez a partir do Structure panel.Age Protection: uma nova funcionalidade para cumprir as leis regionais de verificação de idade e proteger automaticamente os utilizadores mais jovens.Miniaturas de eventos no mapa: os eventos apresentados num mapa podem agora surgir com a sua própria imagem de miniatura em vez de um marcador padrão, para que cada um seja reconhecível de imediato.Mostrar/ocultar palavra-passe: os seus utilizadores podem agora tocar no ícone de olho para mostrar ou ocultar a palavra-passe em qualquer ecrã de início de sessão ou de registo, para que um erro de escrita nunca mais os bloqueie.