O que realmente determina o custo de uma aplicação móvel

“Quanto custa desenvolver uma aplicação móvel” é uma das pesquisas mais comuns à volta do desenvolvimento de software, e também uma das que pior se responde com um número solto. Duas ideias descritas com a mesma frase num primeiro email — “uma app para marcar consultas”, por exemplo — podem ser projetos com um alcance completamente diferente, consoante o que está por detrás dessa frase.

Antes de falar de custo, vale a pena separar duas coisas que se misturam com frequência: escrever o código da aplicação, e tudo o que rodeia essa aplicação para que funcione mesmo nas mãos de um utilizador real. A segunda parte quase nunca aparece num orçamento improvisado, e é normalmente a que mais pesa.

O código é só uma parte do projeto

Uma aplicação que chega de facto à App Store e à Google Play precisa de uma ficha de loja, capturas de ecrã, um processo de revisão que cada plataforma gere à sua maneira, e — assim que vende algo — uma infraestrutura de subscrição ou compra que funcione de forma fiável. Quem não conta com isto desde o início leva com a surpresa mesmo antes do lançamento previsto, normalmente quando já há uma data de marketing ou uma apresentação comprometida que já não se pode adiar.

Isto não afeta só startups com uma ideia de produto. Empresas já estabelecidas pedem aplicações como complemento a um negócio existente — um cartão de fidelização, uma ferramenta de marcações, um acesso a um portal que até agora só funcionava no browser — com a mesma frequência, e as perguntas que determinam o projeto são quase sempre as mesmas.

O que realmente move o número

Uma base de código ou duas equipas separadas. Construímos aplicações móveis com Flutter: uma única base de código para iOS e Android, em vez de duas equipas a manter duas versões com os seus próprios erros. Isso mantém o tempo de desenvolvimento mais previsível, e sobretudo significa que uma alteração não é feita, testada e esquecida duas vezes.

Quantos perfis de utilizador gere. Uma app de consumo com um único tipo de utilizador é mais simples do que uma que tem também um painel de administração, perfis internos ou níveis de acesso diferentes.

Se precisa de conta de utilizador e backend próprio. Uma app que apenas mostra conteúdo estático é muito mais contida do que uma que gere sessões, guarda dados de utilizador e precisa de um sistema por trás que responda em tempo real.

Se vende algo dentro da app. Assim que há uma compra ou uma subscrição, entra em jogo a infraestrutura de pagamentos recorrentes, a gestão de renovações e cancelamentos, e as regras específicas de cada loja de aplicações — outra camada de trabalho que não está no desenho dos ecrãs, mas que determina se a app gera receita de forma fiável ou gera pedidos de suporte.

Quantas integrações precisa. Uma app isolada, que não precisa de falar com nenhum outro sistema, é a mais económica de construir porque os seus limites estão totalmente sob controlo. Uma app que tem de ler ou escrever num ERP, num CRM ou numa plataforma de pagamentos depende do que esse outro sistema realmente oferece.

Fator	O que muda
Número de perfis de utilizador	Complexidade do modelo de dados e dos testes
Conta de utilizador e backend	Necessidade de um sistema próprio por trás da app
Compras ou subscrições dentro da app	Infraestrutura de pagamentos recorrentes, regras da loja
Integrações com sistemas existentes	Tempo de análise, gestão de erros
Publicação em iOS e Android	Dois processos de revisão distintos, um só código com Flutter

O lançamento não é o fim do projeto

Uma app publicada precisa de manutenção: novas versões de iOS e Android que quebram algo sem aviso, alterações nas políticas das lojas, correção de erros que só aparecem com uso real. Um orçamento que só cobre “até publicar na loja” não é um orçamento completo — é a primeira fase de um mais longo.

O que não vamos fazer

Não vamos dar um número nesta página, pela mesma razão que não o damos em nenhuma outra: qualquer valor dado antes de conhecer o alcance real é uma estimativa disfarçada de orçamento. O que podemos antecipar é como trabalhamos: entrega de software utilizável a cada poucas semanas, para rever ecrãs reais em vez de uma apresentação, e detetar uma decisão errada cedo em vez de tarde.

Por onde começamos

Antes de dar qualquer número, perguntamos o que faz a app, quantos tipos de utilizador tem, se vende algo dentro da aplicação, e com que sistemas precisa de falar. Estas quatro respostas determinam a forma do projeto muito mais do que qualquer intervalo publicado num blog. Pode ver exemplos de apps que construímos, incluindo produtos próprios, na página de trabalhos, ou ler mais sobre a nossa abordagem a aplicações móveis.

O preço de uma app não está no código que se vê no ecrã. Está em tudo o que é preciso para que esse código chegue de forma fiável a um utilizador real.

Se o projeto que tem em mente é mais um sistema interno do que uma app de consumo, o artigo sobre comprar ou desenvolver um CRM à medida explica como pensar essa decisão. Para o resto, uma conversa sobre o alcance real é mais rápida do que continuar à procura de um intervalo de preços.