Quanto tempo leva para desenvolver um app? Uma resposta real

As faixas honestas, os quatro fatores que de fato mexem no número e como um founder não-técnico pode ler a estimativa de um desenvolvedor sem se enganar.

Uma founder com quem trabalhamos no ano passado já tinha dito ao investidor-líder que o app ficaria pronto em oito semanas. Ela tirou o número de um freelancer que bateu o olho numa descrição de um parágrafo e disse “ah, uns dois meses”. Quatro meses depois, ela ainda estava no desenvolvimento, o investidor fazia perguntas afiadas em toda call, e ela estava convencida de que o time era lento. O time não era lento. A estimativa era ficção, e ela tinha repetido essa ficção para a única pessoa de quem mais precisava manter a confiança.

Então: quanto tempo leva para desenvolver um app? Para a maioria dos produtos em estágio inicial, uma primeira versão confiável leva de três a seis meses, partindo de um escopo claro até algo que um cliente pagante consegue usar. Uma ferramenta interna pequena fica pronta em quatro a oito semanas. Um produto transacional ou regulado (pagamentos, dados de saúde, qualquer coisa com compliance) leva seis a nove meses ou mais. Essas faixas pressupõem um time focado, um escopo definido e um founder que decide rápido. Mude qualquer uma dessas variáveis e o número se mexe, às vezes muito.

Essa é a resposta. O resto deste artigo é sobre por que as faixas são tão amplas e como saber se o número específico que acabaram de te passar é real.

“Quanto tempo” é a primeira pergunta errada

Quando um founder pergunta quanto tempo leva um app, ele geralmente quer dizer uma de três coisas diferentes, e a resposta muda para cada uma.

Existe o demo: algo que você coloca numa tela durante um pitch, navega por cima e usa para contar uma história. Existe a primeira versão real: algo que um cliente pagante usa de verdade, com dados reais, casos de borda reais e as partes chatas que tornam o software confiável (autenticação, tratamento de erro, um jeito de consertar quando quebra). E existe a visão inteira: o produto como você descreveu no quadro branco, com todas as funcionalidades.

Esses não são o mesmo projeto, e não estão no mesmo prazo. O demo pode levar duas semanas. A primeira versão real é o número de três a seis meses lá de cima. A visão inteira costuma levar um ano ou mais, e você quase nunca quer construir tudo de uma vez, porque o mercado vai te ensinar que metade dela está errada.

O erro mais caro que vemos é o founder citar o prazo do demo para o board enquanto espera que a primeira versão real apareça. Então, antes de perguntar quanto tempo, decida qual das três você está de fato tentando entregar, para quando e por que essa data importa. “Quanto tempo até o quê” é a pergunta que te dá uma resposta útil.

O que de fato mexe no número

Dois apps que parecem idênticos numa frase podem estar a três meses de distância na prática. Quatro fatores explicam a maior parte dessa diferença.

Clareza de escopo. A maior variável não é o tamanho do app. É o quão claramente ele está definido. Um produto bem escopado, com um documento de requisitos do qual um estúdio consegue cotar, é construído mais rápido do que um vago “tipo o Airbnb, mas para X”, porque o time não fica refazendo a mesma tela três vezes enquanto você descobre o que quis dizer. Ambiguidade não aparece como item de orçamento. Aparece como semanas.

Integrações. Toda vez que seu app precisa conversar com algo que você não controla (um meio de pagamento, um banco, um ERP, uma API do governo, um serviço terceiro instável), você adicionou um risco que não dá para estimar bem de antemão. Uma integração tudo bem. Cinco integrações, cada uma com sua própria qualidade de documentação e seus limites de requisição, é onde os prazos dobram em silêncio. Já vimos uma funcionalidade de duas semanas virar seis porque uma API externa se comportou de um jeito totalmente diferente do que a documentação prometia.

Dados e compliance. Um app que guarda nomes e e-mails é uma coisa. Um app que lida com dinheiro, prontuários ou qualquer coisa que um regulador se importe é outra. Trabalho de compliance é engenharia de verdade, não papelada que você acrescenta no fim, e não comprime. Se você está em fintech ou healthtech, coloque os meses extras no plano desde o primeiro dia.

Formato do time. Um time focado que já construiu sistemas parecidos anda mais rápido do que um time maior se montando pela primeira vez. Mais gente não significa mais velocidade. Passado um número pequeno, o custo de coordenação come o ganho. É por isso que um parceiro capaz que já entregou o mesmo padrão antes muitas vezes ganha de contratar quatro engenheiros que depois passam os dois primeiros meses aprendendo a trabalhar juntos.

As três coisas que estouram o prazo em silêncio

Founders esperam que os prazos atrasem por “complexidade técnica”. Na prática, o que destrói as estimativas raramente é técnico. São decisões.

A primeira é escopo indefinido disfarçado de spec pronta. Um documento que diz “usuário pode gerenciar seu perfil” parece completo até o desenvolvimento começar e o time descobrir que ninguém decidiu o que é editável, o que acontece com os dados antigos ou se um admin também pode fazer isso. Cada um desses é uma pergunta, e cada pergunta que fica esperando resposta é uma tarefa parada. Uma fase de discovery de verdade antecipa essas perguntas para que não apareçam no meio do desenvolvimento.

A segunda é roleta de integração. Você não tem como saber quanto tempo leva integrar com um sistema até estar dentro dele. Times bons reduzem esse risco encostando em cada dependência externa nas duas primeiras semanas, não nas duas últimas. Se o seu time nem olhou a API da qual depende até a terceira semana, seu prazo já está em risco e ninguém te contou ainda.

