Como escolher uma software house para software sob medida: critérios e checklist

Escolha uma software house que entenda o seu problema antes de orçar, que aceite garantir em contrato a propriedade do código-fonte, que explique com clareza o modelo de contratação e que tenha um plano de suporte depois da entrega. Portfólio verificável, cadência de comunicação e cuidado com segurança e LGPD completam os critérios. A LOOP Tecnologia trabalha de forma consultiva, com diagnóstico antes da execução — e este guia lista o que verificar em qualquer fornecedor, inclusive nela.

Por LOOP Tecnologia · atualizado em 24 de outubro de 2026

Por que o diagnóstico antes do orçamento é o critério mais importante?

Porque uma proposta só é tão boa quanto o entendimento do problema que está por trás dela. Uma software house que orça sem perguntar sobre processo, usuários e sistemas existentes está precificando uma suposição.

Na primeira conversa, observe quem faz as perguntas. Um parceiro sério quer saber qual resultado de negócio o software precisa gerar, quem vai usá-lo, quais sistemas já existem, quais dados serão migrados e quais são as restrições de prazo e orçamento. Ele também pode sugerir não desenvolver algo, se uma ferramenta pronta resolver melhor.

Projetos maiores costumam começar com uma etapa formal de diagnóstico (também chamada de discovery ou imersão), que entrega mapa de processo, escopo priorizado, arquitetura proposta e estimativa fundamentada. Mesmo quando essa etapa é cobrada, ela costuma sair mais barata do que descobrir no meio do desenvolvimento que o escopo estava errado.

Quem fica com o código-fonte e a propriedade intelectual?

Isso é definido pelo contrato, e você deve exigir que ele preveja a cessão dos direitos patrimoniais sobre o software desenvolvido e a entrega do código-fonte. Sem isso, a empresa pode pagar pelo sistema e não ser dona dele.

Ao revisar a proposta e a minuta de contrato, verifique pontos concretos:

Cláusula de cessão dos direitos patrimoniais do software para a contratante, e em que momento ela ocorre (por exemplo, a cada pagamento ou ao final).
Acesso ao repositório de código desde o início do projeto, de preferência em uma conta da própria empresa.
Entrega de documentação técnica, scripts de implantação e credenciais de infraestrutura.
Identificação de componentes de terceiros e bibliotecas de código aberto usados, com suas licenças.
Tratamento de componentes reutilizáveis que a software house já possuía antes do projeto: o que fica com quem.

Esses cuidados não são desconfiança: eles garantem que você possa trocar de fornecedor, internalizar o time ou contratar uma auditoria sem depender de quem escreveu o código. Para contratos de valor relevante, vale a revisão de um advogado.

Escopo fechado, por hora ou squad dedicado: qual modelo de contratação escolher?

Escopo fechado funciona quando o que será construído está bem definido; contratação por hora (time & materials) funciona quando o escopo vai evoluir; squad dedicado funciona para produtos em evolução contínua. O modelo errado para o tipo de projeto gera atrito, aditivos ou desperdício.

Comparativo entre modelos de contratação de software house
Modelo	Como funciona	Melhor para	Riscos	O que exigir
Escopo fechado	Preço e prazo definidos para um escopo descrito em detalhe	Projetos com requisitos claros e pouca incerteza	Mudanças viram aditivos; o fornecedor pode embutir margem de risco no preço	Escopo por escrito, critérios de aceite e regra clara para mudanças
Por hora (time & materials)	Paga-se pelo esforço efetivamente realizado, com priorização contínua	Projetos com incerteza, MVPs e evolução de sistemas existentes	Custo final menos previsível se não houver acompanhamento	Relatórios de horas, entregas frequentes e teto de orçamento por período
Squad dedicado	Um time fixo (desenvolvimento, design, qualidade, gestão) trabalha para você por período	Produtos digitais com roadmap contínuo e alta demanda	Custo mensal fixo mesmo em períodos de menor demanda	Composição do time por escrito, metas por ciclo e regras para substituição de pessoas

Também é comum combinar modelos: um diagnóstico com escopo fechado, seguido de desenvolvimento por hora ou squad. Mais importante do que o rótulo é entender como mudanças de escopo são tratadas e como você acompanha o que está sendo entregue.

Como avaliar o portfólio e as referências de uma software house?

Procure projetos parecidos com o seu em complexidade e tipo — não necessariamente no mesmo setor — e converse com clientes reais. Um portfólio bonito mostra telas; uma referência mostra como foi trabalhar junto.

Peça para ver sistemas em funcionamento, não apenas imagens de layout.
Pergunte sobre projetos com integrações, migração de dados ou sistemas legados, se esse for o seu caso.
Ao falar com referências, pergunte o que deu errado e como a software house reagiu — isso diz mais do que elogios.
Verifique há quanto tempo os clientes citados continuam com o fornecedor após a primeira entrega.

