Como escolher uma empresa de desenvolvimento de software

Contratar desenvolvimento de software é uma decisão difícil por um motivo específico: quem contrata frequentemente não tem repertório técnico para avaliar o que está comprando, e o resultado só aparece meses depois. Este texto é uma lista de critérios que funcionam mesmo sem formação técnica.

1. Portfólio que dá para verificar

Não basta ver telas bonitas numa apresentação. Peça para acessar sistemas em produção, falar com clientes anteriores e ver um projeto que deu errado — e ouvir o que a empresa aprendeu com ele.

Empresa que nunca teve um projeto difícil ou nunca teve um cliente insatisfeito ou está mentindo, ou entregou pouco. A pergunta reveladora é: “me conte de um projeto que saiu do prazo e o que vocês fizeram”. A qualidade da resposta diz mais do que o portfólio inteiro.

2. Quem realmente vai trabalhar no projeto

O padrão do mercado é vender com o sócio sênior e executar com estagiário. Pergunte com nomes:

• Quem é o líder técnico e quantos anos de experiência tem?
• Quantas pessoas ficam alocadas e em que percentual do tempo?
• Essas pessoas estão em outros projetos simultâneos? Quantos?
• Se alguém sair no meio, qual é o plano?

Peça para conversar com o desenvolvedor que vai liderar. Uma conversa de vinte minutos revela mais que qualquer proposta comercial.

3. Processo de trabalho documentado

Uma empresa madura consegue descrever, sem improvisar, como conduz um projeto: como faz o discovery, qual a cadência de entrega, como funciona o code review, quais testes escreve, como faz o deploy e como trata um bug crítico em produção.

Se a resposta for vaga — “somos ágeis”, “usamos Scrum” — sem detalhe concreto, o processo provavelmente não existe.

4. Contrato com escopo e critérios de aceite

O contrato precisa responder, por escrito:

• Escopo: o que está dentro e o que está fora, item a item.
• Critérios de aceite: como se decide que uma entrega está pronta.
• Prazo: com marcos intermediários, não só a data final.
• Mudança de escopo: como se pede, como se precifica, quem aprova.
• Multas e rescisão: o que acontece se qualquer lado quiser sair.

Contrato genérico de duas páginas é um sinal de alerta, não de simplicidade.

5. Propriedade do código-fonte

Este é inegociável. O código, o repositório, a documentação e as credenciais de infraestrutura devem ser do cliente. Cheque no contrato se está escrito.

Existe um modelo comum e problemático em que o fornecedor mantém o código em conta própria e o cliente só recebe acesso ao sistema funcionando. Se a relação azedar, a empresa perde o ativo que pagou para construir. Repositório em nome do cliente desde o primeiro commit é a prática correta.

6. Política de garantia e sustentação

Perguntas objetivas:

• Qual o período de garantia após a entrega?
• O que é bug (coberto) e o que é melhoria (cobrada)?
• Qual o SLA de resposta para uma falha crítica em produção?
• Quanto custa o contrato de sustentação mensal?

Empresa que não separa bug de melhoria com clareza vai gerar discussão em todo chamado.

7. Como a comunicação funciona no dia a dia

Boa parte dos projetos que dão errado não falha por incompetência técnica — falha por comunicação. Avalie:

• Existe um canal direto ou tudo passa por um comercial?
• Com que frequência há demonstração do que foi construído?
• Existe ambiente de homologação acessível a qualquer momento?
• As decisões ficam registradas por escrito?

O melhor indicador de qualidade de comunicação é o comportamento durante a venda. Se demoram três dias para responder um e-mail antes de assinar, vão demorar mais depois.

8. Capacidade de dizer não

Este é o critério mais subestimado. Um bom parceiro técnico discorda quando você pede algo que não faz sentido: questiona uma funcionalidade que ninguém vai usar, avisa que o prazo é irreal, sugere cortar escopo em vez de aceitar tudo com um sorriso.

Fornecedor que concorda com tudo na reunião de venda vai concordar com tudo durante o projeto — inclusive com decisões ruins. Você não está comprando execução; está comprando julgamento técnico.

9. Referências de clientes anteriores

Peça dois contatos e ligue. Perguntas úteis:

• O prazo foi cumprido? Se não, como foi comunicado?
• Houve aditivo de escopo? Por quê?
• Como foi o suporte depois da entrega?
• Você contrataria de novo?

Empresa que hesita em dar referência está dizendo algo.

Sinais de alerta

Em ordem de gravidade:

• Orçamento fechado sem entender o problema. Preço na primeira ligação significa que o escopo não foi compreendido.
• Prazo agressivo demais. Quem promete em seis semanas o que os outros estimam em quatro meses vai entregar outra coisa.
• Resistência a colocar o código em nome do cliente.
• Uso de jargão para encerrar discussão em vez de explicar.
• Nenhuma pergunta sobre o negócio. Fornecedor que só pergunta sobre requisitos técnicos vai construir exatamente o que foi pedido — inclusive os erros.
• Pressão por decisão rápida com desconto que expira.

O teste de uma reunião

Se puder fazer só uma coisa antes de decidir, faça esta: leve o problema — não a solução — para uma reunião de uma hora com cada candidato e observe as perguntas que eles fazem.

Fornecedor fraco pergunta quantas telas e qual tecnologia. Bom fornecedor pergunta quem usa hoje, quanto tempo o processo leva, o que acontece quando dá errado, quantas pessoas dependem disso e como você vai medir se o projeto deu certo.

A qualidade das perguntas na primeira hora prevê a qualidade da entrega no sexto mês melhor do que qualquer portfólio.

---

Se quiser fazer esse teste com a gente, agende uma conversa. E se ainda estiver decidindo entre construir sob medida ou contratar um sistema pronto, veja a comparação entre as duas opções.