A terceira, e a que os próprios founders causam, é o imposto da lentidão de decisão. Software é construído na velocidade da pessoa mais lenta para decidir, e num projeto pequeno essa pessoa costuma ser você. Cada “deixa eu pensar” numa escolha de design, cada mensagem no Slack sem resposta sobre como um fluxo deveria funcionar, é alguém parado ou, pior, construindo a coisa errada. Já vimos um projeto de três meses virar quatro porque a founder estava viajando e as perguntas se acumularam. O código nunca foi o gargalo.

Uma faixa realista por tipo de projeto

Aqui está o mapa aproximado que damos aos founders antes de qualquer escopo detalhado. Trate como âncora de partida, não como promessa. A estimativa detalhada vem do escopo.

Repare: a coisa mais barata de subestimar é o meio chato, a primeira versão real. O founder precifica mentalmente o demo e aí leva um susto quando o trabalho de qualidade de produção custa mais. Custa mais porque “funciona no demo” e “funciona quando um cliente real bate às 23h com um input ruim” são problemas de engenharia diferentes. Para o lado financeiro da mesma decisão, veja quanto custa construir o mesmo app, porque tempo e dinheiro andam juntos, mas não em sincronia perfeita.

Como ler uma estimativa que te entregaram

Quando alguém te dá um prazo, você não está avaliando se a pessoa é inteligente. Está avaliando se o número está apoiado em alguma coisa. Três testes rápidos.

Pergunte no que ele se baseia. Uma estimativa confiável faz referência a um escopo: “dadas essas telas e essa integração, seis a oito semanas”. Uma não confiável não faz referência a nada: “uns dois meses”. Steve McConnell, que escreveu mais sobre estimativa de software do que quase qualquer um, descreve a incerteza inicial como um cone que estreita só conforme o escopo se define. No começo, uma estimativa séria pode errar por um fator de quatro para mais ou para menos, e só aperta conforme o trabalho fica concreto. Um número dado antes de o escopo existir é um chute de gravata.

Peça uma faixa, não uma data. Estimativas reais têm margem de erro no início, e ela aperta conforme o trabalho é definido. Um time que te dá uma única data confiante para um projeto indefinido é inexperiente ou está te gerenciando. “Seis a oito semanas, e saberemos qual depois das duas primeiras” é o formato de uma resposta honesta.

Pergunte o que faria demorar mais. A resposta te diz se eles de fato pensaram no seu projeto. Um time bom vai te devolver os seus riscos específicos: “a integração com o banco é a incógnita; se o sandbox deles for lento, some duas semanas”. Um time que diz “nada, está tudo sob controle” não olhou fundo o suficiente. Se você estruturou o contrato como preço fixo ou time e materiais muda quem carrega esse risco, mas nunca faz o risco desaparecer.

O que você pode fazer esta semana para entregar mais rápido

Você tem mais controle sobre o prazo do que imagina, e quase nada disso é técnico.

Corte a primeira versão com mais coragem do que parece confortável. A maior parte do que está no seu quadro branco não é necessária para colocar o produto na frente de um cliente pagante, e cada funcionalidade que você adia é tempo que você recupera agora. A disciplina de entregar menos é a velocidade mais barata à sua disposição.

Deixe o escopo concreto antes de o desenvolvimento começar, não durante. Uma tarde decidindo os casos ambíguos lá no início economiza semanas de paradas no meio do caminho. Escreva o que está dentro e, mais importante, o que está fora.

Depois proteja a velocidade do time estando disponível. Decida rápido, responda perguntas no mesmo dia e não suma por uma semana esperando que o prazo se segure. Software é construído na velocidade das suas decisões. Se você tratar o desenvolvimento como algo que acontece sem você, ele vai levar exatamente o tempo da sua semana mais lenta, multiplicado pelo projeto inteiro.

Nada disso exige que você leia código. Exige que você trate o prazo como algo que você co-possui com o time, não um número que você extrai deles e depois torce. Os founders que entregam no prazo não são os que acharam desenvolvedores mais rápidos. São os que perguntaram “quanto tempo até o quê”, escoparam com honestidade e saíram da frente do desenvolvimento.

Perguntas frequentes

Quanto tempo costuma levar para desenvolver um app?
Para uma primeira versão real que um cliente pagante consegue usar, de três a seis meses, com um time focado e um escopo claro. Uma ferramenta interna pequena pode levar de quatro a oito semanas. Um produto transacional ou regulado costuma levar seis a nove meses ou mais.

Qual é o prazo médio de desenvolvimento de um app?
Não há uma média que valha a pena citar, porque “um app” vai de um demo de uma semana a uma plataforma de um ano. As âncoras úteis são por tipo de projeto: ferramenta interna (4–8 semanas), primeira versão real do produto (3–6 meses), marketplace (5–8 meses), produto regulado (6–9+ meses).

Quais são as sete etapas do desenvolvimento de um app?
As etapas que costumam listar (discovery, design, desenvolvimento, integração, testes, lançamento, manutenção) importam menos do que saber quais delas consomem o tempo. Na maioria dos projetos, discovery e integração comem muito mais do calendário do que o founder espera, e os testes são a etapa que é cortada sob pressão e causa o atraso lá na frente.

Quão rápido um app pode ser desenvolvido?
Um demo clicável pode ficar pronto em uma a duas semanas. Mas “rápido” normalmente significa cortar as partes que tornam o software confiável, então velocidade comprada antes de o escopo estar definido quase sempre é dívida contra um atraso futuro. Os desenvolvimentos rápidos de verdade vêm de cortar escopo, não de cortar caminho.