Quanto custa um aplicativo: o que define o preço

O gestor pediu orçamento de aplicativo pela primeira vez e voltou com três propostas que parecem falar de projetos diferentes. Uma descreve só as telas do celular. Outra inclui API, painel e publicação nas lojas. A terceira entrega um PWA instalável por link e deixa a loja de fora. Os números divergem, e ninguém consegue explicar a diferença em uma frase.

Este artigo mostra o que entra no preço de um aplicativo, por que orçamentos para o "mesmo" pedido diferem tanto e o que levar para pedir propostas comparáveis. No meio há um checklist pronto. Se a dúvida ainda é entre PWA e nativo, comece pelo artigo PWA ou aplicativo nativo. Se a dúvida é como roda um projeto do diagnóstico à produção, veja projeto de software sob medida.

O que entra no preço de um aplicativo?

O preço de um aplicativo cobre o trabalho de transformar um processo ou um produto em software que alguém usa no celular, com o que precisa existir atrás dessa tela. Na maior parte dos projetos, a tela é só uma parte. Há API, banco de dados, painel administrativo, regras de acesso, publicação e um período de ajustes depois do lançamento.

Em aplicativos mobile tratamos isso de forma explícita: o aplicativo quase nunca anda sozinho. Ele precisa de uma API, de um banco e de um painel para quem administra conteúdo e usuários. Quando o caminho é a loja, entra também a configuração das contas, os textos e as telas de divulgação e o acompanhamento da revisão. A página do serviço diz que a revisão da Apple e do Google costuma levar de um a poucos dias, e que a primeira publicação precisa de folga porque a loja pode voltar com exigências.

Há custos fixos pequenos e públicos que muita gente descobre tarde. O Apple Developer Program cobra 99 dólares por ano para publicar na App Store. O Google Play cobra uma taxa única de registro de 25 dólares. Esses valores não definem o preço do projeto, mas precisam estar no orçamento de quem vai à loja.

Por que orçamentos para o mesmo app diferem tanto?

Orçamentos divergem porque cada fornecedor completa as lacunas do pedido com hipóteses diferentes. Se o briefing diz só "app de inspeção para a equipe", um lado assume formulário simples em PWA, outro assume nativo nas duas lojas com fotos offline e painel de indicadores. Os dois estão respondendo ao texto que receberam. Estão orçando escopos diferentes.

Três lacunas explicam a maior parte da diferença:

1. Plataforma: PWA, nativo iOS, nativo Android ou os dois nativos. O artigo sobre PWA ou aplicativo nativo mostra quando cada caminho faz sentido.
2. Back-end: só o aplicativo, ou aplicativo mais API, mais painel, mais login e perfis.
3. Fronteira da primeira versão: o que entra agora e o que fica explícito como fase seguinte.

Também pesa o nível de detalhe do processo. Quem opera no cais, a bordo ou na portaria conhece exceções que a lista de telas esconde: aparelho compartilhado, turno da noite, área sem sinal, terceirizada sem cadastro. Sem essas exceções no briefing, cada proposta inventa um cenário.

No aplicativo de saúde que desenvolvemos, a decisão pelo nativo veio de requisitos concretos: assinatura nas lojas, login com Apple e uso diário em iOS e Android. Usamos React Native com Expo e o mesmo back-end em Ruby on Rails. Já no transporte marítimo de passageiros, o caminho foi PWA, porque a equipe interna recebe o sistema por link e atualiza sem passar por loja.

O que pesa mais e o que quase não muda o preço?

O que mais pesa no preço é o escopo da primeira versão, o número de plataformas, a complexidade da API e do painel, as integrações e o trabalho sem conexão. O que quase não muda o preço sozinho é a taxa das lojas, a escolha entre duas bibliotecas parecidas e o ícone na tela de início.

A tabela não substitui um diagnóstico. Ela ajuda a ler uma proposta: se o valor parece baixo e a coluna da esquerda está cheia de itens ambíguos, o risco está no que ficou de fora. Se o valor parece alto e a proposta detalha integrações, offline e painel, compare o conteúdo, não só a linha final.

Salário de mercado não fecha o preço de um projeto. A Robert Half publica, na faixa nacional, mediana de R$ 11.700 para desenvolvedora mobile pleno (salário de entrada da vaga). Isso fala do custo de manter gente alocada, e não do valor de um aplicativo entregue. Um projeto mistura desenho, desenvolvimento, testes, publicação e acompanhamento; o número de um salário isolado não fecha essa conta.

O que levar para pedir um orçamento comparável?

O que torna orçamentos comparáveis é um mesmo pacote de decisões respondido antes do pedido. Sem isso, cada fornecedor preenche o vazio com a hipótese que conhece melhor, e você compara maçãs com laranjas.

