Quanto custa uma aplicação à medida? Construí-la é só a primeira parcela.

A pergunta costuma chegar antes de existir qualquer documento: quanto custa desenvolver uma aplicação à medida? Pode ser um portal para clientes, um sistema de gestão da operação ou uma aplicação móvel para a equipa comercial. A resposta curta é desconfortável e convém dá-la já. Ninguém lhe consegue dar um preço sério antes de saber o que se vai construir, e o preço de construir é apenas a primeira parcela de uma conta que continua enquanto o sistema estiver em uso. O que se pode dar desde o início é mais útil do que um número: a estrutura do custo, os valores de mercado que existem e o que medem de facto, e os riscos que nenhuma tabela mostra.

O que dizem as tabelas de mercado em Portugal

Os valores publicados mais fáceis de encontrar vêm de plataformas que ligam clientes a profissionais. A Zaask apresenta, para o desenvolvimento de software e aplicações, uma faixa de 15 a 40 euros por hora, com base na média nacional; no texto da mesma página, a faixa passa a ser de 15 a 45 euros por hora, com a média nos 35 euros. Para aplicações móveis, aponta um custo médio à volta dos 20 euros por hora, entre 14 e 30. Para um programador de software com alguma experiência, uma média de 25 euros por hora, entre 10 e 45. A Fixando, outra plataforma que opera em Portugal, mostra para o desenvolvimento de software um preço final médio de 425 euros, entre 300 e 550, e um preço total médio de 470 euros, entre 150 e 790.

Estes números são úteis, mas medem outra coisa. São preços por hora ou por tarefa, não preços de projeto: dizem quanto custa uma hora de trabalho, não quantas horas o seu sistema exige. Numa única tabela, o máximo é 4,5 vezes o mínimo (de 10 a 45 euros por hora), o que já diz que a hora de um profissional não vale a de outro. A página da Zaask mostra 40 euros no topo e 45 no texto, e os metadados indicam fevereiro de 2019 como data da última alteração. E um valor médio de 470 euros por pedido é compatível com uma correção ou uma pequena integração, não com um portal de clientes nem com um software de gestão que atravessa a operação inteira. A conta útil não começa pela taxa. Começa pelas horas, e as horas são precisamente o que ninguém conhece no primeiro dia.

Porque é que ninguém sério lhe dá um número à cabeça

Steve McConnell, da Construx Software, chama-lhe o cone da incerteza. No início de um projeto, os detalhes do que vai ser construído, dos requisitos, do plano e da equipa ainda estão por fechar, e essa variabilidade passa para a estimativa. Segundo McConnell, uma estimativa feita na fase de conceito inicial pode falhar por um fator de quatro para cima ou para baixo, uma amplitude de dezasseis vezes entre a estimativa mais alta e a mais baixa. Em termos de orçamento: um projeto estimado em 100 à cabeça pode acabar em qualquer ponto entre 25 e 400.

It isn’t possible to be more accurate; it’s only possible to be more lucky. Steve McConnell, Software Development's Cone of Uncertainty, Construx, 2010

O ponto mais incómodo é que o modelo descreve o melhor caso: o erro de estimadores competentes, sendo fácil fazer pior. O cone só estreita com trabalho de definição, sobretudo nos primeiros 20 a 30% do calendário, e McConnell situa por volta dos 30% do percurso o momento em que os compromissos passam a ter significado. A consequência financeira é direta. Um orçamento dado antes do diagnóstico só pode fazer uma de duas coisas: ou inclui uma margem larga de segurança, e a empresa paga o risco à cabeça, ou não a inclui, e o risco regressa mais tarde como trabalho adicional. Em nenhum dos casos o número inicial descreve o custo real.

Preço fixo ou tempo e materiais: quem fica com o risco

A forma de contratar não elimina a incerteza, decide quem a carrega. Martin Fowler, autor de vários livros sobre desenvolvimento de software, nota que quando se fala de preço fixo quase sempre se quer fixar três coisas ao mesmo tempo:

Usually when people say fixed price, they mean fixing price, time, and scope. This requires detailed, stable, and accurate requirements. Martin Fowler, Fixed Price, martinfowler.com, 2003

A alternativa que descreve é fixar o orçamento e a data e deixar o âmbito ajustar-se ao que se aprende, com o cliente livre de cancelar cedo se o plano revisto não lhe servir. Na mesa de negociação, isto quer dizer que num preço fixo sobre requisitos ainda instáveis o fornecedor que faz bem as contas incorpora o risco no preço, e num contrato de tempo e materiais, em que se paga o tempo efetivamente gasto, o risco fica do lado de quem contrata. Nenhum dos modelos é mais barato por natureza. O que baixa o custo esperado é reduzir a incerteza antes de assinar, e isso faz-se com diagnóstico, não com negociação.

