# 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)?](https://www.mestersegesintelligenciakozpont.hu/pt/base-de-conhecimento/software-a-medida-ou-solucao-pronta) 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?](https://www.mestersegesintelligenciakozpont.hu/pt/base-de-conhecimento/pontos-de-funcao-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](https://www.mestersegesintelligenciakozpont.hu/pt/precos).

## 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](https://njt.hu/jogszabaly/1999-76-00-00), 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](https://eur-lex.europa.eu/legal-content/PT/TXT/?uri=CELEX:32016R0679)). 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](https://owasp.org/www-project-top-ten/), 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](https://www.mestersegesintelligenciakozpont.hu/pt/como-trabalhamos), e o método de definição de preços na página [Preços](https://www.mestersegesintelligenciakozpont.hu/pt/precos).

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](https://www.mestersegesintelligenciakozpont.hu/pt/o-nosso-trabalho), sobre a empresa pode ler na página [Sobre nós](https://www.mestersegesintelligenciakozpont.hu/pt/sobre-nos), e as perguntas frequentes têm resposta na página [Perguntas frequentes](https://www.mestersegesintelligenciakozpont.hu/pt/perguntas-frequentes). Se procura uma empresa de desenvolvimento, escreva-nos através dos contactos indicados na página [Contacto](https://www.mestersegesintelligenciakozpont.hu/pt/contacto).

## Fontes

- [Base de dados legislativa nacional da Hungria (Nemzeti Jogszabálytár): Lei LXXVI de 1999 sobre os direitos de autor (em húngaro)](https://njt.hu/jogszabaly/1999-76-00-00)
- [EUR-Lex: Regulamento (UE) 2016/679 (Regulamento Geral sobre a Proteção de Dados, RGPD)](https://eur-lex.europa.eu/legal-content/PT/TXT/?uri=CELEX:32016R0679)
- [OWASP: OWASP Top 10](https://owasp.org/www-project-top-ten/)
- [OWASP: OWASP Top 10:2025](https://top10.owasp.org/2025/)