Use o checklist abaixo com quem conhece a rotina (não só com quem aprova a compra). Leve as respostas por escrito. Peça que a proposta diga o que entra, o que fica de fora e quais hipóteses foram usadas quando algo ficou em aberto.

Depois de marcar os itens, releia a coluna "o que fica de fora". É nela que propostas honestas se separam das que prometem tudo em um número só. Se ainda faltar decidir entre PWA e nativo, responda primeiro o checklist do artigo PWA ou aplicativo nativo e só então peça preço.

Como comparar propostas sem se perder em números?

Para comparar propostas, alinhe primeiro o escopo e só depois olhe o valor. Peça a cada fornecedor a mesma grade: plataformas, API e painel, integrações, offline, publicação, o que fica de fora e como fica a sustentação depois do lançamento.

Uma grade prática:

1. O que a primeira versão entrega, em funções que alguém consegue testar.
2. Em quais aparelhos e sistemas isso roda no dia do lançamento.
3. Se a API e o painel estão inclusos ou são outro projeto.
4. Quais integrações estão no preço e quais dependem de outro time ou de outro contrato.
5. Como o app se comporta sem sinal, se isso importa para a operação.
6. Quem publica nas lojas ou distribui o PWA, e quem responde à revisão.
7. O que acontece nas primeiras semanas após o lançamento: correções, canal de suporte, novas versões.
8. O que a proposta declara ficar de fora.

Desconfie de comparação só por "prazo em semanas" quando o briefing ainda está vago. Prazo curto com escopo aberto costuma esconder uma segunda negociação no meio do caminho. O artigo sobre projeto de software sob medida mostra por que a primeira versão em uso vale mais como indicador do que a promessa de sistema completo no fim.

Também compare quem participa do seu lado. Proposta que assume que o fornecedor inventa o processo sozinho vai cobrar retrabalho depois, quando a operação apontar as exceções reais.

E se o app for só interno, só iOS, ou precisar funcionar sem sinal?

Se o aplicativo for só interno, o PWA costuma reduzir custo de distribuição e de manutenção, porque atualiza para todos no mesmo momento e dispensa revisão de loja. A equipe recebe um link ou um QR code. Nos nossos sistemas de operação, esse é o caminho mais comum: o piloto registra viagem e o tripulante executa checklist a bordo sem passar pela App Store. Os casos de transporte marítimo de passageiros e de inspeção e manutenção de embarcações seguem essa linha.

Se a necessidade for só iOS no começo, dá para publicar uma plataforma primeiro e deixar a segunda para a fase seguinte, desde que a API já nasça pronta para os dois. Publicar só uma loja reduz trabalho de revisão e de materiais, mas não elimina o back-end. O painel e as regras continuam existindo.

Se o app precisa funcionar sem sinal, o offline entra no escopo desde o diagnóstico. É preciso dizer o que fica no aparelho, por quanto tempo, e o que acontece quando duas pessoas alteram o mesmo registro desconectadas. Esse desenho pesa no preço em qualquer tecnologia. No caso de inspeção de embarcações, um achado registrado a bordo aparece em terra quando a conexão volta; essa regra precisa estar combinada antes do desenvolvimento.

Dados pessoais mudam o cuidado, mesmo quando o app é interno. A LGPD (Lei 13.709/2018), no artigo 46, pede medidas de segurança técnicas e administrativas para proteger dados pessoais, observadas desde a concepção do produto. Na prática, perfis de acesso, registro de ações sensíveis e definição do que o aparelho guarda offline entram no orçamento junto com as telas.

Quando um aplicativo não é o caminho (ainda)?

Um aplicativo não é o caminho quando o processo ainda não tem dono nem regra clara. Se cada equipe faz de um jeito e ninguém descreve o fluxo certo, o celular só leva a confusão para o bolso de cada um. O primeiro trabalho é escrever o processo com quem opera.

Também vale esperar quando o que falta é o sistema por trás. Formulário no celular sem cadastro único, sem permissões e sem relatório vira ilha de dados. Nesse caso, o passo anterior é o sistema web sob medida que guarda regras e informações; o aplicativo vira uma das telas dele.

Produto pronto de prateleira resolve melhor quando o processo é genérico (por exemplo, filas simples de atendimento iguais às de qualquer empresa) e você aceita adaptar a operação ao software. Aí o preço de um app sob medida costuma sobrar.

Se o seu time já consegue descrever o problema, os usuários e a primeira versão, a boosting.tech é uma empresa de software customizado que desenvolve aplicativos e o back-end que eles pedem. A conversa de diagnóstico não tem custo: alinhamos o escopo, as plataformas e o que fica de fora, e só então falamos de proposta. Os detalhes estão em aplicativos mobile.