O custo que começa no dia da entrega

Um software à medida não fica pronto: entra em serviço. A partir desse dia há alojamento, atualizações de segurança, bibliotecas que deixam de ser mantidas, sistemas vizinhos que mudam de versão, pedidos de alteração porque o negócio mudou. Nenhuma destas despesas aparece no orçamento de construção, e todas aparecem na conta.

O dado mais sólido sobre o peso desta fase vem de quem a contabiliza com mais detalhe. O GAO, uma agência independente e apartidária que trabalha para o Congresso dos Estados Unidos, regista que, do que o governo federal gasta por ano em tecnologia (mais de 100 mil milhões de dólares), as agências reportam, tipicamente, cerca de 80% na operação e manutenção do que já existe. Para o ano fiscal de 2025, eram cerca de 83 mil milhões de dólares, 79% do gasto planeado. Do lado de quem programa, um inquérito da Stripe com a Harris Poll, em 2018, a mais de mil programadores e mais de mil executivos nos Estados Unidos, no Reino Unido, em França, na Alemanha e em Singapura, pediu uma estimativa das horas semanais desperdiçadas em manutenção (código mau, erros, depuração, refatoração, modificações): a média foi de 17,3 horas numa semana de trabalho de 41,1.

Quem orça só a construção está a orçar a parte mais visível. Um orçamento responsável reserva desde o primeiro dia capacidade para manter e evoluir o sistema, com um responsável definido, e trata-a como parte do investimento, não como surpresa do segundo ano.

De quem é o código, e o que isso vale

Há um custo que só se vê no dia em que se quer mudar de fornecedor. Em Portugal, o regime dos programas de computador está no Decreto-Lei n.º 252/94, e o n.º 3 do artigo 3.º trata diretamente do software feito por encomenda:

Quando um programa de computador for criado por um empregado no exercício das suas funções, ou segundo instruções emanadas do dador de trabalho, ou por encomenda, pertencem ao destinatário do programa os direitos a ele relativos, salvo estipulação em contrário ou se outra coisa resultar das finalidades do contrato. Decreto-Lei n.º 252/94, de 20 de outubro, artigo 3.º, n.º 3

A regra de partida favorece quem encomenda. Mas a frase termina com duas ressalvas, a estipulação em contrário e as finalidades do contrato, e é aí que a propriedade se ganha ou se perde. Antes de assinar, vale a pena confirmar por escrito que os direitos sobre o programa ficam na empresa, que o código-fonte, a documentação e os acessos ao alojamento são entregues e mantidos atualizados, e em que condições outro fornecedor pode continuar o trabalho. Ter os direitos e conseguir exercê-los são coisas diferentes: um sistema de que a empresa é titular, mas cujo código só uma pessoa conhece e ninguém documentou, cria a mesma dependência que se quis evitar ao recusar uma subscrição. Na Núcleo Parceiro, o princípio está escrito na página de desenvolvimento de aplicações e software à medida: o código, os dados e a arquitetura pertencem à empresa cliente.

O risco que a média esconde

O último custo é o da derrapagem. Bent Flyvbjerg e Alexander Budzier, da Saïd Business School da Universidade de Oxford, analisaram 1.471 projetos de tecnologia, de sistemas de gestão empresarial a sistemas de relação com clientes, e encontraram uma derrapagem média de custos de 27%. O número tranquiliza até se ler o resto.

Fully one in six of the projects we studied was a black swan, with a cost overrun of 200%, on average, and a schedule overrun of almost 70%. Bent Flyvbjerg e Alexander Budzier, Why Your IT Project May Be Riskier Than You Think, Harvard Business Review, 2011

Em conta simples: um projeto orçado em 100 que caia nessa cauda custa, em média, 300. A recomendação dos autores não é deixar de construir. É dividir os projetos grandes em partes de dimensão, complexidade e duração limitadas, preparar planos de contingência para os riscos que não se evitam e prever com base nos resultados de projetos semelhantes noutras organizações. Numa empresa média, isto traduz-se em construir por fases que entregam valor por si mesmas, com um ponto de decisão no fim de cada uma, em vez de apostar o orçamento inteiro numa entrega única.

Quando compensa construir, afinal

