Como escolher uma software house: critérios práticos

Três propostas na mesa, três apresentações bonitas, três portfólios com telas caprichadas. Todas prometem qualidade, agilidade e parceria. Na prática, você está escolhendo quem vai carregar uma parte crítica da operação da sua empresa pelos próximos anos, e a apresentação não diz quase nada sobre isso.

Escolher uma software house é menos parecido com comprar um produto e mais parecido com contratar uma equipe. O que importa é como ela trabalha quando o projeto aperta, quando o escopo muda e quando algo quebra em produção. Este texto troca critérios vagos por perguntas que você consegue verificar.

Portfólio bonito não responde o que importa

O portfólio mostra o resultado visual de projetos passados. Ele não mostra se o sistema funcionou bem depois do lançamento, se o cliente conseguiu evoluí-lo, se o prazo foi cumprido, nem quem da equipe que fez aquele trabalho ainda está na empresa.

Use o portfólio para uma coisa só: verificar se o fornecedor já lidou com problemas parecidos com o seu. Sistemas com regras de negócio densas, integração com ERP, operação em campo sem internet, volume alto de transações. Tela bonita qualquer bom designer faz; entender por que a baixa de estoque precisa ser idempotente é outra coisa.

Em seguida, peça para conversar sobre um projeto específico em profundidade. Qual foi a decisão técnica mais difícil? O que deu errado e como resolveram? O que fariam diferente? Quem responde com detalhe concreto provavelmente fez o trabalho. Quem responde com adjetivos, provavelmente não.

Software house, time interno ou os dois

Antes de comparar fornecedores, vale confirmar que contratar fora é a decisão certa.

Software house faz sentido quando:

• o projeto tem começo claro e a empresa não tem, nem quer ter agora, uma equipe de tecnologia;
• é preciso um conjunto de competências (arquitetura, back-end, front-end, mobile, infraestrutura) que seria difícil contratar de uma vez;
• a empresa quer começar rápido e decidir depois se internaliza.

Time interno faz sentido quando:

• o software é o próprio produto da empresa ou a principal vantagem competitiva;
• a evolução será contínua e intensa por muitos anos;
• existe liderança técnica interna capaz de contratar, orientar e reter pessoas.

O modelo híbrido costuma ser o mais saudável para empresas médias: a software house constrói a base e as partes mais complexas enquanto a empresa forma, aos poucos, um núcleo interno. Para funcionar, a transferência de conhecimento precisa ser planejada desde o início, com documentação, revisão de código conjunta e participação do time interno nas decisões, e não deixada para o último mês do contrato.

Pergunte ao fornecedor como ele lidaria com a sua empresa contratando desenvolvedores próprios no meio do caminho. A reação diz muito.

Quem vai escrever o código do seu projeto

É a pergunta mais importante e a menos feita. Quem apresenta a proposta raramente é quem escreve o código. Descubra:

• Quem são as pessoas que vão trabalhar no projeto, com nome e papel. Dá para conversar com elas antes de assinar?
• São funcionários ou terceirizados? Subcontratação não é necessariamente ruim, mas você precisa saber, porque afeta continuidade, confidencialidade e responsabilidade.
• Quanto do tempo delas está dedicado ao seu projeto e quantos outros projetos elas tocam em paralelo.
• O que acontece se alguém sair. Como é feita a substituição e como o conhecimento é preservado.
• Quem toma as decisões de arquitetura e se essa pessoa participa do dia a dia ou só aparece em reunião de início.

Uma equipe pequena, estável e sênior costuma entregar mais do que uma equipe grande com rotatividade alta.

Como você acompanha o andamento: entregas funcionando

Relatório de status com percentual de conclusão não é acompanhamento. "O projeto está 70% pronto" pode significar qualquer coisa, inclusive que nada funciona ainda.

O critério que importa é: com que frequência você vê software funcionando, num ambiente onde pode clicar, testar e errar. Pergunte:

• De quanto em quanto tempo existe uma entrega que eu consigo usar?
• Existe um ambiente de homologação com acesso para a minha equipe?
• Quem do meu lado precisa validar cada entrega, e quanto tempo isso vai tomar?
• Como as prioridades do próximo ciclo são definidas, e quem decide?
• Tenho acesso ao quadro de tarefas e ao repositório durante o projeto, ou só vejo o que me mostram?

Fornecedor que só mostra o sistema no fim é fornecedor que descobre os mal-entendidos no fim. Entregas curtas e frequentes permitem corrigir a rota quando ainda é barato.

Qualidade: testes, revisão de código e ambientes

Você não precisa ser técnico para perguntar sobre qualidade. Precisa só pedir para ver como funciona:

• Testes automatizados. Existem? Cobrem as regras de negócio críticas? Rodam sozinhos a cada mudança?
• Revisão de código. Todo código é revisado por outra pessoa antes de entrar? Isso reduz erros e espalha conhecimento na equipe.
• Ambientes separados. Desenvolvimento, homologação e produção são ambientes diferentes? Dados reais de clientes aparecem em ambiente de teste?
• Publicação automatizada. Colocar uma versão no ar é um processo repetível ou alguém copia arquivos à mão?
• Monitoramento. Como o fornecedor fica sabendo que algo quebrou em produção: pelo alerta ou pelo seu telefonema?
• Segurança e LGPD. Como tratam senhas, dados pessoais, controle de acesso e atualização de dependências?

