Quanto custa um software personalizado? O que faz variar

Quanto custa um software personalizado? A resposta honesta é que depende de cinco fatores principais: o âmbito (o que o software tem de fazer), as integrações com os sistemas que já usa, o estado dos dados que vêm de sistemas antigos, as exigências de conformidade e segurança, e o que acontece depois da entrega. A boa notícia é que quase todos estes fatores se controlam: com um problema bem definido, uma primeira versão pequena e uma proposta escrita que diga exatamente o que inclui e o que não inclui.

Neste artigo não publicamos valores: um número sem contexto esconde os pressupostos que realmente fazem o preço. Explicamos o que faz o custo variar, como pedir uma proposta rigorosa e o que ela deve conter.

Porque é que ninguém sério lhe dá um preço sem fazer perguntas

"Uma aplicação para gerir encomendas" pode ser uma folha de cálculo melhorada para uma pessoa, ou um sistema com vários perfis de utilizador, integração com o ERP, portal para clientes e regras de preço por cliente. As duas descrições cabem na mesma frase. O custo não.

Um valor fechado depois de uma conversa de dez minutos ou inclui uma margem grande para cobrir o que o fornecedor não sabe, ou esse desconhecimento aparece a meio do projeto sob a forma de "alterações ao âmbito". Nenhuma das hipóteses é boa para si.

Os fatores que fazem variar o custo

1. Âmbito: o que o software tem mesmo de fazer

É o fator com mais peso. Não se mede em número de ecrãs, mas em complexidade de regras de negócio. Algumas perguntas que o determinam:

Quantos tipos de utilizador existem, e o que cada um pode ver e fazer?
Quantos fluxos de trabalho diferentes o sistema suporta (encomendas, aprovações, devoluções, faturação)?
Quantas exceções existem? "Normalmente é assim, mas para estes clientes é diferente" é a frase que mais custo acrescenta a um projeto.
Precisa de aplicação móvel, de funcionar sem ligação à internet, de vários idiomas?

Uma situação típica: uma PME quer substituir um conjunto de folhas de cálculo que controla a produção. A primeira lista de requisitos tem trinta pontos. Depois de ver o processo real, percebe-se que oito deles resolvem a maior parte do problema diário. Os outros podem esperar por uma segunda fase, ou nunca ser precisos.

2. Integrações com os sistemas que já usa

Poucas empresas partem do zero. Há um ERP (PHC, Primavera, Sage ou outro), uma loja online, um banco, uma transportadora, talvez uma plataforma de email marketing. Cada integração tem custo, e esse custo depende menos do número de integrações do que da qualidade de cada uma:

O sistema tem uma interface de programação (API) documentada e estável, ou a integração tem de ser feita diretamente na base de dados ou por ficheiros exportados?
É preciso comunicação nos dois sentidos, ou basta ler dados?
O que acontece quando um dos lados está em baixo? Os dados ficam em fila, ou perdem-se?

Uma integração mal especificada é, com frequência, a maior fonte de derrapagens.

3. Dados legacy e migração

Se o software novo substitui outro, ou uma coleção de folhas de cálculo, os dados antigos têm de passar para o novo sistema. Em teoria é uma cópia. Na prática, os dados antigos têm duplicados, clientes com três fichas diferentes, campos usados para fins distintos ao longo dos anos e regras que só existem na cabeça de quem os introduziu.

O custo da migração depende do volume, mas sobretudo da qualidade dos dados e de quantas fontes diferentes é preciso consolidar. Vale a pena perguntar logo no início: quem na empresa vai validar que os dados migrados estão corretos? Essa validação é trabalho real, e alguém do seu lado tem de o fazer.

Escrevemos sobre este tema com mais detalhe em Sistemas legacy: sinais de que o seu software está a travar a empresa.

4. Conformidade, segurança e acessibilidade

Algumas exigências não são opcionais e têm de estar no âmbito desde o início:

Proteção de dados. Se o software trata dados pessoais de clientes ou colaboradores, o RGPD exige medidas técnicas e organizativas adequadas para garantir a segurança desse tratamento (artigo 32.º) e prevê direitos como o apagamento dos dados (artigo 17.º) (Regulamento (UE) 2016/679, EUR-Lex). Controlo de acessos, registo de quem alterou o quê e forma de exportar ou apagar os dados de uma pessoa custam menos se forem pensados de raiz.
Faturação. Em Portugal, a emissão de faturas tem regras próprias, incluindo o uso de programas de faturação certificados pela Autoridade Tributária, nos termos da Portaria n.º 363/2010 (gov.pt — Pedir certificação de programa de faturação). Por isso, na maioria dos casos, o software à medida deve integrar-se com o programa de faturação certificado que a empresa já usa, em vez de emitir faturas por si. Esta decisão muda bastante o custo.
Acessibilidade. O Ato Europeu da Acessibilidade (Diretiva (UE) 2019/882) aplica-se a determinados produtos e serviços, incluindo serviços de comércio eletrónico, desde 28 de junho de 2025, com uma exceção para microempresas que prestam serviços (Diretiva (UE) 2019/882, EUR-Lex), transposta em Portugal pelo Decreto-Lei n.º 82/2022.  Se o software é usado pelos seus clientes, e não só internamente, confirme se estas regras se aplicam.

5. Utilizadores, volume e disponibilidade

