Quanto custa fazer um aplicativo: as variáveis que decidem a conta, e o que perguntar para chegar num número
Ninguém dá um número por telefone porque o mesmo pedido cabe em três projetos de tamanhos diferentes. O que dá para publicar são as variáveis — e as perguntas escritas que fazem três propostas falarem do mesmo produto.
Publicado 9 min de leitura Kapstan
A pergunta
O número que ninguém consegue dar por telefone
Quanto custa fazer um aplicativo é uma pergunta sem resposta única porque a palavra “aplicativo” não descreve trabalho nenhum: ela nomeia a tela, e a tela é a menor parte. Dois pedidos com a mesma descrição — “um app de agendamento” — viram projetos de tamanhos diferentes conforme o que acontece quando o cliente cancela, paga ou erra.
Quem responde na primeira ligação está respondendo outra pergunta: quanto custaria construir o que ele entendeu em dois minutos. É um número honesto sobre uma coisa que não é o seu projeto, e ele volta como aditivo quando a diferença aparece.
Estimar é possível, e rápido, desde que a conversa passe pelas variáveis antes do valor. Quem constrói também mexe na conta: os quatro caminhos para construir cobram coisas diferentes, e a escolha entre eles é anterior ao orçamento.
O mesmo pedido são três projetos
Um aplicativo de agendamento pode ser três projetos diferentes com a mesma tela. O que os separa não é o desenho: é o que o sistema faz quando alguém erra. Se ele apenas mostra a agenda, é um; se grava, cobra e confirma, é outro; se avisa terceiros, concilia e responde por horário marcado em duplicidade, é o terceiro.
- Mostra A tela apresenta a informação e nada acontece depois dela. Erro não tem consequência porque nada foi registrado.
- Registra O que a pessoa faz fica gravado, e por isso precisa de conta, permissão e um caminho de volta para cada engano.
- Responde O sistema promete algo a alguém de fora — cobra, avisa, reserva. Cada promessa exige o caso em que ela falha, e é aí que mora o trabalho.
Peça a quem for orçar que descreva, por escrito, o que o sistema faz quando o pagamento cai no meio. A resposta a essa frase separa um orçamento de tela de um orçamento de produto.
O que de fato move a conta
Cinco variáveis decidem o tamanho de um projeto de aplicativo: quantas jornadas ele atende, quantos sistemas de terceiro ele precisa alcançar, de quem é o dado que ele guarda, se há dinheiro passando por dentro e em quantas plataformas ele roda. Elas não somam — elas multiplicam, e é por isso que dois pedidos parecidos terminam em ordens de grandeza diferentes.
| Variável | O que ela decide | O que costuma ser subestimado |
|---|---|---|
| Quantas jornadas | O escopo em linha reta | Cada jornada tem um caminho que dá certo e vários que não. É o segundo grupo que some. |
| Integração com sistema de terceiro | Quanto do projeto não depende de você | Ambiente de teste, homologação e o dia em que a API do outro muda sem avisar. |
| De quem é o dado | Arquitetura, contrato e prazo ao mesmo tempo | Dado de saúde, financeiro ou de menor não é cláusula no fim: é outro jeito de construir desde o início. |
| Se há pagamento | Se existe conciliação — um projeto dentro do projeto | Cobrar é simples. Estorno, assinatura que falha, imposto e o fechamento com o banco levam o tempo. |
| Quantas plataformas | Quantos produtos você está pedindo | Duas plataformas são duas filas de revisão e dois ciclos de correção — não um botão de exportar. |
Três das cinco você fecha sem fornecedor nenhum: a lista de jornadas, a lista de sistemas que o aplicativo precisa alcançar e a decisão de rodar em uma plataforma só no primeiro corte. Chegar com as três escritas é o que faz a primeira conversa começar no tamanho do projeto, e não na adivinhação dele.
Ordem de grandeza não é margem
Quatro coisas mudam a ordem de grandeza de um projeto, e não a margem dele: dinheiro passando por dentro, dado sensível, integração com sistema que você não controla e a exigência de rodar em mais de uma plataforma. Todo o resto — cor, quantidade de telas, texto do botão — mexe na borda da conta, e é justamente o que ocupa as reuniões.
A razão é sempre a mesma: cada uma das quatro não acrescenta trabalho, acrescenta uma categoria de trabalho. Pagamento traz conciliação e estorno. Dado sensível traz registro de acesso, prazo de guarda e o pedido de exclusão. Sistema de terceiro traz uma fila de aprovação que não obedece ao seu cronograma. Segunda plataforma traz um segundo produto.
Isso muda o que se negocia: pedir desconto num projeto que tem as quatro é pedir que alguém deixe de fazer uma delas — e a que sai é a menos visível, o tratamento de erro.
O orçamento
O que chega depois do orçamento
O orçamento de construção descreve o que se constrói, e não o que se opera: infraestrutura, plantão e correção continuam custando todo mês e ficam de fora por padrão. No caso de um aplicativo há ainda um custo que não é de programação — a conta de loja e o ciclo de revisão antes de cada versão, que é tempo de calendário e não acelera com mais gente.
O custo de operar tem seção própria no pilar — o que custa depois que sobe. Para o orçamento importa uma pergunta só: quem assume cada um desses itens, e a partir de qual dia. Sem ela respondida na proposta, a resposta chega no dia da primeira queda.
Como fazer três propostas virarem comparáveis
Três propostas só se comparam quando as três responderam à mesma lista escrita. Sem ela, cada fornecedor orça um produto diferente e a mais barata é apenas a que entendeu menos. A lista tem seis perguntas, todas por escrito, e ela vale mais que qualquer conversa: o que se compara depois não é o total, é o que cada um respondeu.
- As jornadas, nomeadas e fechadas. Não “um app de agendamento”: agendar, remarcar, cancelar, cobrar, avisar. É o que faz duas propostas falarem do mesmo produto.
- O que o sistema faz quando dá errado. Três casos: pagamento que cai no meio, o mesmo botão apertado duas vezes e cadastro que já existia.
- Quais sistemas de fora entram, e quem homologa cada um. Essa fila não é sua.
- De quem é o repositório e a infraestrutura, e desde qual dia. Um “depois a gente transfere” é preço, não detalhe.
- O que está fora do escopo. Proposta sem essa lista não é mais barata: é mais vaga, e a vaga cobra a diferença depois.
- Quem opera depois de subir, e sob qual acordo. É o que separa quem entrega de quem sustenta.
Leia as respostas antes de olhar o total. Quem descreve o caso de erro e quem não o menciona não estão orçando o mesmo trabalho — e o segundo vai cobrar por ele mais tarde, com outro nome.
Os cortes de escopo, e o que muda entre um e o seguinte
Um projeto de aplicativo tem quatro cortes possíveis, e cada um responde a uma pergunta diferente: protótipo navegável, primeiro corte no ar, produto com cliente pagando e produto com operação. A conta não é decidida pelo produto inteiro — é decidida pela distância entre o corte que você pediu e o anterior.
| O corte | O que ele já responde | O que ele ainda não aguenta |
|---|---|---|
| Protótipo navegável | Se a ideia se explica sozinha | Usuário de verdade. Ele não guarda nada, e o que se aprende é sobre a tela, não sobre o produto. |
| Primeiro corte no ar | Se alguém usa, e por quê | Volume e exceção. Trabalho manual atrás da tela é aceitável aqui — e só aqui. |
| Produto com cliente pagando | Se alguém paga, e continua pagando | Conciliação e suporte. Dinheiro entrando cria obrigações que o corte anterior não tinha. |
| Produto com operação | O dia a dia sem você por perto | Nada — e passa a ter custo fixo mesmo num mês sem nada novo. |
Pedir o primeiro corte sabendo qual é o próximo é a diferença entre cortar escopo e adiar decisão. Cortar por jornada inteira mantém o corte útil; cortar por camada devolve telas que não ensinam nada — o que um MVP é, e o que ele não é trata dessa distinção, e é onde a maior parte dos orçamentos escorrega.
Perguntas frequentes
O que é
Quanto custa fazer um aplicativo?
Depende de cinco variáveis que multiplicam entre si: quantas jornadas o aplicativo atende, quantos sistemas de terceiro ele alcança, de quem é o dado que ele guarda, se há dinheiro passando por dentro e em quantas plataformas ele roda. Três delas você fecha sozinho antes de pedir a primeira proposta.
Por que ninguém publica uma tabela de preço?
Porque a mesma descrição — “um app de agendamento” — cabe em projetos de tamanhos muito diferentes, conforme o que o sistema faz quando alguém erra. Uma tabela descreveria um projeto que não é o seu, e quem lê levaria embora o número errado. As variáveis, sim, permitem estimar de que lado o seu caso cai.
Como se faz
Como faço três orçamentos virarem comparáveis?
Mandando a mesma lista escrita para os três, no mesmo dia: as jornadas nomeadas e fechadas, o que o sistema faz em três casos de erro, quais sistemas de fora entram e quem homologa, de quem é o repositório, o que está fora do escopo e quem opera depois. Compare pelo que ficou de fora.
Dá para começar menor e crescer depois?
Dá, e costuma sair mais barato — desde que o corte seja por jornada inteira, e não por camada: uma jornada do início ao fim ensina alguma coisa, três telas sem nada atrás não ensinam. O que não se corta é o que fica caro depois: modelo de dados, conta e permissão.
O que preocupa
O que não está no orçamento e vai chegar depois?
Quatro coisas: conta de loja e os ciclos de revisão, a infraestrutura em que o produto roda, o plantão de quem atende quando ele cai, e o segundo mês — a correção do que só aparece com gente real usando. Pergunte quem assume cada uma antes de assinar.
E se o preço estourar no meio do projeto?
Estouro quase nunca vem de estimativa errada: vem de decisão de produto tomada durante a construção, e de escopo que nunca foi escrito como lista fechada. A lista de jornadas e a do que está fora do escopo transformam a surpresa em conversa — as duas mostram o que mudou, e quando.
Quer um número para o seu caso?
A Kapstan constrói e põe no ar app, site e produto digital. A conversa começa por você contando as jornadas que o seu precisa atender — o orçamento vem depois disso, e não antes.
sem compromisso · no WhatsApp ou no Google Meet