Quanto custa desenvolver um app? A pergunta está errada, e essa é a pergunta que funciona

Uma fundadora com quem trabalhamos no ano passado nos encaminhou três cotações para o que ela chamava de “mesmo” app. US$ 18.000 de um freelancer em Bogotá. US$ 80.000 de um pequeno estúdio em São Paulo. US$ 260.000 de uma agência americana. Mesma descrição de produto, mesmos wireframes, três estimadores honestos. As três cotações eram defensáveis. A barata era um protótipo em Bubble que ela podia mostrar para investidores. A do meio era um app funcional que dois clientes reais podiam usar sem quebrar. A cara incluía a integração de SSO e a revisão de compliance que o piloto enterprise dela ia exigir.

Quanto custa desenvolver um app é uma das perguntas mais buscadas do Google por fundadores. E também uma das menos respondíveis. Os números nas listas são tecnicamente corretos da mesma forma que “uma refeição em Nova York custa entre US$ 4 e US$ 400” é tecnicamente correto. A faixa é tão larga que não diz nada. Pior: toda faixa é enviesada pela fonte. Agências de app cotam faixas que favorecem agências de app. Marketplaces de freelancer cotam faixas que favorecem freelancers. Plataformas no-code cotam faixas que fazem o no-code parecer óbvio.

A pergunta que funciona é outra: quanto custa desenvolver o meu app, no meu escopo, no meu prazo, com um time em que eu posso confiar? Custo em software sob medida é o resultado de seis drivers. Quando você conhece os seus, consegue nomear uma faixa, defendê-la, e parar de ser empurrado pela vendedora.

Por que a resposta padrão está errada

A resposta padrão funciona assim. Um app simples custa US$ 20K a US$ 50K. Um app de complexidade média custa US$ 50K a US$ 150K. Um app enterprise complexo custa US$ 150K a US$ 500K. Algumas fontes empurram o teto para um milhão.

Essas faixas não são mentira. Elas são a média da população de apps que a fonte viu. Você não está construindo o app médio. Você está construindo um app específico, e a média não diz se o seu número fica em US$ 30K ou US$ 300K. A variância dentro de cada banda é maior que a banda em si.

O problema mais profundo é que “simples, médio, complexo” esconde toda decisão que de fato move o número. Um app com uma única tela e checkout em Stripe é simples. Um app com uma única tela e integração de SSO enterprise não é. Um app com cinco telas e um backend tipo Notion é gigante. Um app com quinze telas e um painel admin CRUD é pequeno. Os rótulos colapsam tudo isso em ruído.

Fundadores que ancoram nessas faixas cometem dois erros previsíveis. Pegam a cotação mais barata dentro da banda alvo e descobrem seis meses depois que o time barato construiu um app diferente do que precisavam. Ou assumem que preço é igual a qualidade e pagam 4x por um time que não é melhor que a opção do meio. Os dois erros começam no mesmo lugar: um número que nunca esteve preso a uma estimativa real.

Os seis drivers que de fato definem o seu número

Custo em software sob medida não é mágica. É o produto de seis coisas, e dá pra discutir com qualquer estimador sobre qualquer uma delas. Se uma cotação não decompõe o número em pelo menos quatro desses seis, não é uma estimativa. É um chute vestido de uma.

Escopo: o que os usuários fazem, do início ao fim

Escopo é o maior driver e o que fundadores subestimam de forma consistente. A unidade certa não é “telas” nem “features”. É fluxos. Um fluxo é tudo que um usuário faz para alcançar um objetivo, do cadastro ao resultado.

A maioria dos fundadores conta features e reporta escopo como “dez features”. Um app funcional com dez features tem aproximadamente quarenta fluxos quando você inclui os caminhos infelizes (o que acontece quando um pagamento falha, quando uma sessão expira, quando um e-mail bate, quando um usuário quer apagar a conta, quando um admin precisa estornar). Cada fluxo tem de duas a dez horas de trabalho dependendo de como o sistema está moldado por baixo. A diferença entre contar dez features e contar quarenta fluxos é a diferença entre uma cotação de US$ 40K e uma realidade de US$ 120K.

Se você ainda não escreveu os fluxos que seu app precisa suportar, você não está pronto para ser cotado. Você está pronto para escrever um product requirements document, que é o que qualquer estimador real vai te pedir antes mesmo de cotar.

Integrações: com o que seu app conversa

