Como escolher uma empresa de desenvolvimento de software?
Segundo a Mesterséges Intelligencia Központ Kft., empresa de desenvolvimento de software de Budapeste, uma boa escolha depende de três perguntas: se o fornecedor compreende o objetivo, se a sua proposta pode ser verificada, e de quem serão o código e o sistema após a entrega.
Em resumo: comece por descrever o objetivo e os requisitos obrigatórios, e só depois peça propostas. Vale a pena pedir para ver trabalho em funcionamento, um processo transparente e acesso ao código; as propostas devem ser comparadas com base na mesma especificação item a item, de preferência pelo tamanho medido. No contrato, devem ficar também definidos o código-fonte e os direitos de utilização, a confidencialidade, a correção de erros, a operação e a forma de saída.
Primeiro o objetivo: o que tem o software de fazer?
A maior parte das más escolhas não começa no fornecedor, mas numa encomenda vaga. Se não estiver escrito o que o software tem de fazer, cada proposta significará uma coisa diferente, e não haverá referência para avaliar nem o preço, nem o trabalho concluído. Não é preciso uma especificação pronta (um bom fornecedor ajuda a escrevê-la), mas vale a pena pensar previamente em algumas coisas:
- Objetivo: que problema resolve o software, e como se vai perceber que foi bem-sucedido.
- Utilizadores: quem o vai usar, sejam colaboradores internos, clientes ou parceiros.
- Requisitos obrigatórios: aquilo sem o qual não pode arrancar, separado dos itens «seria bom ter».
- Sistemas existentes: a que tem de se ligar (ERP, CRM, loja online, faturação, banco).
- Dados: que dados trata, incluindo dados pessoais.
- Condicionantes: se há um prazo fixo, regras internas, ou requisitos de alojamento ou de segurança.
Vale a pena decidir também se é de todo necessário um desenvolvimento à medida, ou se basta um produto pronto, eventualmente um produto pronto com uma extensão à medida. O artigo Software à medida ou solução pronta (SaaS)? ajuda nisso.
Lista restrita: a quem vale a pena contactar?
Não é preciso contactar muitas empresas; alguns candidatos escolhidos com cuidado são melhores do que muitas propostas superficiais. Critérios para a seleção:
- Trabalho semelhante: se já construiu um sistema de dimensão e natureza semelhantes (software empresarial, loja online, aplicação móvel, integração de IA).
- Adequação tecnológica: se trabalha com as tecnologias a que os sistemas existentes se têm de ligar.
- Escala: se a capacidade da empresa é adequada ao projeto; um sistema grande precisa de várias especialidades, uma tarefa pequena, de menos.
- Língua e disponibilidade: se consegue comunicar na sua língua e no seu fuso horário.
Verificar trabalhos e referências
A prova mais forte é o software em funcionamento. Peça aos candidatos que mostrem um sistema que se possa experimentar, e que expliquem exatamente qual foi a sua parte nele. Muitos trabalhos para clientes estão protegidos por confidencialidade, por isso nem sempre é possível dar nomes. Nesse caso, uma descrição anonimizada, uma demonstração ou os produtos próprios da empresa também dizem muito.
Se um antigo cliente der uma referência, vale a pena fazer perguntas concretas: se o âmbito acordado foi respeitado, como foram tratadas as alterações e os erros, se o cliente recebeu o código-fonte e se ainda trabalham juntos. Um «ficámos satisfeitos» genérico diz pouco; o facto de o cliente continuar a operar o sistema com eles após a entrega diz muito.
Conversa técnica
Vale a pena ter uma conversa técnica com cada candidato, de preferência com a presença de um técnico também do seu lado. O que conta não é a segurança com que as respostas são dadas, mas se o candidato faz perguntas e identifica os riscos. Boas perguntas:
- Como abordariam o trabalho, e qual seria a primeira etapa?
- Como ligariam os nossos sistemas existentes, e o que precisam de saber sobre eles?
- Como testam, e quem decide que uma parte está concluída?
- Quem vai trabalhar no projeto, e quem será a nossa pessoa de contacto?
- Onde vai funcionar o sistema, e quem é responsável pelas atualizações de segurança?
- Se houver também inteligência artificial: que dados vão para onde, e o que acontece quando a IA se engana?
É um sinal de alerta se um candidato indicar um preço e um prazo exatos logo após a primeira conversa, sem fazer perguntas.
Processo e comunicação
No desenvolvimento de software, as surpresas raramente nascem no código; nascem muito mais na comunicação. Por isso, vale a pena perguntar como poderá acompanhar o progresso ao longo do caminho. Sinais de boas práticas:
- Desenvolvimento por etapas: o trabalho divide-se em etapas, e no fim de cada uma é apresentado software em funcionamento, e não apenas um relatório.
- Acesso ao código: o cliente vê o repositório de código desde o primeiro dia, e não o recebe apenas na entrega.
- Lista de tarefas rastreável: as tarefas, os erros e as alterações são visíveis num registo comum.
- Pessoa de contacto permanente: há uma pessoa que conhece o projeto e pode tomar decisões.
- Gestão de alterações: a necessidade nova ou alterada é descrita, medida ou estimada, e só entra no trabalho após aprovação.
Comparar as propostas
Duas propostas só podem ser comparadas se disserem respeito ao mesmo âmbito. Por isso, todos os candidatos devem receber a mesma descrição item a item, e vale a pena perguntar-lhes para que funções e para que tamanho apresentaram o preço. Se o proponente medir o tamanho funcional do software com um método normalizado, por exemplo em pontos de função COSMIC, o tamanho pode ser verificado a partir da mesma especificação; o método é apresentado no artigo O que é um ponto de função COSMIC?.
Se a diferença entre duas propostas for grande, vale a pena fazer estas perguntas:
| Pergunta | O que revela |
|---|---|
| Para que tamanho e para que funções é o preço? | se orçamentaram o mesmo âmbito |
| O que aparece como item à parte? | se a integração, a migração de dados, os gráficos e a operação estão incluídos |
| Que requisitos não funcionais tiveram em conta? | desempenho, segurança, acessibilidade |
| Como tratam as alterações? | o que acontece se surgir uma nova necessidade pelo caminho |
| Como funciona a correção de erros após a entrega? | o que está incluído no preço, e o que conta como trabalho extra |
| De quem será o código-fonte, e que direitos recebemos? | se o sistema pode ser continuado por outra empresa |
| A faturação é a preço fixo ou com base no esforço? | quem suporta o risco do âmbito |
O preço fixo funciona bem quando o âmbito está fixado item a item; a faturação com base no esforço é mais flexível, mas o risco do âmbito fica do lado do cliente. Em ambos os casos, o que importa é que o âmbito possa ser medido e acompanhado. A forma como definimos os preços está descrita na página Preços.
Os pontos essenciais do contrato
O contrato é o que conta em caso de litígio ou de uma situação inesperada. O que se segue é informação, não aconselhamento jurídico: vale a pena pedir também a um jurista que reveja o contrato.
Código-fonte e direitos de utilização
A lei húngara dos direitos de autor (Lei LXXVI de 1999, Szjt.; texto em húngaro) protege os programas de computador, tanto em código-fonte como em código objeto, como obras protegidas por direitos de autor (§ 1, n.º 2, alínea c)), e estabelece que os direitos patrimoniais sobre o software são transmissíveis (§ 58, n.º 3). Assim, o cliente ou adquire os direitos patrimoniais, ou recebe uma autorização de utilização (licença); as duas coisas não são iguais.
Algumas regras que tornam importante uma redação precisa: o contrato de utilização só confere um direito exclusivo se tal for expressamente estipulado (§ 43, n.º 1); se o contrato não indicar os modos e a extensão da utilização, a autorização limita-se à medida indispensável para a finalidade do contrato (§ 43, n.º 5); se o conteúdo não for inequívoco, prevalece a interpretação mais favorável ao autor (§ 42, n.º 3); e o utilizador só pode conceder uma autorização a terceiros com a autorização expressa do autor (§ 46, n.º 1). Por isso, vale a pena estipular:
- a entrega do código-fonte completo e da documentação, também por etapas;
- se o cliente adquire os direitos patrimoniais, ou que autorização recebe e com que extensão (se é exclusiva, se permite modificações, se é transmissível);
- que o fornecedor detém os direitos sobre o código escrito pelos seus colaboradores e subcontratados;
- a lista e as licenças dos componentes de código aberto e de terceiros utilizados.
Confidencialidade (NDA)
Se a ideia ou os dados de negócio forem confidenciais, vale a pena celebrar um acordo de confidencialidade (NDA) antes de entrar em pormenores. Defina nele o que conta como informação confidencial, quem pode ter acesso a ela, quanto tempo dura a confidencialidade e o que acontece aos materiais no fim do trabalho.
Correção de erros e garantia
O contrato deve dizer o que conta como erro (um desvio em relação ao requisito acordado), como decorre o teste de aceitação, que níveis de gravidade existem e com que rapidez o fornecedor reage a cada nível. Defina também durante quanto tempo o fornecedor corrige gratuitamente os erros que estavam ocultos no momento da entrega, e o que já conta como evolução.
Operação e SLA
Se o fornecedor continuar a operar o sistema após a entrega, um acordo de nível de serviço (service level agreement, SLA) fixa as condições: a disponibilidade garantida, a forma de comunicar incidentes, os tempos de resposta e de resolução por gravidade, as janelas de manutenção, as cópias de segurança e os relatórios. O que não estiver escrito não pode ser exigido numa situação de litígio.
Plano de saída
O plano de saída responde à pergunta sobre o que acontece se a colaboração com o fornecedor não continuar, seja por insatisfação, seja porque o fornecedor deixou de existir. Os seus elementos:
- documentação atualizada sobre a instalação, a arquitetura e a operação;
- o repositório de código, o alojamento, o domínio e as contas na nuvem em nome do cliente ou, pelo menos, com acesso do cliente;
- regras para a entrega das palavras-passe e das chaves de acesso;
- a possibilidade de exportar os dados num formato normalizado;
- colaboração na passagem do sistema para um novo fornecedor.
Proteção de dados: o contrato de subcontratação
Se o fornecedor tiver acesso a dados pessoais durante o trabalho (por exemplo, porque opera o sistema ou faz testes com dados reais), nos termos do RGPD é tipicamente considerado subcontratante, e é necessário celebrar com ele um contrato de subcontratação por escrito (artigo 28.º do RGPD). Este tem de estipular, entre outros aspetos, que o fornecedor só trata os dados mediante instruções documentadas do cliente, assegura a confidencialidade e a segurança, só recorre a outro subcontratante com autorização, apaga ou devolve os dados no fim da prestação do serviço e permite auditorias.
Práticas de segurança
A segurança não pode ser acrescentada ao software depois, por isso vale a pena perguntar como o fornecedor trabalha com ela. Um bom ponto de partida é o OWASP Top 10, uma lista amplamente conhecida dos riscos de segurança mais críticos das aplicações web; a edição em vigor é a OWASP Top 10:2025 (verificado em 17 de outubro de 2026). Os três primeiros lugares são ocupados pelo controlo de acessos deficiente, pela configuração de segurança incorreta e pelas falhas na cadeia de fornecimento de software. Pergunte:
- Como gerem as permissões, e como testam que um utilizador só vê os seus próprios dados?
- Como atualizam as bibliotecas externas que utilizam, e como sabem se uma delas tem uma vulnerabilidade?
- Onde guardam as palavras-passe e as chaves, e quem tem acesso a elas?
- Há revisão de código (code review) e testes automáticos?
- Como são feitas as cópias de segurança, e já experimentaram restaurá-las?
Freelancer ou empresa de desenvolvimento?
Ambos podem ser uma boa escolha; a questão é a dimensão da tarefa e o tempo de vida do sistema.
| Critério | Freelancer | Empresa de desenvolvimento |
|---|---|---|
| Comunicação | direta, com uma pessoa | através de uma pessoa de contacto, com vários especialistas |
| Especialidades | os conhecimentos de uma pessoa | várias especialidades: interface, backend, mobile, operação, testes |
| Substituição | em caso de doença ou saída, o trabalho para | os membros da equipa conseguem substituir-se uns aos outros |
| Capacidade | para tarefas mais pequenas e bem delimitadas | para sistemas maiores e trabalho em paralelo |
| Contrato | diretamente com o especialista | com a empresa, que responde pelo trabalho da equipa |
| Operação a longo prazo | depende da disponibilidade do freelancer | pode ser assegurada de forma organizada |
Um freelancer adequa-se a uma tarefa bem delimitada, sobretudo se o cliente tiver um responsável técnico próprio que dirija e receba o trabalho. Se o sistema fizer parte do funcionamento diário da empresa, exigir várias especialidades e for funcionar durante anos, uma empresa de desenvolvimento representa, normalmente, um risco menor. O plano de saída e a entrega do código-fonte são igualmente importantes em ambos os casos.
Sinais de alerta
- Preço e prazo exatos logo após a primeira conversa, sem perguntas.
- Não há especificação escrita, ou a proposta não diz a que se refere.
- O cliente não pode ver o código, e só o receberia na entrega.
- Resposta vaga sobre quem vai trabalhar no projeto.
- Não é claro de quem será o código-fonte nem que direitos recebe o cliente.
- Recusa em assinar um contrato de subcontratação ou um acordo de confidencialidade.
- Não há trabalho em funcionamento para mostrar.
Lista de verificação
| Pergunta | Está bem se |
|---|---|
| O objetivo e os requisitos obrigatórios estão escritos? | existe uma descrição curta, entendida da mesma forma por todos |
| Vimos trabalho em funcionamento? | experimentámos pelo menos um sistema semelhante |
| Compreendem a tarefa? | fizeram perguntas e identificaram os riscos |
| Vamos ver o progresso? | demonstrações por etapas, acesso ao repositório de código |
| A proposta é comparável? | refere-se ao mesmo âmbito item a item, e os itens à parte são visíveis |
| A questão do código-fonte e dos direitos está resolvida? | o contrato menciona a entrega e a extensão dos direitos |
| Há acordo de confidencialidade e contrato de subcontratação? | foram assinados onde é necessário |
| A correção de erros e a operação estão definidas? | níveis de gravidade, tempos de resposta, SLA |
| Há um plano de saída? | documentação, acessos, exportação de dados |
| Perguntámos sobre a segurança? | respostas concretas sobre permissões, atualizações e cópias de segurança |
Perguntas frequentes
Freelancer ou empresa de desenvolvimento?
Para uma tarefa mais pequena e bem delimitada, um freelancer experiente também pode ser uma boa escolha, sobretudo se a empresa tiver um responsável técnico próprio. Se o sistema fizer parte do funcionamento diário, exigir várias especialidades e for funcionar durante muito tempo, uma empresa de desenvolvimento representa um risco menor, porque o trabalho não depende de uma única pessoa.
Como comparar duas propostas?
Só são comparáveis as propostas apresentadas para a mesma especificação item a item. Pergunte a ambos os proponentes para que tamanho e para que funções apresentaram o preço, o que aparece como item à parte e como tratam as alterações. Se o tamanho tiver sido medido com um método normalizado, por exemplo em pontos de função COSMIC, pode ser verificado a partir da mesma especificação.
O que deve constar do contrato?
O âmbito (a especificação item a item), o preço e o calendário, a entrega do código-fonte e a extensão dos direitos de utilização, a confidencialidade, as regras de aceitação e de correção de erros, a operação e o SLA, o plano de saída e, se estiverem envolvidos dados pessoais, o contrato de subcontratação. Trata-se de informação, não de aconselhamento jurídico.
O que acontece se o fornecedor desaparecer?
Se o código-fonte, a documentação e os acessos estiverem com o cliente, outro fornecedor pode assumir o sistema. Por isso, vale a pena ver o repositório de código desde o primeiro dia, manter o alojamento e o domínio em nome próprio e fixar um plano de saída no contrato. Se isto faltar, a continuação do sistema pode ser difícil e lenta.
De quem será o código-fonte?
De quem o contrato determinar: segundo a lei húngara dos direitos de autor, os direitos patrimoniais sobre o software são transmissíveis, mas isso não é automático. Vale a pena estipular no contrato que o cliente recebe o código-fonte completo e que direitos exatamente adquire sobre ele. Connosco, o código-fonte e os direitos de utilização também se regem pelo contrato.
Como podemos ajudar?
Trabalhamos assim: a primeira consulta é gratuita, escrevemos a especificação em conjunto, medimos o tamanho do software em pontos de função COSMIC, e a partir dele elaboramos a proposta e o calendário. O desenvolvimento avança por etapas, com uma demonstração no fim de cada uma; a pedido, assinamos um acordo de confidencialidade (NDA) e, após a entrega, asseguramos também a operação e a manutenção. O código-fonte e os direitos de utilização regem-se pelo contrato. Os passos estão descritos na página Como trabalhamos, e o método de definição de preços na página Preços.
Neste momento, estamos a desenvolver um grande sistema ERP e CRM; os nossos próprios desenvolvimentos, que podem ser experimentados, são apresentados na página O nosso trabalho, sobre a empresa pode ler na página Sobre nós, e as perguntas frequentes têm resposta na página Perguntas frequentes. Se procura uma empresa de desenvolvimento, escreva-nos através dos contactos indicados na página Contacto.