Porque não existe um preço único para uma aplicação
Perguntar quanto custa uma aplicação é um pouco como perguntar quanto custa uma casa. Depende do tamanho, do terreno, dos acabamentos e do que vai lá dentro. Uma aplicação de marcações com pagamentos para um salão e uma aplicação de entregas em que o cliente acompanha o estafeta em direto no mapa são produtos muito diferentes, mesmo que ambas "tenham login e enviem notificações".
Por isso, desconfie de qualquer valor apresentado antes de alguém perceber o seu projeto. O que podemos fazer é mostrar-lhe as peças que compõem um orçamento. Quando as conhece, percebe porque é que uma proposta é mais alta do que outra e decide o que vale a pena construir agora e o que pode esperar.
Âmbito: ecrãs, fluxos e perfis de utilizador
O âmbito é o que mais pesa. Cada ecrã tem de ser desenhado, programado, ligado à base de dados e testado. Contar ecrãs, no entanto, não chega. O trabalho real está nos fluxos, o caminho completo que o utilizador percorre. Um registo simples é um fluxo curto. Um checkout com cupões, envio, formas de pagamento e e-mail de confirmação é um fluxo longo, com muitas regras e muitas formas de falhar.
Os perfis de utilizador multiplicam esse trabalho. Uma aplicação só para clientes finais é uma coisa. Uma aplicação com clientes, equipa e gestores, cada um com ecrãs e permissões diferentes, é outra. Uma aplicação de entregas tem, no mínimo, três experiências: o comprador, o estafeta e o administrador.
Quase todas as aplicações empresariais precisam ainda de um painel de administração, a área web onde a empresa gere produtos, horários e preços e acompanha encomendas. É fácil esquecê-lo quando se imagina a aplicação, mas faz parte do produto e do orçamento. Um painel com relatórios, exportação de dados e gestão de equipa dá mais trabalho do que um simples editor de registos.
Integrações e funcionalidades especiais
Integrar é fazer a aplicação comunicar com sistemas que já utiliza. Algumas integrações são simples porque o serviço tem uma API bem documentada. Outras obrigam a mexer num sistema antigo, a limpar dados desorganizados e a tratar do que acontece quando o outro lado fica em baixo.
Algumas funcionalidades também parecem pequenos itens numa lista, mas mudam o tamanho do projeto, porque exigem mais arquitetura, mais testes e, por vezes, serviços externos pagos. Regras de negócio complexas, como comissões, níveis de acesso e fluxos de aprovação, entram na mesma categoria. O que costuma pesar mais:
- Pagamentos: cartões, carteiras digitais, subscrições recorrentes, divisão de pagamentos entre vendedores.
- ERP e CRM: stock, faturação, catálogos sincronizados, envio de contactos comerciais para a equipa de vendas.
- WhatsApp e APIs de terceiros: confirmações, lembretes, envios, início de sessão com redes sociais.
- Tempo real: chat, localização do estafeta, painéis que se atualizam sozinhos.
- Mapas e localização: rotas, zonas de entrega, pesquisa por proximidade.
- Inteligência artificial: assistentes, leitura de documentos, recomendações.
- Modo offline: guardar dados no dispositivo e sincronizar quando a ligação regressa.
Design, plataformas e publicação nas lojas
Se a sua empresa já tem identidade visual, com logótipo, cores e tipografia, o design parte daí e o trabalho é aplicar a marca aos ecrãs. Se está a começar do zero, é preciso criar a identidade primeiro, o que acrescenta tempo. Os protótipos clicáveis, que permitem testar a experiência antes de escrever código, também fazem parte desta etapa e costumam poupar retrabalho mais tarde.
A escolha das plataformas muda o custo. Hoje é possível servir iPhone e Android com um único código-fonte, e uma aplicação web progressiva (PWA) pode ser instalada diretamente a partir do navegador, sem passar pelas lojas. As aplicações totalmente nativas, com código separado para cada sistema, dão mais trabalho e fazem sentido quando o produto depende muito de funcionalidades do dispositivo.
A publicação na App Store e no Google Play é uma etapa à parte. Exige contas de programador, imagens e textos para a página da loja, uma política de privacidade e a aprovação de cada loja, que pode pedir alterações antes de aprovar.
O custo não termina no lançamento
Muitas pessoas orçamentam apenas o desenvolvimento e são surpreendidas mais tarde. Uma aplicação no ar tem custos recorrentes: servidores e base de dados, domínio, serviços de e-mail e de notificações push, APIs pagas para mapas ou IA e taxas de processamento de pagamentos. Se a aplicação estiver nas lojas, a Apple cobra uma anuidade de programador e a Google cobra uma taxa de registo. Muitos destes custos crescem com a base de utilizadores.
Depois há a manutenção. Os sistemas operativos mudam, as bibliotecas recebem atualizações de segurança e as lojas atualizam as suas regras. A utilização real também revela melhorias e novas funcionalidades que valem a pena. Planeie desde o primeiro dia como vão funcionar o suporte e a evolução contínua depois de a aplicação estar no ar.
Porque é que os orçamentos variam tanto entre empresas
É comum receber propostas muito diferentes para o mesmo projeto. Na maioria das vezes, não estão a orçamentar a mesma coisa. Uma inclui painel de administração, testes em dispositivos reais e publicação nas lojas. Outra entrega só a aplicação, sem painel, e deixa o resto como "extras" que aparecem a meio do caminho.
A forma como a aplicação é construída e por quem também conta. Adaptar um modelo pronto custa menos do que um desenvolvimento à medida, mas limita o que poderá mudar depois. Um código limpo e documentado custa mais no início e muito menos quando a aplicação precisa de crescer ou de passar para outra equipa. Não compare os valores finais. Compare o que está escrito em cada proposta.
Como reduzir o custo sem perder qualidade
A forma mais segura de gastar menos é construir menos coisas, e não construí-las pior. Dispensar testes ou aceitar um código frágil sai caro assim que a aplicação precisa de correções ou de uma nova funcionalidade. Cortar o âmbito com cuidado preserva o que importa.
Começar por um MVP, a menor versão que já resolve o problema principal, é o caminho mais comum. Explicamos como definir essa primeira versão no nosso artigo sobre o que é um MVP. Algumas práticas que ajudam:
- Escrever numa frase o problema que a aplicação resolve e deixar de fora tudo o que não contribui para ele.
- Separar o que é preciso no lançamento do que seria bom ter mais tarde.
- Dividir o projeto em etapas, cada uma com uma entrega funcional.
- Começar por uma PWA e deixar a publicação nas lojas para quando a utilização a justificar.
- Usar serviços prontos para as partes que não são o seu diferencial, como o início de sessão e o envio de e-mails.
O que uma proposta séria deve especificar
Uma boa proposta deixa pouco espaço para surpresas. Antes de assinar, verifique se inclui:
- Âmbito detalhado: ecrãs, fluxos, perfis de utilizador, painel e integrações.
- Prazo total, dividido por etapas.
- Preço fechado, com pagamentos associados às entregas.
- O que recebe no fim de cada etapa e como o vai testar.
- O que não está incluído, como alojamento, contas das lojas e serviços de terceiros.
- Como funcionam o suporte e as alterações de âmbito depois de o projeto arrancar.
Como a BG Coding elabora um orçamento
Não trabalhamos com tabela de preços. Primeiro, conhecemos o seu negócio, o seu público e o problema que a aplicação precisa de resolver, numa conversa de diagnóstico. Depois, enviamos uma proposta com âmbito, etapas, prazo e preço fechado, incluindo o que fica de fora. Se a verba for curta, sugerimos um MVP ou uma primeira fase que já resolva o problema principal.
Se tem uma ideia de aplicação e quer saber o que é preciso para a concretizar, conte-nos tudo na nossa página de pedido de orçamento e voltaremos a contactá-lo com um diagnóstico.