Quanto tempo leva para lançar um aplicativo — e as semanas que ninguém põe no cronograma

Toda estimativa que você vai ler segue o mesmo formato: app simples de 6 a 10 semanas, MVP de 12 a 16, produto completo de 16 a 24, projeto complexo de 24 a 40. Os números não estão errados. O problema é o que eles medem.

Eles medem construção: descoberta, design, código, teste. Tudo isso está sob controle de quem você contratou, e por isso é a parte fácil de estimar. O que fica de fora é a parte que depende de terceiros — a Apple, o Google, um banco, a sua própria área jurídica — e que não anda mais rápido porque o projeto está atrasado.

Em aplicativo, essa parte é maior do que parece. E ela é específica de mobile: quem faz site publica quando quer. Você não. Entre o aplicativo estar pronto e ele existir na loja há um intermediário que precisa aprovar, e que pode dizer não.

A conta de desenvolvedor vem primeiro. Publicar como empresa exige o cadastro da pessoa jurídica na Apple e no Google, e no caso da Apple isso passa por um número D-U-N-S vinculado ao CNPJ. Se a empresa nunca teve um, a emissão leva dias, às vezes semanas, e nada acontece em paralelo — sem conta aprovada não existe nem onde subir a primeira versão de teste.

Depois vêm os acordos. Para cobrar qualquer coisa dentro do app é preciso ter o contrato de aplicativos pagos aceito e os dados bancários e fiscais completos, com o titular da conta assinando. É um formulário, mas é um formulário que trava a funcionalidade inteira de assinatura até estar em ordem — e costuma parar numa assinatura que precisa de alguém que está de férias.

E há as permissões especiais. Certas capacidades do iOS não são liberadas marcando uma caixa: você pede, justifica e espera a Apple conceder. Num dos nossos projetos, a permissão para usar as APIs de Tempo de Uso foi concedida para o aplicativo — e descobrimos que a extensão que executa o bloqueio, por ter identificador próprio, precisava de uma segunda solicitação para o mesmo direito. Duas idas, duas esperas, para uma função que era o motivo de o produto existir.

Todo cronograma trata a revisão como uma caixa de um a sete dias no fim. Ela é isso quando passa de primeira. Quando não passa, vira um ciclo: recusa, correção, reenvio, nova fila.

Num lançamento nosso, a recusa veio com três apontamentos de uma vez. O primeiro era de metadados — o texto da ficha na loja precisava ser reescrito, incluindo nome, subtítulo e palavras-chave. O segundo era da classificação etária, que exigiu refazer o questionário e reenviar. O terceiro era o mais incômodo: uma falha de compra que o revisor viu num iPad específico, com uma versão específica do sistema, e que não reproduzia do nosso lado.

Esse terceiro caso é o que mais custa calendário, porque não se corrige um bug que não se reproduz. O que se faz é eliminar as causas possíveis uma a uma — verificar os contratos, o estado de cada produto de assinatura, o ambiente de testes — e escrever para o revisor um roteiro de reprodução passo a passo, com conta de demonstração, para que a próxima tentativa não dependa de sorte.

Cada volta dessas custa dias, não horas. Duas voltas e você perdeu duas semanas sem ter escrito uma linha de funcionalidade nova.

Todo texto sobre prazo cita mudança de escopo como principal causa de atraso, e para por aí, como se fosse um fenômeno climático. Não é. É um procedimento que existe ou não existe.

Escopo muda em praticamente todo projeto e isso é saudável — significa que alguém aprendeu algo. O que produz atraso não é a mudança: é a mudança absorvida em silêncio. Quando um pedido novo entra sem ser reorçado e sem recalcular a data, o cronograma continua dizendo a mesma coisa enquanto o trabalho cresce, e o atraso só aparece no fim, todo de uma vez.

Por isso a pergunta a fazer no início não é “qual é o prazo”, e sim “o que acontece com o prazo quando eu pedir uma mudança”. Um fornecedor que responde “a gente encaixa” está prometendo o atraso que ainda não aconteceu.

Para um produto enxuto, feito para validar uma ideia: de duas a quatro semanas de descoberta e escopo, de três a cinco de design, de seis a dez de construção — com design e código se sobrepondo em parte — e de uma a duas semanas para publicação, contando a revisão. Do primeiro contato à loja, algo entre dois e três meses e meio quando as contas já existem.

Para um produto completo, com backend próprio, contas de usuário, assinatura e integrações: de três a seis meses, pela mesma lógica, com a diferença de que a publicação tende a ser mais complicada porque há mais superfície para a loja questionar — cobrança, dados pessoais, permissões.

Some a isso, uma vez só e no começo, o tempo das contas de desenvolvedor, se a empresa ainda não as tiver. É o item que mais frequentemente empurra uma data de lançamento e o mais fácil de resolver com antecedência, porque não depende do projeto: dá para começar hoje, antes mesmo de o escopo estar fechado.

Três coisas encurtam prazo de verdade. A primeira é reduzir a primeira versão — é a única alavanca que funciona sempre, e quase todo escopo inicial tem funcionalidade que pode esperar sem prejuízo.

A segunda é resolver as dependências externas em paralelo, no início: abrir as contas, aceitar os acordos, reunir os textos legais, pedir as permissões especiais. Nada disso depende do aplicativo estar pronto, e tudo isso trava o lançamento se ficar para o fim.

A terceira é decidir rápido. O prazo de um projeto é feito de tempo de trabalho mais tempo de espera por decisão, e a segunda parcela costuma ser maior do que o cliente imagina. Uma aprovação que leva cinco dias úteis, três vezes ao longo do projeto, são três semanas que ninguém colocou na conta.

O que não encurta prazo é aumentar a equipe no meio. Colocar mais gente num projeto atrasado é a forma mais confiável de atrasá-lo mais, porque quem chega precisa ser explicado por quem já estava — e quem explica para de construir.