Empresa de software no Porto: como avaliar propostas
Critérios objetivos para comparar propostas de empresas de software no Porto, com a lista de itens que tornam orçamentos comparáveis e os sinais de risco.
Propostas de software com valores muito diferentes estão quase sempre a orçamentar âmbitos diferentes. Para comparar a sério, envie o mesmo documento de requisitos a todos os candidatos e exija resposta item a item, módulos, integrações, RGPD, garantia e titularidade do código.
Se recebeu três propostas para o mesmo sistema e os valores variam para o dobro ou o triplo, a explicação raramente é que um fornecedor é caro e outro barato. É que estão a orçamentar coisas diferentes. O Porto tem um mercado de software maduro, com fornecedores competentes em vários portes, e é exatamente por isso que a comparação exige método.
Este texto dá esse método: o que enviar aos candidatos, o que exigir de cada proposta e onde estão os sinais de risco.
Comece por enviar o mesmo documento a todos
Antes de pedir orçamento, escreva um documento de requisitos único. Não precisa de ser técnico. Precisa de conter:
- O processo atual, descrito como funciona na prática, não como devia funcionar.
- Volumes: quantos utilizadores, quantas transações por dia, que dimensão de base de dados.
- Funcionalidades esperadas, separadas entre primeira entrega e fases seguintes.
- Integrações necessárias, com o nome dos sistemas: ERP, faturação certificada, pagamentos, APIs de terceiros.
- Perfis de utilizador e níveis de permissão.
- Requisitos de dados pessoais: que categorias, de quem, com que finalidade.
- O que está explicitamente fora desta fase.
Este documento faz duas coisas ao mesmo tempo: baixa o preço, porque reduz a incerteza que o fornecedor precifica como risco, e torna as propostas comparáveis.
O que exigir em cada proposta
| Item | O que tem de constar | Se faltar |
|---|---|---|
| Módulos e funcionalidades | Lista nominal por fase | Vai haver discussão sobre o que estava incluído |
| Integrações | Sistemas nomeados, incluídas e excluídas | O custo de integração aparece como extra a meio |
| Migração de dados | Incluída ou não, com volume | Dados reais são sujos; pode custar como um módulo |
| Perfis e permissões | Quantos, com que níveis | Multiplica esforço de teste não orçamentado |
| RGPD | Base legal, minimização, registo de acessos, prazos de conservação | Refazer no fim custa vários múltiplos |
| Alojamento | Onde ficam os dados e com que subcontratantes | Problema de conformidade descoberto tarde |
| Primeira entrega em produção | Data e âmbito concretos | Projeto sem ponto de verificação cedo |
| Fora de âmbito | Processo, preço e prazo | Atrito garantido a meio do projeto |
| Garantia | Duração e definição de defeito | Discussão sobre o que é bug e o que é mudança |
| Custo de operação | Alojamento, licenças, serviços por utilização | A fatura mensal surpreende depois |
| Titularidade | Código, base de dados e credenciais em seu nome | Fica dependente do fornecedor |
A última linha é a que mais importa. Se a resposta não for "o código é seu, no seu repositório, desde o primeiro commit", está a contratar dependência junto com o software.
O que faz o preço subir de verdade
A intuição de quem contrata é contar ecrãs. Não é aí que está o custo.
Regras de negócio e exceções. Um formulário de registo é barato. O mesmo formulário com sete validações, quatro perfis de permissão e um circuito de aprovação custa várias vezes mais. O percurso normal é a menor parte do trabalho.
Integrações. O custo é proporcional à qualidade da documentação do outro lado. Integrar com uma API bem documentada leva dias; com um sistema antigo sem documentação leva semanas.
Migração de dados. Dados reais têm duplicados, campos vazios e formatos inconsistentes. Limpar e migrar é trabalho a sério.
Requisitos não funcionais e indefinição. Registo de quem fez o quê, cifragem, prazos de conservação e tempo de resposta sob carga não aparecem no ecrã e aparecem na fatura. E, acima de tudo, quando o âmbito não está claro, o fornecedor orçamenta o risco.
Sinais de risco numa proposta
Valor global sem discriminação. Um número único, sem decomposição por módulo ou fase, não permite negociar âmbito nem avaliar o que foi assumido.
Prazo exato sem perguntas prévias. Quem dá uma data sem perguntar por volumes, exceções e integrações está a estimar por analogia.
Ausência de riscos identificados. Quem já entregou sistemas sabe onde estes partem. "Não há riscos, é simples" é a pior resposta possível.
Primeira entrega em produção a mais de três meses. Significa financiar três meses de suposições sem validação.
Silêncio sobre RGPD. Num sistema que trata dados pessoais, isto indica que o assunto vai ser tratado à pressa no fim, e caro.
Equipa não nomeada. Em fornecedores de porte médio é comum o sénior aparecer na reunião comercial e desaparecer na execução. Peça nomes e peça para conhecer quem vai escrever o código.
Depois de escolher: como reduzir o risco de execução
Não feche o projeto inteiro de uma vez. Contrate um recorte pequeno e pago, uma integração, um módulo, uma automação, com entrega em quatro a seis semanas.
Por menos de 10% do valor total fica a saber três coisas que nenhuma proposta revela: se a estimativa foi honesta, se a comunicação é clara e o que o fornecedor faz quando algo corre mal. Se as três respostas forem boas, avance para o resto com muito menos incerteza.
Durante a execução, mantenha o mínimo: reunião semanal com agenda, entrega em ambiente de homologação a cada duas ou três semanas e um responsável interno com tempo real alocado e autoridade para decidir regras de negócio em 24 horas. Este último ponto é a causa mais frequente de atraso, e depende inteiramente de si.
Uma nota sobre proteção de dados
Os requisitos de RGPD referidos aqui são técnicos e correntes, minimização, base legal, registo de acessos, prazos de conservação, direitos dos titulares e contrato de subcontratante. Não substituem aconselhamento jurídico. Antes de fechar o desenho do tratamento, sobretudo com categorias especiais de dados, valide com um jurista ou com o encarregado de proteção de dados.
A Retti Tech atende em todo o Brasil e trabalha com clientes em Portugal remotamente. Não temos escritório no Porto e não fingimos ter: o que oferecemos é o mesmo processo que defendemos aqui, âmbito escrito, entregas curtas e código no repositório do cliente desde o primeiro dia.
Perguntas frequentes
Porque é que os orçamentos variam tanto para o mesmo pedido?
Porque cada fornecedor assume coisas diferentes em silêncio. Um orçamenta apenas o percurso normal, outro inclui exceções, permissões, registo de acessos e migração de dados. Sem um documento de requisitos comum, está a comparar coisas distintas.
O que faz um orçamento subir mais do que o esperado?
Regras de negócio e exceções, integrações com sistemas mal documentados, migração de dados reais e requisitos não funcionais como registo de acessos, RGPD e disponibilidade. O número de ecrãs pesa muito pouco.
Devo escolher a proposta mais barata?
Só depois de confirmar que orçamenta o mesmo âmbito. A proposta mais barata costuma ser a que menos pensou no problema, e a diferença aparece em pedidos adicionais durante o projeto. Compare âmbitos primeiro, valores depois.
Tem um processo que consome o time?
Me conta como funciona hoje. Se der para automatizar, eu te digo por onde começar — a conversa de diagnóstico não é cobrada.
Natiam Gabriel é AI Engineer & Full-Stack Developer e fundador da Retti Tech, estúdio de desenvolvimento de software que atende empresas em todo o Brasil. Constrói sistemas web sob medida, automações e integrações, com ou sem inteligência artificial, do levantamento de requisitos até a operação em produção. Mais de 20 empresas usam em produção os sistemas que desenvolveu.