Como deve ser a comunicação durante o projeto?

Deve ter cadência combinada, um responsável claro de cada lado e entregas que você consegue ver e testar com frequência. Se você só enxerga o sistema no final, o risco de surpresa é alto.

Combine antes de começar: quem é o ponto de contato, com que frequência há reuniões de acompanhamento, onde ficam registradas as decisões e como você acessa um ambiente de homologação para testar o que foi feito. Pergunte também como a software house comunica atrasos e riscos — a resposta revela muito sobre a cultura da empresa.

Do seu lado, reserve tempo de alguém que conheça o processo para validar entregas. Nenhum fornecedor consegue compensar a ausência de quem decide.

O que verificar sobre segurança, LGPD e suporte após a entrega?

Verifique como o fornecedor protege acessos, código e dados durante o projeto, como trata dados pessoais conforme a LGPD e o que acontece depois do go-live: quem corrige falhas, em quanto tempo e a que custo.

Segurança e LGPD

Pergunte como são gerenciados acessos ao código e aos ambientes, se dados reais de produção são usados em testes, como são guardadas senhas e chaves, e se há revisão de código. Se o sistema tratar dados pessoais, o contrato deve definir os papéis de cada parte na LGPD e as obrigações em caso de incidente.

Suporte, sustentação e SLA

Software em produção precisa de manutenção: correções, atualizações de dependências, ajustes de infraestrutura e pequenas evoluções. Exija por escrito o período de garantia, o canal de atendimento, os tempos de resposta por nível de criticidade (o SLA) e como serão cobradas as evoluções depois da entrega.

Checklist para comparar software houses

Use a lista abaixo para comparar propostas lado a lado. Um fornecedor que não consegue responder com clareza a vários itens provavelmente não é a melhor escolha para um software sob medida.

Fez perguntas sobre o negócio, os usuários e os sistemas atuais antes de enviar preço.
Propõe uma etapa de diagnóstico ou explica como o escopo foi levantado.
Escopo, entregas e critérios de aceite estão descritos por escrito.
O contrato prevê cessão dos direitos patrimoniais e entrega do código-fonte.
O código fica em repositório ao qual a empresa tem acesso desde o início.
O modelo de contratação está claro, incluindo como mudanças de escopo são tratadas.
Há cadência de acompanhamento, ponto de contato definido e ambiente de homologação.
Apresentou projetos comparáveis e clientes que aceitam conversar como referência.
Explicou práticas de segurança e o tratamento de dados pessoais conforme a LGPD.
Garantia, suporte e SLA pós-entrega estão definidos por escrito.
Documentação técnica e implantação fazem parte da entrega.

Sinais de alerta

Alguns comportamentos merecem atenção redobrada antes de assinar:

Preço fechado enviado depois de uma única conversa curta, sem escopo escrito.
Resistência em colocar a propriedade do código no contrato ou em dar acesso ao repositório.
Promessa de prazo muito mais curto que o dos demais fornecedores, sem explicação de como.
Nenhuma pergunta sobre como o sistema será mantido depois do lançamento.
Portfólio apenas com imagens, sem possibilidade de ver sistemas reais ou falar com clientes.
Concordância com tudo o que é pedido, sem nenhum questionamento ou alternativa.

Perguntas frequentes

Software house ou freelancer: qual escolher?

Freelancers podem funcionar bem para tarefas pontuais e bem delimitadas. Para sistemas que sustentam processos críticos, uma software house tende a oferecer mais continuidade, papéis complementares (desenvolvimento, design, qualidade, gestão) e capacidade de suporte depois da entrega.

Devo escolher a proposta de menor preço?

Só se as propostas estiverem comparando a mesma coisa. Diferenças grandes de preço costumam indicar escopos interpretados de formas diferentes, ausência de testes, documentação ou suporte, ou margens de risco. Compare item por item antes de comparar o valor final.

O que é a fase de diagnóstico (discovery) e preciso pagar por ela?

É a etapa em que processo, usuários, integrações e prioridades são mapeados antes do desenvolvimento. Algumas empresas cobram por ela, outras incluem no projeto; o importante é que ela exista e que o resultado seja entregue a você por escrito.

Posso trocar de software house no meio do projeto?

Pode, desde que você tenha acesso ao código-fonte, à documentação e aos ambientes. É por isso que esses itens devem estar garantidos em contrato desde o início, e não negociados no momento da troca.

Uma software house de outra cidade consegue atender bem?

Sim, desde que haja cadência de comunicação clara, ferramentas de acompanhamento e disponibilidade para encontros presenciais quando o projeto exigir, como em etapas de diagnóstico ou implantação.