Custo e contratação
Quanto custa desenvolver um aplicativo: as faixas que a gente usa e o que cabe em cada uma
Três faixas de preço, o que cabe em cada uma e o que fica fora de todas. Com o que faz um aplicativo mudar de faixa e como a faixa vira proposta.
9 min de leitura
Na App.co, um aplicativo simples ou uma primeira versão enxuta fica entre R$ 20.000 e R$ 40.000. Um aplicativo médio, com backend próprio e painel administrativo, fica entre R$ 40.000 e R$ 70.000. Quando o aplicativo conversa com um equipamento, precisa funcionar sem internet ou vende assinatura nas lojas, o ponto de partida é R$ 50.000, sem teto definido. São faixas de referência, tiradas de orçamentos que a gente já fez, e não uma proposta. O número que vale é o da proposta, que sai do seu escopo escrito.
Quase todo texto sobre esse assunto traz uma tabela parecida e para aí. O que falta nela é o que está dentro de cada número. Duas propostas com o mesmo valor podem comprar coisas muito diferentes: uma inclui backend, publicação nas lojas e o código entregue a você; a outra entrega um arquivo de instalação e uma conta mensal de servidor que ninguém tinha mencionado.
Quanto custa um aplicativo, faixa por faixa?
As três faixas acompanham o que o aplicativo precisa fazer, e não a quantidade de telas. Os prazos ao lado de cada uma também são de referência. Em qualquer delas, some até 30 dias entre o build pronto e o aplicativo disponível para baixar: a revisão da App Store e da Google Play tem tempo próprio e não depende de nenhum dos dois lados.
- Aplicativo simples ou primeira versão enxuta: de R$ 20.000 a R$ 40.000. O fluxo principal do começo ao fim, login, as telas essenciais e a publicação nas duas lojas. Prazo de referência: de 6 a 12 semanas, do briefing à loja.
- Aplicativo médio: de R$ 40.000 a R$ 70.000. Tudo isso com backend próprio e um painel administrativo para você operar o produto sem depender de programador. Prazo de referência: de 3 a 5 meses.
- Aplicativo com equipamento, operação sem internet ou assinatura nas lojas: a partir de R$ 50.000. Prazo de referência, quando entra equipamento ou operação offline: de 4 a 6 meses.
Sinal de alerta
Preço fechado na primeira conversa, antes de existir uma lista do que entra e do que fica de fora. Sem escopo, qualquer número é chute, ou estratégia para fechar.
Por que a terceira faixa começa dentro da segunda e não tem teto?
Porque ela mede um tipo de trabalho que pesa no projeto mesmo quando o resto do aplicativo é pequeno. Um aplicativo de poucas telas que precisa ler um equipamento por Bluetooth no meio da lavoura já está nela.
Os três casos têm algo em comum: parte do trabalho acontece fora do escritório ou depende de regra que a gente não controla. Com equipamento, há teste em campo, e campo tem agenda própria. Com operação offline, a parte cara é a volta: juntar o que mudou no aparelho com o que mudou no servidor enquanto os dois estavam separados. Com assinatura, há renovação, cancelamento e reembolso para tratar, e cada loja tem regras próprias para o que pode ser vendido dentro do aplicativo.
Por isso não há teto publicado. O custo depende do equipamento, de quanto tempo a operação fica sem rede e de como a cobrança funciona, e nada disso dá para estimar sem olhar o caso.
Os três níveis de "funciona sem internet" e o que cada um muda no projetoO que está dentro da faixa?
Uma faixa só serve para comparar se você souber o que ela compra. Nas três, quando o aplicativo é novo, feito do zero, o preço cobre o projeto inteiro até ele estar nas lojas. Evolução de um aplicativo que já existe é orçada à parte, com escopo próprio.
- O escopo da primeira versão, por escrito, antes da primeira linha de código, com a lista do que fica de fora e o motivo de cada corte.
- O desenho do fluxo e das telas junto com você, se você ainda não tem protótipo. Se já tem, a gente parte dele.
- O aplicativo para iOS e Android, a partir de uma base única em Flutter.
- Backend próprio e painel administrativo, quando a faixa prevê.
- Um ambiente de teste no ar durante o projeto, para você usar o produto enquanto ele é construído.
- A publicação na App Store e na Google Play, com data no cronograma.
- O código-fonte e o repositório, entregues a você ao fim do projeto.
Sinal de alerta
Proposta que lista o que entra e não lista o que fica de fora. O que não está escrito vira discussão depois, e quase sempre no pior momento.
O que fica fora de qualquer faixa?
Aqui mora a maior parte das surpresas. Nada da lista abaixo é custo escondido: são gastos que existem em qualquer aplicativo, com qualquer fornecedor. O problema começa quando ninguém fala deles antes.
- Contas e serviços de terceiros. A conta de desenvolvedor da Apple tem anuidade, a do Google Play tem taxa de cadastro, e servidor, banco de dados e domínio são cobrados todo mês ou todo ano. Serviços cobrados por uso, como envio de e-mail e SMS, mapas e IA, crescem junto com o número de usuários.
- A comissão das lojas sobre o que o aplicativo vende. Em assinatura e compra dentro do aplicativo, a Apple e o Google ficam com uma parte de cada venda. Isso sai da sua receita, não do projeto, mas precisa entrar na conta do negócio desde o começo.
- Manutenção e evolução depois que o aplicativo entra no ar. Sistema operacional atualiza, loja muda regra, o negócio pede coisa nova. A gente combina como isso funciona antes de fechar o projeto.
- Mudança de escopo no meio do projeto. Ela é avaliada, recebe estimativa própria, e você decide se entra agora, empurrando o resto, ou na versão seguinte.
- Integração com um sistema que não estava no escopo, como um ERP ou um meio de pagamento que apareceu depois. Conta como mudança de escopo.
- O equipamento em si, quando o aplicativo conversa com hardware. A faixa cobre o software que fala com ele.
- O conteúdo inicial. Os textos, as fotos e o cadastro dos primeiros dados são seus. Se for preciso importar uma base que já existe, isso entra no escopo e aparece na proposta.
Sinal de alerta
Proposta que termina no build entregue, sem uma linha sobre servidor, contas das lojas ou o que acontece depois do lançamento. Esses custos continuam existindo, só que sem dono.
O que faz um aplicativo mudar de faixa?
Cinco perguntas decidem quase sempre, e nenhuma delas é sobre tecnologia.
- Quantos tipos de usuário o produto tem? Um aplicativo em que todo mundo faz a mesma coisa é um projeto. Um em que quem anuncia, quem compra e quem modera veem telas e regras diferentes é outro.
- Alguém precisa operar o produto por trás? Se o seu time vai cadastrar, aprovar ou publicar conteúdo, o projeto ganha um painel administrativo e vai para a faixa do meio.
- Tem cobrança? Pagamento avulso, assinatura nas lojas e assinatura na web mudam o projeto de jeitos diferentes.
- Depende de sistema ou de equipamento de terceiro? Integração custa o que a documentação do outro lado deixa custar, e equipamento exige teste no mundo real.
- Precisa funcionar sem internet? Mostrar sem rede o que já foi baixado sai barato. Trabalhar um turno inteiro sem sinal e sincronizar depois, não.
Sinal de alerta
Fornecedor que dá preço sem fazer essas perguntas. Se ele não sabe quantos tipos de usuário o seu produto tem, ele não sabe o que está orçando.
Como isso aparece em projetos de verdade?
Os cases do portfólio entram aqui para mostrar o trabalho que cada fator exige, e não o preço. O valor de cada contrato é do cliente e não sai daqui.
Tipos de usuário. No Rural Imóveis, corretor e comprador usam o mesmo marketplace com permissões diferentes, separadas no próprio banco com Row-Level Security no Supabase, e todo anúncio passa por um painel de moderação antes de ser publicado. Cada perfil a mais é regra a mais para construir e para testar.
Painel de operação. No Doxys, a equipe médica publica o acervo direto pelo painel, sem depender de programador. Esse painel é um produto dentro do produto, com telas, permissões e fluxo próprios.
Equipamento e operação sem internet. No Farm Tracker, o aplicativo em Flutter lê um hardware com GPS e RFID por Bluetooth, continua registrando sem sinal na lavoura e sincroniza quando a rede volta. O trabalho mais pesado ficou no modelo de dados: definir quem manda quando o aparelho e o servidor divergem.
Ver o case do Rural Imóveis, com corretor e comprador separados no bancoDá para gastar menos sem jogar dinheiro fora?
Dá, e quase sempre cortando escopo, não negociando desconto.
Comece pela primeira versão enxuta: o fluxo que prova a tese, do começo ao fim, sem buraco no meio. O que fica para depois vai para uma lista escrita, com motivo. Cortar funcionalidade é saudável. Cortar teste, controle de acesso ou estrutura de dado sai caro, porque consertar depois custa mais do que fazer certo agora.
Às vezes a resposta mais barata é não construir. Se o seu processo é o padrão do setor, um produto pronto resolve mais rápido e por menos. E se o uso é consulta, sem turno inteiro sem rede e sem equipamento, um site que funciona bem no celular pode bastar.
Sinal de alerta
Orçamento bem abaixo dos outros sem dizer o que foi cortado. Alguma coisa saiu, e é melhor saber o que antes de assinar.
Como a faixa vira proposta?
A faixa serve para você saber se o projeto cabe no seu orçamento antes de gastar tempo com reunião. Quem fecha o valor é a proposta.
A gente conversa sobre o que o produto precisa fazer, escreve o escopo da primeira versão, quebra em etapas e estima uma por uma. A proposta sai com o valor, o prazo de cada etapa, o que entra e o que fica de fora. Se o seu caso não couber em nenhuma das três faixas, a proposta diz isso e explica por quê.
Uma faixa nunca vira número único na primeira conversa. Se alguém disser um valor fechado antes de ver o escopo, pergunte o que está dentro dele.
Quanto custa manter o aplicativo depois de pronto?
Depende de quantas pessoas usam, de quais serviços o aplicativo consome e de quanto ele ainda vai mudar. Por isso não entra nas faixas acima, e por isso precisa estar na proposta antes de você assinar.
Peça esse custo separado em duas linhas: a infraestrutura, que cresce com o uso, e o trabalho de manutenção e evolução. E pergunte quem paga cada conta e em nome de quem ela fica.
A gente entrega e fica por perto depois. O combinado de evolução e suporte sai antes do fim do projeto, junto com o resto.
Os sinais de alerta, numa lista só
Se você levar só uma coisa daqui, leve esta lista. Cada item é a versão curta de uma das seções acima.
- Dá preço fechado antes de existir escopo escrito.
- Lista o que entra e não lista o que fica de fora.
- Não pergunta quantos tipos de usuário o produto tem, se tem cobrança ou se precisa funcionar sem internet.
- Não fala de servidor, contas das lojas nem serviços cobrados por uso.
- Termina a proposta no lançamento, sem uma linha sobre manutenção.
- Cobra bem menos que os outros sem dizer o que cortou.
- Não diz de quem é o código no fim do projeto.
Como a gente chega no número
As três faixas deste texto saem de orçamentos que a gente já fez, e existem para você saber se a conversa vale a pena antes da primeira reunião. O número que vale é o da proposta, com o escopo escrito, o que entra, o que fica de fora e o prazo de cada etapa.
Se for pedir orçamento, para a gente ou para qualquer outro fornecedor, leve as cinco perguntas sobre o que faz um aplicativo mudar de faixa e peça a mesma coisa a todos: o que está dentro do valor e o que fica fora. Só assim dá para comparar. E quando for para construir com a App.co, o código-fonte é do cliente e o repositório é entregue ao fim do projeto.