Nada disto responde à pergunta anterior, a de saber se deve construir de todo. Essa decide-se pelo papel do sistema no negócio e está tratada no artigo Software à medida ou SaaS: como decidir: compra-se o que é comum, constrói-se o que distingue. Aqui interessa a consequência financeira. Se o sistema codifica aquilo que faz os clientes escolherem a sua empresa, o custo total descrito acima é o preço de um ativo que a concorrência não pode assinar. Se não codifica, é um custo alto para obter o que um fornecedor venderia a toda a gente por uma mensalidade.

Como se decide sem um número inventado

A decisão fica mais barata quando segue uma ordem. Primeiro, definir o que o sistema tem de fazer pelo negócio antes de falar de ecrãs: que decisão melhora, que tarefa elimina, que informação passa a existir. Segundo, pedir a estimativa só depois de um diagnóstico de âmbito, com amplitude explicada (um mínimo e um máximo) em vez de um número único. Terceiro, dividir a construção em fases que valem por si. Quarto, orçamentar a vida do sistema e não só o lançamento. Quinto, fechar no contrato a titularidade do código, a entrega do código-fonte e da documentação e as condições de saída.

É esta a ordem que a Núcleo Parceiro segue. Cada projeto começa por um Diagnóstico Estratégico, e só depois se desenha a arquitetura e se apresenta uma proposta com âmbito e calendário, ao longo de cinco fases: Diagnóstico Estratégico, Arquitetura de Sistema, Design de Experiência, Desenvolvimento, e Escala e Evolução. Não há preço de prateleira, porque não há sistema de prateleira.

O que isto não prova

Nenhum destes números é o preço do seu sistema, e convém dizer onde acaba o alcance de cada um. As faixas da Zaask e da Fixando são médias de orçamentos feitos nas plataformas, sem metodologia detalhada publicada, com texto de 2019 no caso da Zaask, e refletem sobretudo trabalho à hora ou tarefas pequenas; não medem o custo de um portal nem de um software de gestão. O cone da incerteza é um modelo de melhor caso, apresentado por uma empresa que vende formação e consultoria a equipas de software, e não foi calibrado com projetos portugueses. O dado do GAO descreve o portefólio tecnológico do governo federal norte-americano, cheio de sistemas antigos, e não demonstra que 80% do custo de uma aplicação de uma empresa média esteja na manutenção. O inquérito da Stripe mede estimativas declaradas, não horas registadas, e não inclui Portugal. A amostra de Flyvbjerg e Budzier é dominada por organismos públicos (92%) e por projetos nos Estados Unidos (83%), com um custo médio de 167 milhões de dólares; os autores dizem ter encontrado pouca diferença face às empresas privadas e às organizações europeias da amostra, mas a escala não é a de uma PME portuguesa. E a leitura do Decreto-Lei n.º 252/94 feita aqui é informativa, não é aconselhamento jurídico: um contrato concreto deve ser revisto por um advogado.

Fontes

Cada número e cada citação deste artigo foram lidos na fonte primária a 24 de setembro de 2026. Onde a fonte não sustenta a leitura corrente, dizemo-lo no corpo do texto.

1. Zaask, Quanto custa o desenvolvimento de software e aplicações? consultado a 24 de setembro de 2026. zaask.pt/quanto-custa/desenvolvimento-de-software-e-aplicacoes
2. Zaask, Quanto custa o desenvolvimento de aplicações para mobile?. zaask.pt/quanto-custa/desenvolvimento-aplicacoes-mobile
3. Zaask, Quanto custa uma programadora ou um programador de software?. zaask.pt/quanto-custa/programador
4. Fixando, Preço de Desenvolvimento de Software, consultado a 24 de setembro de 2026. fixando.pt/desenvolvimento-de-software/preco
5. Steve McConnell, Software Development's Cone of Uncertainty, Construx Software, 2010. construx.com, Cone of Uncertainty (PDF)
6. Martin Fowler, Fixed Price, martinfowler.com, 2003. martinfowler.com/bliki/FixedPrice.html
7. U.S. Government Accountability Office, Information Technology: Agencies Need to Plan for Modernizing Critical Decades-Old Legacy Systems, GAO-25-107795, 2025. gao.gov/products/gao-25-107795
8. Stripe e Harris Poll, The Developer Coefficient, 2018. stripe.com, The Developer Coefficient (PDF)
9. Bent Flyvbjerg e Alexander Budzier, Why Your IT Project May Be Riskier Than You Think, Harvard Business Review, 89(9), 2011, pp. 23-25. arxiv.org/abs/1304.0265
10. Decreto-Lei n.º 252/94, de 20 de outubro, proteção jurídica dos programas de computador, artigo 3.º (versão atualizada). pgdlisboa.pt, DL n.º 252/94