Peça para ver um exemplo real, mesmo que anonimizado: um pipeline de publicação, um relatório de testes, uma revisão de código. Quem tem processo mostra em minutos.

Como o fornecedor lida com mudança de escopo

O escopo vai mudar. Sempre. Você vai descobrir necessidades novas ao usar as primeiras entregas, e isso é bom. A questão é como o contrato e o fornecedor lidam com isso.

Há dois extremos ruins. No primeiro, o escopo é fechado em detalhe e qualquer mudança vira aditivo, negociação e atraso, o que empurra a empresa a aceitar o que foi especificado mesmo sabendo que está errado. No segundo, não há escopo nenhum, tudo é "a gente vai ajustando", e ninguém sabe quando o projeto termina.

O meio saudável tem três elementos: um objetivo claro por fase, uma lista priorizada que pode ser reordenada, e uma regra explícita de troca, em que incluir algo novo significa decidir o que sai ou vai para a próxima fase. Pergunte ao fornecedor como ele faria isso na prática, com um exemplo.

É também por isso que a etapa anterior ao desenvolvimento importa tanto. Um discovery de software bem feito reduz as surpresas e dá base para uma proposta que faz sentido, e é o momento em que se entende de fato o que determina o investimento num software sob medida.

De quem é o código, e o que acontece depois da entrega

Duas perguntas que precisam de resposta por escrito:

De quem é o código-fonte? O repositório deveria estar na conta da sua empresa desde o primeiro dia, assim como a conta de nuvem, os domínios e as credenciais. O contrato precisa prever a cessão dos direitos patrimoniais. Os detalhes estão em propriedade do código-fonte no contrato.

O que acontece depois do lançamento? Quem corrige um bug crítico num domingo? Em quanto tempo alguém responde? Como evoluções são pedidas e priorizadas? Sistema em produção precisa de sustentação, e o acordo sobre isso deve existir antes do lançamento, não depois do primeiro incidente. O que exigir está em SLA de suporte e sustentação.

Como saber, depois de alguns meses, se a escolha foi boa

A escolha não termina na assinatura. Nos primeiros ciclos, observe sinais concretos:

• Você viu software funcionando com regularidade, e não apenas relatórios de andamento.
• Os problemas chegaram cedo. Um bom fornecedor avisa sobre risco de atraso ou dúvida de requisito assim que percebe, e não na véspera da entrega.
• As estimativas ficaram mais precisas com o tempo, à medida que a equipe conheceu o seu negócio.
• Sua equipe entende o que está sendo construído e participa das decisões, em vez de só receber telas prontas.
• Os erros encontrados em homologação diminuíram de ciclo para ciclo.

Se esses sinais não aparecem, converse cedo. Ajustar a forma de trabalho no começo é muito mais fácil do que trocar de fornecedor no meio do projeto.

Sinais de alerta na primeira conversa

• Proposta fechada sem entender o processo. Se o fornecedor dá prazo e investimento depois de uma reunião de meia hora, ele está chutando, ou vai cortar o que não entendeu.
• Nenhuma pergunta difícil. Bom fornecedor questiona requisitos, aponta riscos e às vezes recomenda não construir algo.
• Tudo é possível e rápido. Sem trade-offs, sem "isso aumenta a complexidade", sem "sugiro deixar para a segunda fase".
• Tecnologia antes do problema. A conversa começa pela stack da moda e não pela sua operação.
• Resistência a colocar o repositório no seu nome.
• Ninguém da equipe técnica participa das conversas antes da assinatura.
• Promessas de resultado de negócio garantido. Software viabiliza resultados; ninguém sério garante números antes de entender a operação.

Checklist para comparar propostas

• Conversei com quem vai escrever o código?
• Sei com que frequência vou ver software funcionando?
• A proposta explica como mudanças de escopo são tratadas?
• Há testes automatizados, revisão de código e ambientes separados?
• O repositório, a nuvem e os domínios ficam no nome da minha empresa?
• O contrato prevê cessão de direitos e entregáveis de transição?
• Existe um modelo de sustentação definido para depois do lançamento?
• O fornecedor apontou riscos e sugeriu cortes, ou só concordou?

Uma conversa antes da proposta

Na Pervian Tech, o primeiro contato é com quem vai de fato desenhar e escrever o seu sistema, não com um vendedor. Trabalhamos com entregas funcionando em ciclos curtos, repositório e infraestrutura no nome do cliente desde o início e sustentação combinada antes do lançamento. Veja como conduzimos projetos de desenvolvimento web sob medida.

Cada projeto é sob medida, e o investimento é definido sob consulta, depois de um diagnóstico inicial gratuito em que entendemos o problema antes de propor qualquer coisa. Se você está comparando fornecedores, fale com a gente e traga as perguntas deste texto.