Todo sistema externo que seu app toca adiciona custo em dois lugares: o build inicial e a manutenção de longo prazo. Uma integração com Stripe é barata porque a Stripe investiu em ser fácil. Uma integração direta com um provedor de PIX brasileiro não é barata, porque a documentação está em português, o sandbox é instável, e os bugs de produção só aparecem sob carga.

Integrações também trazem modos de falha que o resto do código não tem. Um webhook do Stripe pode chegar duas vezes. Um CRM pode retornar 502. Um provedor de identidade pode trocar a tela de consentimento numa terça. Lidar bem com isso exige mais código que o caminho feliz, e um estimador real cobra por isso. Uma cotação barata que lista “integração com Stripe” como uma linha está cobrando o caminho feliz e descobrindo o resto à sua custa.

Conte suas integrações. A maioria dos apps no início tem três a sete (auth, pagamentos, e-mail, analytics, file storage, uma ou duas APIs de domínio). Cada uma raramente sai por menos de US$ 2.000 de trabalho, e fica em US$ 5.000–US$ 10.000 se o provedor for chato.

Dados: onde o estado vive, quem é dono

Alguns apps são UI em cima de uma tabela Postgres pequena. Esses são baratos. Outros são quase todo o dado, com a UI sendo uma camada fina por cima. Esses não são.

As perguntas que movem o número: quanto dado por usuário, com que frequência muda, quem mais precisa ver, dá pra exportar, precisa ser pesquisado, como você faz backup, o que acontece quando o dado de um usuário corrompe às 23h de uma sexta. Cada resposta puxa um design de US$ 0 ou de US$ 20K. Um habit tracker B2C com cinco campos por usuário é a ponta barata. Uma plataforma B2B que ingere o CSV de um parceiro toda noite, transforma e expõe num dashboard que o parceiro também precisa logar é a ponta cara. Mesma quantidade de telas.

Se o seu app é o dado, o custo é o dado. Se o seu app é o workflow em cima do dado, o custo é o workflow. Estimadores que não perguntam qual dos dois você está construindo não estão estimando; estão chutando o mais fácil dos dois.

Compliance e contas: o que a lei e a identidade obrigam você a construir

Três coisas quebram uma cotação barata no contato: indústrias reguladas, clientes enterprise e identidade em escala.

Saúde, fintech, educação e legaltech carregam um overhead de compliance que não é opcional. LGPD, SOC 2 readiness, audit logs, criptografia em repouso, controle de acesso por papel. Nada disso é difícil, mas tudo é trabalho, e adicionar postura de compliance depois custa de três a cinco vezes mais que embutir no início.

Clientes enterprise são parecidos. O dia que seu primeiro cliente real pede SSO, exportação de audit log, papéis customizados e SLA é o dia que seu MVP de US$ 40K vira um produto de US$ 120K. Nada disso é ruim de construir. Não é grátis, e uma cotação barata que diz “a gente adiciona feature enterprise depois” está movendo custo da cotação para o futuro.

Identidade é o terceiro driver silencioso. Um app com um único papel de usuário é barato. Um app com admins, usuários finais, super-admins, contas de parceiro e um papel read-only para o cliente não é. Cada papel arrasta uma matriz de permissão atrás, e matrizes de permissão têm a pior densidade de bugs de qualquer parte do sistema.

Qualidade do time: quem está escrevendo o código

Dois times cotando o mesmo escopo podem produzir números 3x distantes, e o número mais alto costuma ser o melhor negócio. Times juniores escrevem mais código pra fazer a mesma coisa, depois escrevem mais código por cima pra consertar o que a primeira rodada quebrou. A taxa por hora parece economia. O custo total de propriedade conta a verdade.

Um time sênior escreve menos código, escreve com mais cuidado, deixa documentado o suficiente pra um time futuro estender, e entrega um sistema que não cai na primeira vez que você adiciona uma segunda feature em cima. A taxa por hora é maior. O custo de construir, rodar e estender o app nos primeiros 18 meses costuma ser menor.

Se você não consegue avaliar código (e quase nenhum dos nossos clientes consegue), olhe sinais. Como o time fala sobre trade-offs? Pergunta sobre o objetivo de negócio ou só sobre a especificação? Empurra de volta em pedidos que vão criar dívida técnica? Te mostra um sistema rodando em produção de um cliente anterior, não só um screenshot do Dribbble? Um time que não consegue defender uma única decisão de arquitetura em linguagem clara é o time que vai te cobrar duas vezes pela mesma feature quando ela quebrar. Já desenrolamos o resto do diagnóstico em como avaliar uma software house; quase todo sinal daquela lista mapeia em custo.