Uma ferramenta interna usada por cinco pessoas é diferente de um portal usado por milhares de clientes a qualquer hora. O volume de dados, o número de utilizadores em simultâneo e o custo de o sistema estar parado uma hora determinam a infraestrutura, a monitorização e os testes necessários. Se uma paragem de meio dia é um incómodo, a solução pode ser simples. Se uma paragem de meio dia significa encomendas perdidas, o investimento em fiabilidade tem de estar no orçamento.

6. O que acontece depois da entrega

O custo de um software não acaba no dia em que é entregue. Há alojamento, licenças de serviços de terceiros, atualizações de segurança e as melhorias que vão surgir com o uso. Numa proposta, procure respostas claras a estas perguntas:

Onde fica alojado o sistema, e em nome de quem?
De quem é o código, e onde está guardado?
Que documentação e passagem de conhecimento estão incluídas, para que a sua equipa, ou outro fornecedor, consiga continuar o trabalho?
Que custos recorrentes de terceiros existem (alojamento, envio de emails, mapas, pagamentos)?

7. Incerteza

Quando as perguntas acima ainda não têm resposta, o mais sensato é começar por uma fase curta de descoberta, com um resultado concreto: âmbito definido, arquitetura proposta, riscos identificados. Só depois se fecha o preço da construção. Parece um passo a mais, mas é o que evita que a incerteza seja paga duas vezes.

Como controlar o custo

Comece pelo problema, não pela lista de funcionalidades. "Reduzir o tempo de preparação de encomendas" orienta melhor as decisões do que uma lista de quarenta ecrãs.
Faça uma primeira versão pequena. Construa o mínimo que resolve o problema principal e ponha-o nas mãos de utilizadores reais. O que aprender vai mudar as prioridades da fase seguinte, e é mais barato aprender com uma versão pequena.
Compre o que é genérico, construa o que o diferencia. Contabilidade, faturação e email já existem e funcionam. O software à medida deve concentrar-se no que é específico do seu negócio.
Tenha uma pessoa com poder de decisão. Decisões que ficam semanas à espera de uma reunião custam dinheiro, mesmo quando ninguém está a programar.
Prefira âmbito fixo por fases. Iterações com âmbito e preço acordados antes de começar dão-lhe pontos de controlo: no fim de cada uma, decide se continua, se muda de direção ou se para.

Como obter uma proposta rigorosa

Não precisa de um caderno de encargos formal. Prepare o seguinte:

O problema, em poucas frases. O que corre mal hoje, e quanto custa em tempo, erros ou oportunidades perdidas.
O processo atual. Como o trabalho é feito hoje, incluindo as folhas de cálculo e os passos manuais. Exemplos reais (sem dados pessoais) ajudam muito.
Os sistemas envolvidos. Que ERP, que loja online, que outras ferramentas, e se têm API ou exportação de dados.
Volumes aproximados. Número de utilizadores, encomendas por mês, registos a migrar.
Prazos e o motivo. "Até março" ajuda pouco. "Até março, porque é quando começa a época alta" ajuda muito.
Um orçamento aproximado. Partilhar um intervalo não o põe em desvantagem. Permite ao fornecedor propor a melhor solução dentro desse intervalo, em vez de adivinhar.
Quem decide. E quem vai validar o trabalho do lado da empresa.

O que uma boa proposta deve conter

Uma boa proposta de desenvolvimento de software permite comparar fornecedores e, mais tarde, confirmar que recebeu o que pagou. Deve incluir:

Âmbito e exclusões. O que está incluído e, tão importante quanto isso, o que não está.
Pressupostos. Por exemplo: "o ERP disponibiliza uma API com acesso a encomendas" ou "os dados a migrar são entregues num único ficheiro". Se um pressuposto falhar, sabe-se à partida o que muda.
Faseamento e entregáveis. O que é entregue em cada fase e como pode experimentar o trabalho antes do fim.
Prazos. Por fase, com as dependências do seu lado (acessos, validações, dados) identificadas.
Preço e condições de pagamento. Associados a fases ou entregáveis, não a horas sem limite.
Como são tratadas as alterações. O que acontece quando surge um pedido novo a meio do projeto.
Critérios de aceitação. Como se decide que uma fase está concluída.
Propriedade do código e dos dados. De quem é o código, onde fica e quando lhe é entregue.
Custos recorrentes e responsabilidades depois da entrega. Alojamento, licenças de terceiros, documentação e passagem de conhecimento.
Riscos conhecidos. Um fornecedor que não identifica nenhum risco ou não olhou com atenção, ou não lhe está a contar tudo.

Sinais de alerta

Desconfie de propostas com âmbito vago ("desenvolvimento de plataforma de gestão"), sem exclusões, sem pressupostos, com todo o pagamento adiantado, ou em que o código fica na posse do fornecedor. E desconfie de um preço que chega antes de alguém lhe fazer perguntas difíceis sobre o seu negócio.

Próximo passo: uma proposta escrita, sem compromisso

É assim que trabalhamos no Desenvolvimento de MVP e Produto: âmbito cortado até ao que prova valor, iterações com âmbito e preço acordados antes de começar, uma versão a funcionar nas suas mãos desde cedo e um código que é seu.

Fale connosco e descreva em algumas frases o que quer construir, corrigir ou automatizar. Respondemos num dia útil com perguntas e uma primeira opinião honesta. Depois de uma conversa curta, recebe uma proposta por escrito com âmbito, abordagem, prazos e preço, sem compromisso.

O que faz variar o custo de um software à medida (e como controlá-lo)