Quanto tempo leva para fazer um aplicativo, de verdade

Quase toda proposta de aplicativo erra o prazo, e quase sempre pelo mesmo motivo: ela cronometra a programação e esquece de tudo que vem em volta.

Programar é a parte previsível. O que estoura prazo são as etapas que não dependem só de quem constrói: a fila da Apple, o retorno do cliente, o acesso a um sistema de terceiro, a conta de desenvolvedor que ninguém abriu.

Aqui está o cronograma inteiro, com o que costuma dar errado em cada etapa.

Etapa 1 · Definir o que o app faz

Onde trava: aqui, quase sempre.

Não é desenho de tela, é decisão: o que entra na primeira versão e o que fica para depois. A lista de desejos inicial sempre cabe num app três vezes maior que o orçamento.

A pergunta que resolve é ingrata e eficaz: se o app fizesse uma coisa só, qual seria? Essa coisa é a primeira versão. O resto é a segunda.

Pular esta etapa não economiza tempo, apenas empurra a discussão para o meio do desenvolvimento, quando mudar custa muito mais caro.

Etapa 2 · Desenhar as telas

Aqui se decide não só a aparência, mas o caminho: quantos toques até a ação principal, o que acontece quando dá erro, como fica sem internet.

Onde trava: rodada de revisão sem fim. Combine quantas rodadas estão previstas, por escrito. “Ajustes até aprovar” é uma data em aberto.

Etapa 3 · Construir

A parte mais longa, e a mais previsível. Roda em ciclos, com pedaço funcionando para você ver e opinar, não meses de silêncio seguidos de uma entrega única.

Onde trava: integração com sistema de terceiro. Se o app precisa conversar com o seu ERP, com um meio de pagamento ou com uma transportadora, o prazo passa a depender da documentação e do suporte deles, não de quem programa. É a principal fonte de atraso, e precisa entrar no plano como risco desde o começo.

Etapa 4 · Testar em aparelho de verdade

Emulador não é telefone. Aparelho Android antigo, iPhone com tela pequena, internet ruim, bateria em economia. É onde aparece o que nenhum teste de mesa pega.

Onde trava: subestimar esta etapa. Ela sempre acha coisa, e o cronograma precisa ter espaço para corrigir o que ela achar.

Etapa 5 · Publicar nas lojas

E aqui está a etapa que some das propostas.

Antes de submeter, você precisa ter:

• Conta de desenvolvedor Apple (paga, anual) e Google Play (paga, uma vez)
• Política de privacidade publicada numa URL acessível
• Ícones, capturas e descrição em todos os tamanhos pedidos
• Declaração de quais dados o app coleta e para quê
• Uma conta de teste funcionando, para o revisor entrar e usar

Onde trava: a conta de desenvolvedor. Abrir uma conta de empresa na Apple exige verificação que pode levar dias ou semanas, e não adianta correr depois: precisa começar no início do projeto, não no fim.

Prepare a conta de desenvolvedor na primeira semana, não na última. É a única etapa do projeto que não acelera com esforço.

A revisão, e a rejeição que você deve prever

O Google costuma aprovar rápido. A Apple é mais rigorosa, e a revisão em si leva de um a poucos dias, quando passa de primeira.

Os motivos mais comuns de rejeição:

• Uso de dado pessoal sem explicar direito para que serve
• Qualquer coisa que a Apple interprete como pagamento fora do sistema dela
• Faltou conta de teste, ou a que veio não funcionou
• App que a revisão considera “pouco funcional” perto de um site

Cada rejeição volta para o fim da fila. Um cronograma honesto prevê pelo menos uma. Não porque o trabalho foi malfeito, mas porque as regras são interpretadas por pessoas.

Etapa 6 · Acompanhar depois de lançar

O app entrou no ar. Agora aparecem os travamentos em aparelhos que ninguém testou, e os primeiros usuários reais usando de um jeito que ninguém previu.

As duas semanas seguintes ao lançamento são de ajuste, e precisam estar combinadas, senão viram discussão sobre quem paga.

O que realmente encurta o prazo

Nenhum destes é atalho técnico. Todos dependem de decisão sua:

1. Escopo menor na primeira versão. É a única alavanca que funciona sempre.
2. Uma pessoa que decide. Decisão por comitê dobra o tempo de cada rodada.
3. Acesso às integrações desde o dia 1. Peça credencial de teste antes de precisar dela.
4. Contas de desenvolvedor abertas na primeira semana.
5. Rodadas de revisão combinadas por escrito.

O que não encurta

Colocar mais gente no meio do projeto. Quem entra precisa entender o que já existe, e quem explica para de produzir. Perto do fim, isso atrasa em vez de acelerar.

E a escolha entre React Native, Flutter ou nativo muda menos o prazo do que as pessoas imaginam. Cross-platform entrega antes na maioria dos casos porque um código serve as duas lojas; nativo compensa quando o app depende de recurso pesado do aparelho. A decisão deve sair do seu caso, não do que está na moda, e essa conversa vale uma reunião no começo, não uma discussão no meio.