---
title: "O vibe coding é magia. E a sua app, aguenta mesmo em produção?"
description: "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 na"
canonical_url: "https://pt.goodbarber.com/blog/o-vibe-coding-e-magia-na-demo-e-a-sua-app-aguenta-mesmo-em-producao-a1300/"
lang: pt
date: 2026-07-10
last_updated: 2026-09-01
---

# O vibe coding é magia. E a sua app, aguenta mesmo em produção?

[Voltar](/blog/make-it-r19/)

# O vibe coding é magia na demo. E a sua app, aguenta mesmo em produção?

Escrito por [Pierre-Laurent Medori](https://pt.goodbarber.com/blog/author/pierre-medori/)  na Sexta-Feira 10 Julho 2026· Última atualização: Terça-Feira 1 Setembro 2026

## As ferramentas prompt-to-app conseguem transformar uma ideia numa demo funcional antes de o café arrefecer — e essa euforia é real. Mas entre um protótipo feito em vibe coding e uma app que os seus utilizadores descarregam da App Store erguem-se sete muros bem concretos: propriedade, backend, autenticação, revisão das lojas, funcionalidades nativas, estabilidade do código e conformidade. Eis um mapa honesto desse fosso, desenhado do lado da produção — quinze anos a publicar apps nativas nas lojas — e a forma de manter a velocidade da IA sem cair do precipício.

## A euforia dos cinco minutos é real

![](https://cmsphoto.ww-cdn.com/superstatic/121801/art/grande/97296821-67778594.jpg?v=1783667596.469417)

A 2 de fevereiro de 2025, Andrej Karpathy [deu nome à coisa](https://x.com/karpathy/status/1886192184808149383): «Há um novo tipo de programação a que chamo "vibe coding": entregamo-nos por completo às vibes, abraçamos os exponenciais e esquecemos que o código sequer existe.» Nove meses depois, "vibe coding" era a [Palavra do Ano do Collins Dictionary](https://www.collinsdictionary.com/woty). Poucos termos tecnológicos viajaram tão depressa — porque poucas experiências tecnológicas são assim tão inebriantes.

Os números dizem o mesmo. A Lovable atingiu [100 milhões de dólares de receita anual recorrente oito meses após o lançamento](https://techcrunch.com/2025/07/23/eight-months-in-swedish-unicorn-lovable-crosses-the-100m-arr-milestone/), com mais de 10 milhões de projetos criados na plataforma. O Bolt.new chegou a [cerca de 40 milhões de dólares de ARR em aproximadamente cinco meses](https://www.growthunhinged.com/p/boltnew-growth-journey). O Replit [multiplicou a receita por dez em meio ano](https://x.com/amasad/status/1937221946976133188) depois de lançar o seu agente. Milhões de pessoas escreveram uma frase e viram software aparecer.

Nós compreendemos essa euforia. É a mesma que os nossos utilizadores sentem quando descrevem uma funcionalidade e a veem a funcionar na sua app. Ver a nossa ideia a funcionar — não em maquete, *a funcionar* — muda aquilo que acreditamos ser capazes de construir. Essa parte não merece ironia nenhuma.

Mas Karpathy deixou a ressalva no mesmíssimo post: o vibe coding «não é nada mau para projetos descartáveis de fim de semana». Quem o vive di-lo com menos diplomacia. Um criador no r/nocode intitulou o seu post [«Experimentei o Bolt.new. Senti-me um deus. Depois a realidade deu-me uma estalada.»](https://www.reddit.com/r/nocode/comments/1ii52d3/tried_boltnew_felt_like_a_god_then_reality/) e resumiu a manhã seguinte assim: «De repente, o sonho da "programação com IA" transformou-se em "ansiedade com IA".»

A demo não é uma mentira. O erro é lê-la como um produto acabado.

## Os sete muros entre um protótipo e as lojas

O vibe coding está pronto para produção? Para protótipos e ferramentas internas, sim — e de forma brilhante. Para uma app publicada nas lojas, com utilizadores reais e dados reais, não por si só. As verdadeiras limitações do vibe coding não estão no código que ele escreve; estão em tudo o que a produção exige à volta desse código.

A própria indústria no-code começou a dar nome à divisão. O [State of No-Code 2026](https://www.caspio.com/blog/state-of-no-code-2026/) da Caspio descreve uma IA a puxar o mercado em duas direções ao mesmo tempo e termina numa fórmula sem rodeios: «A divisão não é "IA boa vs. IA má". É **descartável vs. duradouro** (*disposable vs. durable*).»

Então, o que torna descartável um protótipo feito em vibe coding? Não é a demo — é tudo o que está à volta dela. Sete muros, todos invisíveis no ecrã do portátil, todos bem reais no dia em que tenta publicar. Três deles — o código nativo, a submissão às lojas e o ciclo de vida da app — são tão específicos do móvel que lhes dedicámos [uma análise completa](https://pt.goodbarber.com/blog/o-que-as-ferramentas-de-vibe-coding-se-esquecem-de-te-dizer-sobre-as-apps-moveis-a1279/); aqui, ocupam o seu lugar no quadro geral.

**Muro 1 — Alojamento e propriedade**

Para sermos justos com as ferramentas: em geral, o código é seu. A documentação do Lovable [di-lo explicitamente](https://docs.lovable.dev/tips-tricks/deployment-hosting-ownership), e pode exportar para o GitHub. O que não é seu é tudo aquilo de que o código precisa para correr. Por omissão, a sua app vive na cloud gerida do fornecedor — Lovable Cloud, [alojamento do Bolt](https://support.bolt.new/faqs/hosting), Vercel — com o backend, a base de dados e o pipeline de build operados por eles, aos preços deles, nos termos deles. Ser dono do código-fonte de uma app cuja infraestrutura pertence a outra pessoa é como ser dono da planta de uma casa construída em terreno arrendado. Produção significa que alguém responde por essa infraestrutura durante anos: disponibilidade, backups, renovações, faturas. Na demo, ninguém responde. Uma exportação leva consigo o código-fonte; o backend, o alojamento e a IA que o escreveu ficam para trás, e é por isso que [ser dono do código e conseguir sair são duas coisas diferentes](https://pt.goodbarber.com/blog/pode-ser-dono-da-sua-app-consegue-sair-do-seu-app-builder-com-ia-a1325/).

**Mutualização.** Uma plataforma SaaS opera uma única infraestrutura para todas as suas apps, mantida por uma equipa cujo trabalho a tempo inteiro é mantê-la de pé — e o custo está incluído na subscrição, em vez de ser descoberto mais tarde. Todas as apps que já publicámos correram nesse modelo desde o primeiro dia.

**Muro 2 — Backend e dados**

A camada de dados de um protótipo está otimizada para a demo: existe, responde, parece bem. Os dados de produção têm exigências mais duras — migrações, backups, ambientes que separam os testes da realidade. Em julho de 2025, essa lição fez manchetes quando o agente do Replit [apagou uma base de dados de produção](https://www.theregister.com/2025/07/21/replit_saastr_vibe_coding_incident/) durante um congelamento de código explícito, eliminando os registos de [mais de 1200 executivos](https://fortune.com/2025/07/23/ai-coding-tool-replit-wiped-database-called-it-a-catastrophic-failure/). O Replit reagiu anunciando a separação automática entre bases de dados de desenvolvimento e de produção — fechando uma lacuna que os sistemas de produção tratam como requisito de base.

E para lá da base de dados, a produção é onde vivem os problemas operacionais sem glamour. O email transacional é o clássico: um fundador de SaaS [relatou no r/SaaS](https://www.reddit.com/r/SaaS/comments/1k189yz/avoid_sendgrid_for_small_saas/) «frequentemente menos de 50% de taxa de entrega» em infraestrutura de email partilhada. Não há prompt que resolva a entregabilidade.

**Um backend que já existia antes da sua app.** Numa plataforma gerida, a camada de dados — migrações, backups, a separação entre testes e produção — foi construída uma vez, por profissionais, e é posta à prova todos os dias por todas as apps que nela correm; só o nosso módulo de e-commerce corre em produção para milhares de comerciantes. A canalização sem glamour é o trabalho diário de uma equipa de plataforma, não a descoberta que faz à terceira semana.

**Muro 3 — Autenticação e segurança**

Este é o muro mais bem documentado, porque os investigadores não param de o medir. O estudo de 2025 da Veracode, com mais de 100 modelos, concluiu que o código gerado por IA introduzia vulnerabilidades do OWASP Top 10 em [45% das tarefas testadas](https://www.businesswire.com/news/home/20250730694951/en/AI-Generated-Code-Poses-Major-Security-Risks-in-Nearly-Half-of-All-Development-Tasks-Veracode-Research-Reveals). Um [benchmark académico](https://arxiv.org/abs/2512.03262) publicado em dezembro de 2025 mediu o fosso na sua forma mais crua: o melhor agente produzia soluções funcionalmente corretas 61% das vezes, mas apenas 10,5% dessas soluções eram seguras. E em 2025 foi registado um CVE a documentar a ausência de Row-Level Security em apps geradas pelo Lovable — o investigador de segurança Matt Palmer [analisou 1645 dessas apps e encontrou 170 a expor dados](https://mattpalmer.io/posts/2025/05/statement-on-CVE-2025-48757/), incluindo chaves de API e detalhes financeiros. Quando a Escape.tech [analisou mais de 5600 apps ativas criadas por vibe coding](https://escape.tech/blog/methodology-how-we-discovered-vulnerabilities-apps-built-with-vibe-coding/) em outubro de 2025, encontrou mais de 2000 vulnerabilidades e mais de 400 segredos expostos.

Nada disto significa que os modelos sejam maus. Significa que a revisão de segurança é uma exigência de produção pela qual um protótipo, por definição, nunca passou.

**Segurança escrita uma vez, herdada por todos.** A autenticação de uma plataforma é um único código, endurecido por anos de tráfego real; quando algo precisa de correção, essa correção escreve-se uma vez — entra imediatamente em produção do lado do servidor e segue para a próxima build de todas as apps. É essa a diferença estrutural entre um login mantido por engenheiros e milhares de logins gerados, cada um a reinventar sozinho as suas próprias regras de acesso.

**Muro 4 — Submissão às lojas**

Eis o facto que a maioria dos tutoriais de vibe coding salta: **a maior parte das ferramentas prompt-to-app constrói aplicações web, não apps móveis**. O próprio FAQ do Lovable [di-lo sem rodeios](https://docs.lovable.dev/introduction/faq): «Não, o Lovable está focado em aplicações web.» O v0 [gera código web publicado na Vercel](https://vercel.com/blog/maximizing-outputs-with-v0-from-ui-generation-to-code-creation). O Bolt é a exceção parcial — a sua [integração com o Expo](https://expo.dev/blog/bolt-expo-integration-announcement) gera código React Native verdadeiro —, mas as builds dos binários, as contas de programador e a revisão da Apple continuam a ser inteiramente problema seu.

A solução alternativa habitualmente sugerida — embrulhar a app web num invólucro nativo — esbarra na [Guideline 4.2](https://developer.apple.com/app-store/review/guidelines/) da Apple: «A sua app deve incluir funcionalidades, conteúdo e uma interface que a elevem para lá de um site reempacotado.» Na experiência da nossa equipa de publicação, os revisores testam por hábito as apps offline; um wrapper que mostra um ecrã em branco diz-lhes tudo. E a revisão é implacável mesmo para apps a sério: a Apple rejeita cerca de 42% das primeiras submissões (linha de base da Apple, medida nas apps que a nossa equipa de publicação submeteu nos últimos 12 meses). Escrevemos um guia sobre [as razões pelas quais a Apple rejeita apps e como recuperar](https://pt.goodbarber.com/blog/reasons-why-your-app-could-be-rejected-by-apple-and-how-to-make-a-comeback-a545/).

**A submissão como processo industrial.** Uma plataforma compila binários desenhados para passar a revisão, e quando a Apple ou a Google sobem a fasquia — novas etiquetas de privacidade, novos prazos de SDK, novas verificações de completude — atualiza uma vez, e todas as apps que publica herdam a correção. Quinze anos de submissões às lojas são uma forma de capital que nenhum prompt consegue gerar.

**Muro 5 — Funcionalidades nativas do dispositivo**

As funcionalidades que fazem uma app móvel valer mais do que um site são precisamente aquelas com que uma app web embrulhada se atrapalha. As notificações push são o exemplo mais flagrante: no iOS, o push web [só funciona em apps web instaladas manualmente no ecrã principal](https://webkit.org/blog/13878/web-push-for-web-apps-on-ios-and-ipados/) — nunca no navegador. Câmara, modo offline, biometria: cada uma exige plugins nativos adicionados, configurados e mantidos à mão, fora de tudo o que a IA gerou. Uma demo web "otimizada para móvel" e uma app nativa são espécies diferentes com a mesma cara.

**Nativo por construção.** Numa plataforma que compila Swift e Kotlin verdadeiros, push, câmara, offline e haptics são componentes pré-construídos, mantidos a cada versão do iOS e do Android — a camada que faz uma app parecer profissional é o ponto de partida, não um acrescento tardio.

**Muro 6 — Regeneration drift: o código que se reescreve sozinho**

Chamemos-lhe **regeneration drift** — a deriva da regeneração: cada novo prompt regenera o código contra um contexto ligeiramente diferente, e a correção de ontem pode desaparecer discretamente na geração de hoje. Addy Osmani, engineering lead do Google Chrome, [deu nome ao padrão](https://addyo.substack.com/p/the-70-problem-hard-truths-about) — «dois passos atrás»: «Tentamos corrigir um pequeno bug… A IA sugere uma alteração que parece razoável… Essa correção parte outra coisa.» Os dados confirmam: a [análise de 211 milhões de linhas de código alteradas](https://www.gitclear.com/ai_assistant_code_quality_2025_research) da GitClear encontrou blocos de cinco ou mais linhas duplicadas multiplicados por 8 em 2024, e a fatia de código revista nas duas semanas a seguir a ser escrita quase duplicou desde 2020. Um código que não fica quieto é um código sobre o qual não se pode prometer nada — muito menos a um utilizador que encontrou um bug.

**Alicerces que não se mexem.** Numa plataforma, a IA gera apenas a fina camada personalizada por cima de um substrato versionado e testado — autenticação, checkout, CMS e sistema de design fazem parte do substrato que nenhum prompt regenera. A deriva fica confinada a essa camada fina em vez de tomar a app inteira: o checkout de que depende não pode reescrever-se sozinho, em silêncio.

**Muro 7 — Privacidade e conformidade**

Uma app publicada carrega obrigações legais que uma demo nunca cumpre. As etiquetas de privacidade da Apple e o formulário de segurança dos dados do Google Play exigem que declare que dados recolhe, para onde vão e quem os trata — perguntas a que uma stack feita em vibe coding muitas vezes não sabe responder, porque algures um valor por omissão colocou os dados dos seus utilizadores numa infraestrutura que nunca escolheu. O RGPD sobe ainda mais a fasquia: consentimento específico e não agregado, residência de dados que consiga realmente indicar, uma lista de subcontratantes que realmente conheça. Nada disto aparece numa demo. Tudo isto aparece numa revisão de loja — ou, pior, numa queixa.

**Conformidade tratada uma vez, a montante.** Um único esforço jurídico e de engenharia ao nível da plataforma — no nosso caso, todos os dados alojados na Europa, gestão de consentimento integrada, deteção automática das permissões que cada funcionalidade exige — serve todas as apps e mantém-se atual à medida que as regras evoluem. Os nossos motores de compilação vão um passo mais longe: uma biblioteca só entra no binário se a funcionalidade que a usa estiver ativada, por isso as apps não se limitam a *declarar* menos — *contêm* menos.

**Os sete muros do vibe coding — resumo**

| Muro                     | Por omissão no protótipo         | Exigência de produção                                                         | Como a plataforma o absorve                                  |
| ------------------------ | -------------------------------- | ----------------------------------------------------------------------------- | ------------------------------------------------------------ |
| Alojamento e propriedade | Uma app na cloud do fornecedor   | Infraestrutura que alguém detém, opera e paga durante anos                    | Uma infraestrutura mutualizada, operada pela plataforma      |
| Backend e dados          | Dados que aparecem no ecrã       | Migrações, backups, separação dev/prod, email que chega                       | Backend pré-construído, posto à prova diariamente            |
| Autenticação e segurança | Um ecrã de login                 | Regras de acesso revistas e testadas                                          | Autenticação escrita uma vez; um patch cobre todas           |
| Submissão às lojas       | Um URL web                       | Um binário nativo assinado que sobrevive à revisão da Apple                   | Binários prontos para revisão; mudanças de regras absorvidas |
| Funcionalidades nativas  | Um layout com ar de móvel        | Push, câmara, offline — integração real com o SO                              | Componentes nativos acompanhados a cada versão do SO         |
| Estabilidade do código   | A build que funciona esta semana | Um código onde a correção do mês passado ainda lá está                        | A IA só toca na camada personalizada                         |
| Conformidade             | Nada                             | Consentimento à altura do RGPD, etiquetas de privacidade, residência de dados | Alojamento na UE + consentimento, tratados uma vez           |

[O que é um aplicativo nativo?](https://pt.goodbarber.com/glossary/native-app/)

## A checklist de produção: a sua app está pronta para ser publicada?

Sete muros, sete perguntas. As respostas de plataforma acima são as nossas; estas perguntas são as suas. Responda-lhes a propósito do seu protótipo:

1. **Quem opera a infraestrutura em que ela corre — e continuará a operá-la daqui a dois anos?**
2. **Onde vivem os dados, e o que acontece quando o esquema tiver de mudar?**
3. **Alguém que saiba ler código reviu a autenticação e as regras de acesso?**
4. **Consegue produzir um binário iOS e Android assinado que passe a revisão das lojas?**
5. **Consegue enviar uma notificação push para um telemóvel bloqueado?**
6. **Consegue corrigir um bug daqui a seis meses sem regenerar — e voltar a partir — tudo o resto?**
7. **O fluxo de consentimento e o tratamento de dados sobreviveriam a uma queixa ao abrigo do RGPD?**

Três ou mais respostas «não» (ou «não sei»), e o que tem em mãos é um protótipo. Isso não é um fracasso — um protótipo é uma coisa genuinamente útil. Valida uma ideia numa tarde, por quase nada. O fracasso está apenas na confusão: planear um lançamento, uma base de utilizadores e um negócio sobre algo construído para ser descartável.

## A velocidade da IA sem o precipício

A conclusão não é «evite a IA». Usamos geração de código por IA todos os dias nas nossas próprias equipas de engenharia — o nosso CMO [já o dizia](https://pt.goodbarber.com/blog/entrevista-vibe-coding-visto-pela-goodbarber-a1205/) em abril de 2025, com a ressalva que a indústria entretanto confirmou: «Sem conhecimentos de programação, é fácil ficar rapidamente sobrecarregado ou bloqueado, porque a IA pode criar incoerências significativas se for usada sem supervisão humana especializada.»

A conclusão é apontar a velocidade da IA a uma fundação que chega às lojas. É essa toda a lógica do [AI Extension Builder](https://pt.goodbarber.com/blog/ai-extension-builder-crie-secoes-com-ia-sem-programar-a1242/) (atualmente em Beta, disponível para todos os clientes), a resposta da GoodBarber à pergunta prompt-to-app: descreve uma funcionalidade em linguagem corrente, um agente de IA constrói-a — mas constrói-a *dentro* de uma plataforma, sobre APIs documentadas, e o resultado herda tudo aquilo que falta a um protótipo. O design segue automaticamente o sistema de design da sua app. A secção é publicada sob a forma de binários Swift e Kotlin genuínos, através do mesmo pipeline de lojas que operamos desde 2011 — com uma equipa de publicação que recupera 91% das primeiras rejeições da Apple quando elas acontecem (últimos 12 meses).

Os muros 2 e 3 — backend e segurança — recebem o mesmo tratamento. Quando uma secção construída pela IA precisa de guardar dados, a [integração com o Supabase](https://pt.goodbarber.com/blog/ai-extension-builder-ligue-o-supabase-a-sua-app-a1296/) cria a estrutura da base de dados por si, no seu próprio projeto Supabase, em infraestrutura que controla — e cada tabela sai com políticas de Row-Level Security ativadas por omissão. É exatamente o modo de falha documentado no CVE do Lovable, resolvido antes sequer de saber que devia perguntar por ele. E o núcleo da plataforma — alojamento, base de dados, notificações push, analytics e pagamentos — está incluído numa única subscrição, pelo que não há uma pilha de serviços de terceiros para montar, proteger e pagar em separado. Custo total de propriedade: cerca de um décimo do desenvolvimento à medida.

Há limites, claro. A GoodBarber foi construída para apps de conteúdo e comércio móvel; um jogo ou um marketplace fortemente personalizado caem fora desse âmbito, e para esses projetos o caminho mais natural é entregar o protótipo feito em vibe coding a uma equipa de desenvolvimento. Dentro desse âmbito, porém, a abordagem de plataforma é o que transforma a velocidade da IA numa app que consegue publicar — e manter a funcionar ao longo do tempo.

**O próximo passo, em concreto:** [comece um teste gratuito](https://pt.goodbarber.com), abra uma secção "Create with AI" e descreva a funcionalidade que fez em vibe coding no fim de semana passado. Os mesmos cinco minutos. Desta vez, o resultado tem um pipeline de lojas por trás.

## FAQ

**É possível publicar uma app feita em vibe coding na App Store?**

Não diretamente, na maioria dos casos. O Lovable e o v0 produzem aplicações web — não há binário iOS ou Android para submeter. Embrulhar a app web num invólucro nativo é possível, mas a Guideline 4.2 da Apple rejeita apps que se resumem a «um site reempacotado». O Bolt consegue gerar código React Native via Expo, mas as builds, as contas de programador e a revisão das lojas ficam por sua conta. Os caminhos fiáveis são: contratar programadores para levar o código até produção, ou reconstruir numa plataforma que compila binários nativos e trata da submissão. Para a análise completa do lado móvel, veja [o que as ferramentas de vibe coding se esquecem de lhe contar sobre apps móveis](https://pt.goodbarber.com/blog/o-que-as-ferramentas-de-vibe-coding-se-esquecem-de-te-dizer-sobre-as-apps-moveis-a1279/).

**O vibe coding está pronto para produção?**

Para protótipos, ferramentas internas e projetos de fim de semana — sim, e é excelente nisso. Para apps de produção com utilizadores reais, a resposta ponderada é: não sem revisão de engenharia. O código gerado por IA introduz vulnerabilidades de segurança em 45% das tarefas testadas (Veracode, 2025), e um benchmark académico concluiu que as soluções do seu melhor agente eram funcionalmente corretas 61% das vezes, mas seguras apenas 10,5% das vezes (arXiv, dezembro de 2025). Estar pronto para produção não é uma questão de o código correr — é alojamento, dados, revisão de segurança, submissão às lojas, funcionalidades nativas, estabilidade do código e conformidade: os sete muros do vibe coding.

**O que é o regeneration drift no vibe coding?**

O regeneration drift — a deriva da regeneração — é o que acontece quando cada novo prompt regenera o código contra um contexto ligeiramente diferente, e a correção de ontem pode desaparecer discretamente na geração de hoje. Addy Osmani chama ao ciclo resultante o padrão dos «dois passos atrás»; a análise da GitClear a 211 milhões de linhas de código alteradas mediu a sua pegada — blocos de código duplicado multiplicados por 8 em 2024. É a principal razão pela qual uma app feita em vibe coding se torna mais difícil de manter quanto mais prompts recebe.

**A Apple baniu as apps de vibe coding?**

Não — e a distinção importa. Em março de 2026, a Apple [bloqueou atualizações às apps das *plataformas* de vibe coding](https://www.macrumors.com/2026/03/18/apple-blocks-updates-for-vibe-coding-apps/) como o Replit e o Vibecode, ao abrigo da Guideline 2.5.2, que proíbe apps que descarregam e executam código. Isso visa as ferramentas enquanto apps iOS, não as apps construídas com IA. A Apple disse ao MacRumors que não tem regras específicas contra apps de vibe coding. Uma app individual construída com IA enfrenta a fasquia habitual: funcionalidade mínima (4.2), spam (4.3) e completude — a mesma revisão que todas as apps enfrentam.

**Quando é que se deve trocar um protótipo de vibe coding por um app builder?**

No momento em que o protótipo tem de se tornar a ferramenta diária de alguém: utilizadores reais, presença nas lojas, atualizações, um backend que persiste. É um limiar de responsabilidade, não de competência — no dia em que outras pessoas dependem da app, alguém tem de responder pelos seus sete muros. Guarde o protótipo; ele cumpriu a missão de validar a ideia. Depois reconstrua-o onde esses muros já são o trabalho de outra pessoa — binários nativos, submissão às lojas, alojamento e manutenção incluídos. Como [disse o nosso CMO](https://pt.goodbarber.com/blog/entrevista-vibe-coding-visto-pela-goodbarber-a1205/), o vibe coding serve um público especializado; um app builder é feito para toda a gente.

**Quanto custa, afinal, publicar nas lojas?**

Uma conta Apple Developer custa $99/ano; uma conta de programador do Google Play é um pagamento único de $25. Depois vem o custo real: preparar as builds, as capturas de ecrã e as declarações de privacidade — e sobreviver à revisão: a Apple rejeita cerca de 42% das primeiras submissões (linha de base da Apple, medida nas apps que a nossa equipa de publicação submeteu nos últimos 12 meses). O nosso [guia de publicação passo a passo](https://pt.goodbarber.com/blog/how-to-publish-your-app-on-google-play-and-the-app-store-a107/) cobre o processo, e o nosso [serviço de publicação](https://pt.goodbarber.com/app-publishing-service/) trata dele por si.

Antes de apostar num plano gratuito para começar, veja [o que os criadores de apps gratuitos realmente incluem](https://pt.goodbarber.com/blog/e-mesmo-possivel-criar-um-aplicativo-gratis-o-que-os-criadores-de-apps-gratuitos-realmente-incluem-a1339/) e onde todos eles param.

![PIERRE MEDORI](https://blog.goodbarber.com/_public/profile/b5/b5f3704c4117b921f2e8146eddf0b0763b3e1692-default.jpg)

Sobre o autor[PIERRE MEDORI](https://pt.goodbarber.com/blog/author/pierre-medori/)Head of Backend Engineering

Sou Head of Backend Engineering na GoodBarber, onde construímos a plataforma que permite a qualquer pessoa criar aplicações nativas sem escrever uma linha de código. A minha equipa é responsável por tudo o que acontece nos bastidores — as APIs, os serviços e a infraestrutura que transformam um projeto no-code em aplicações realmente publicadas, com alojamento, notificações push e uma loja completa. Escrevo sobre a engenharia que mantém o no-code a funcionar em grande escala e sobre o papel que a IA desempenha nisso.

[Saiba mais](https://pt.goodbarber.com/blog/author/pierre-medori/)

[![LinkedIn](https://portal.ww-cdn.com/portal_static/svg/base2021/linkedin.3ed8162e2a2b.svg)](https://www.linkedin.com/in/pierre-laurent-medori/)