Ritmo: o quanto o calendário está te apertando

O calendário é a variável mais barata de mover e a que fundadores mais resistem em mover. Comprimir um build de seis meses em três meses não corta o custo pela metade. Aproximadamente dobra, porque builds comprimidos exigem mais gente em paralelo, mais overhead de coordenação, mais retrabalho quando duas branches paralelas colidem, e mais tempo sênior por hora.

O contrário também vale. Um time que consegue construir num ritmo estável ao longo de seis meses vai cotar um total menor que o mesmo time correndo um sprint pra entregar antes do seu demo de investidor. Se você tem flexibilidade no prazo, essa flexibilidade vale dinheiro de verdade. Se não tem, a cotação vai refletir o aperto, e um time que te deu o número de ritmo calmo vai entregar um produto diferente (pior) quando você falar numa terça que precisa pra sexta.

Faixas realistas por estágio

Com os seis drivers na mão, as faixas abaixo viram úteis em vez de enganosas. Continuam sendo faixas. Os drivers acima dizem onde dentro de cada faixa você fica.

Esboço / protótipo para mostrar, não pra usar. US$ 5.000 a US$ 20.000. Build no-code (Bubble, Glide, FlutterFlow), ou um app React muito templado, ou um Figma clicável. Demonstra. Não sobrevive a um usuário real. Use pra fundraising, alinhamento interno ou uma carta de intenção de cliente. Não use como base do seu produto real, e não deixe um estimador prometer que dá.

MVP real que dois clientes reais conseguem usar. US$ 35.000 a US$ 120.000. Três a sete integrações. Dois a três papéis de usuário. Compliance ainda leve. Oito a vinte fluxos de usuário. Um time de dois a três engenheiros ao longo de três a cinco meses. É o formato mais comum de uma engagement da Pixel Breeders, e onde a variância é maior, porque os seis drivers param de ser abstratos e começam a virar horas reais.

V1 pós-lançamento com clientes pagantes e backlog real. US$ 150.000 a US$ 400.000+ no primeiro ano. O build do MVP mais as dez coisas que clientes pedem nos primeiros noventa dias que você não conseguiria prever. O pedido de SSO do primeiro piloto enterprise. O rebuild da fila que vocês ligaram rápido demais durante o MVP. A analytics que você decidiu pular. Fundadores que escopam só pra MVP e não pra “MVP mais o primeiro ano de realidade” voltam perguntando por que os segundos seis meses custaram o mesmo que os primeiros.

Essas faixas assumem time competente, escopo honesto e o mercado dos EUA ou Europa Ocidental. Brasil, Leste Europeu e América Latina cortam a parte de custo do time pela metade sem cortar qualidade, se você achar um time real. Arbitragem geográfica funciona, mas os piores projetos que a gente já ouviu sobre começaram com “achamos um time em [país] pela metade do preço”.

O diagnóstico de cinco perguntas que testa uma cotação

Quando uma cotação chega, faça as cinco perguntas abaixo antes de comparar duas cotações entre si. O diagnóstico separa estimativas reais de teatro de venda. Um estimador real responde sem hesitar. Um chute produz respostas vagas, linguagem defensiva ou “a gente vai descobrindo junto”.

1. Que escopo vocês assumiram, em fluxos? Não features. Fluxos. Se não conseguem listar dez ou vinte fluxos por nome, não estimaram; precificaram seus wireframes.
2. Quais integrações estão na cotação, e quais estão explicitamente fora? Uma cotação real tem uma lista. Um chute diz “a gente lida com integrações conforme aparecer”.
3. Quem exatamente vai estar nesse time? Não a experiência coletiva da empresa. As três pessoas reais que vão escrever o código, com LinkedIn ou GitHub. Um time real entrega os nomes. Um time bait-and-switch não.
4. Quais são os três maiores riscos que vocês veem nesse escopo? Esse é o diagnóstico que pega mais. Um estimador sênior nomeia três riscos em quinze segundos. Um estimador júnior ou desonesto diz “nenhum risco grande, já fizemos isso antes”.
5. Como é o sétimo mês se a gente contratar vocês? Essa pergunta força a pensar para além do build, na manutenção, nos pedidos inevitáveis de feature, nos bugs que aparecem em produção. Um time que só pensou no build vai te cobrar duas vezes por essa conversa depois.

Se uma cotação responde as cinco bem e tem o dobro do preço de uma cotação que não responde nenhuma, a mais cara é a mais barata em doze meses.

Onde fundadores queimam mais dinheiro

A gente assistiu os mesmos três erros drenarem orçamentos por anos. Nenhum deles é sobre a taxa por hora.

Construir o app que você imaginou em vez do app que seus clientes vão usar. A forma mais rápida de gastar US$ 80.000 que você não precisava gastar é entregar o produto que está na sua cabeça e descobrir, depois do lançamento, que clientes querem outra coisa. A cura é colocar a menor versão possível na frente de três clientes reais antes do build, não depois. Já escrevemos sobre por que a maioria dos chamados MVPs não é MVP, e o princípio vale pra custo: a feature mais barata é a que você não constrói.

Economizar no time e pagar de volta em retrabalho. O freelancer que custa US$ 25 por hora e produz código que o próximo time reescreve do zero não te economizou nada. Custou o build duas vezes, mais o tempo perdido entre as rodadas. Mão de obra barata em trabalho de engenharia é a forma mais confiável de pagar caro.

Escolher o contrato que deixa a barateza esconder. Uma cotação fixed-price num escopo mal definido cria o incentivo pro time cortar canto em tudo que você não escreveu. Uma cotação puramente time-and-materials num briefing vago cria o incentivo pro trabalho expandir. O formato do contrato importa tanto quanto o valor. Desenrolamos os trade-offs em fixed price vs time and materials; escolha a estrutura que deixa seu time ser honesto com você.

O que perguntar antes de assinar

Coloque as três coisas abaixo no contrato.

Uma lista dos fluxos que a cotação cobre, e a declaração explícita de que qualquer coisa fora dessa lista é um change request. Isso protege os dois lados. O time não fica refém de coisas que não foram estimadas. Você não é surpreendido quando “a gente cuida do painel admin” vira uma adição de US$ 30K.

Uma demo semanal de software funcionando, não slides, não screenshots. Se o time não consegue te mostrar uma versão rodando do que construiu naquela semana, eles não construíram naquela semana. A demo é a forma mais barata de gestão de projeto que você vai comprar.

Uma estrutura de pagamento por marcos amarrada nessas demos. Não “33% no início, 33% no meio, 33% na entrega”. Algo mais perto de “5% no início, depois um pagamento depois de cada quinzena de demo funcionando”. O time é pago por entregar. Você para de pagar se as demos pararem.

O custo de desenvolver um app é o custo dessas decisões, bem ou mal feitas, multiplicado pelo tempo que um time competente leva pra executá-las. O número não é aleatório. É o resultado de seis drivers que você consegue nomear, três cláusulas de contrato que você consegue escrever e uma conversa diagnóstica que você consegue ter antes de assinar. Fundadores que pulam a conversa pagam por ela depois. Os que têm essa conversa pagam aproximadamente o que o app deveria ter custado, e terminam com o app que de fato pretendiam construir.

É essa a resposta da pergunta original. Não uma faixa. Um método.

FAQ

Dá pra construir um app de graça?
Dá pra construir um esboço de graça com Bubble, Glide ou alguma ferramenta no-code. Não dá pra construir um negócio assim. A versão de graça demonstra. Não sobrevive a usuários reais, escala, integrações ou nenhuma customização significativa. Trate o build de graça como ferramenta de fundraising e validação, depois planeje um build real quando a demanda estiver provada.

Por que as faixas de custo que eu vejo online são tão largas?
Toda faixa colapsa seis drivers independentes em um número. Um app de US$ 20K e um app de US$ 200K podem ter a mesma quantidade de telas, a mesma descrição e o mesmo objetivo de negócio. Os drivers desse artigo são como você transforma uma faixa em um número pro seu app.

Quanto tempo leva pra desenvolver um app?
Um MVP real com clientes pagantes leva de três a seis meses com um time de dois a três engenheiros. Quem promete menos está construindo um protótipo, cortando escopo sem te avisar, ou prestes a entregar algo que quebra. Quem cota doze meses está overbuilding ou subdimensionando o time silenciosamente.

Qual a forma mais barata de validar uma ideia de app antes de construir?
Uma landing page, um vídeo demo e três conversas lideradas pelo fundador com clientes em potencial validam mais em duas semanas do que três meses construindo. A maioria dos fundadores pula esse passo e descobre depois do build que a demanda que assumiu não estava lá no formato que pensava.