O que perguntar antes de contratar uma software house?

Pergunte como ela define escopo e preço, quem vai escrever o código, com que frequência você verá o sistema funcionando e em nome de quem ficam o repositório e a infraestrutura. Pergunte também sobre testes, documentação e suporte depois da entrega.

De quem é o código-fonte de um sistema encomendado?

Depende do contrato. Por isso ele deve prever a cessão do código-fonte e da propriedade intelectual para a sua empresa após o pagamento, além de manter repositório e contas em nome da empresa desde o início.

É melhor contratar freelancer ou software house?

Freelancer pode funcionar para tarefas pequenas e bem delimitadas. Para um sistema que vai sustentar o negócio, uma empresa com processo, responsável técnico e capacidade de trazer especialistas reduz o risco de o projeto depender de uma única pessoa.

Como contratar uma software house sem cair em armadilha

Para saber como contratar uma software house sem cair em armadilha, olhe menos para o portfólio bonito e mais para quatro coisas: como ela define o escopo, como cobra, quem de fato vai programar e o que acontece com o código no fim. As piores experiências quase sempre vêm de uma dessas quatro estar mal resolvida no contrato.

O preço importa, mas é o último critério, não o primeiro. Uma proposta barata com escopo vago tende a virar uma proposta cara no terceiro mês.

Este guia mostra as armadilhas mais comuns, as perguntas que separam fornecedores sérios dos demais, o que exigir no contrato e um roteiro para conduzir a escolha.

As armadilhas mais comuns na contratação

Antes do checklist, vale conhecer os problemas que ele previne.

Escopo vago e preço "estimado"

A proposta diz "sistema de gestão com módulos de vendas e estoque" e um valor por hora estimado. Sem lista de funcionalidades e critérios de aceite, qualquer coisa pode ser entregue e qualquer coisa pode ser cobrada como extra.

Quem vende não é quem faz

Você conversa com um comercial simpático e um gerente de projeto. O desenvolvimento vai para alguém que você nunca conheceu, às vezes terceirizado de novo. Cada camada adiciona ruído e custo.

Código refém

O sistema fica hospedado na conta do fornecedor, o repositório é dele e o contrato não fala de propriedade intelectual. Se a relação acaba, você fica sem o software que pagou.

Silêncio até a entrega

Três meses sem ver nada funcionando e uma "grande entrega" no fim. Quando o problema aparece, já é tarde e caro para corrigir.

Nenhum plano para depois

O sistema vai para o ar e o fornecedor some. Não há documentação, testes ou alguém para corrigir o primeiro bug em produção.

Critérios para avaliar uma software house

Use estes critérios para comparar candidatas. Nenhum exige conhecimento técnico.

Processo de escopo: ela propõe uma etapa para entender e escrever o escopo antes do preço final? Fornecedor sério quer entender antes de prometer.
Modelo de preço claro: preço fechado por escopo ou por hora, com regras explícitas para mudanças.
Acesso a quem constrói: você fala direto com o engenheiro responsável? Existe uma pessoa técnica do início ao fim?
Entregas frequentes: você vê o sistema funcionando em ambiente de teste desde as primeiras semanas?
Propriedade do código: repositório, domínios e contas de infraestrutura no nome da sua empresa.
Qualidade verificável: testes automatizados, documentação e um time seu (ou outro fornecedor) capaz de assumir.
Comunicação: tempo de resposta definido e um canal direto.
Aderência técnica: experiência no tipo de projeto (web, aplicativo, IA, blockchain) e na stack proposta, explicada em termos que você entende.

Perguntas para fazer ao fornecedor

Leve esta lista para a primeira reunião. As respostas dizem muito, e a forma como respondem também.

Como vocês chegam ao escopo e ao preço? Em quanto tempo eu tenho uma proposta fechada?
O preço é fechado ou por hora? O que acontece se eu quiser mudar algo no meio?
Quem vai escrever o código? Posso conversar com essa pessoa agora?
Com que frequência vou ver o sistema funcionando?
O repositório e a infraestrutura ficam no nome de quem?
Que tipo de teste vocês fazem? O código vem documentado?
Como é a transição para produção? Existe suporte nas primeiras semanas?
Se daqui a um ano eu quiser levar o sistema para outro time, o que eu recebo?
Qual foi um projeto que deu errado e o que vocês mudaram depois?

A última pergunta é a mais reveladora. Todo fornecedor já teve problema; o que importa é se ele reconhece e aprendeu.

Preço fechado ou por hora

Os dois modelos funcionam quando bem usados. A diferença está em quem carrega o risco.

Aspecto	Preço fechado por escopo	Por hora (time and materials)
Previsibilidade de custo	Alta	Baixa
Flexibilidade para mudar	Mudanças viram aditivo ou trocam de lugar com outro item	Alta, cada mudança só soma horas
Quem carrega o risco de atraso	Fornecedor	Cliente
Exige escopo bem definido	Sim	Não necessariamente
Melhor para	MVPs e projetos com objetivo claro	Evolução contínua, pesquisa, produto maduro

Para a primeira versão de um sistema ou aplicativo, preço fechado costuma proteger melhor o cliente, desde que o escopo esteja escrito com clareza. O artigo sobre escopo de projeto de software mostra o que esse documento precisa ter.

O que exigir no contrato

Um bom contrato de desenvolvimento não precisa ser longo, mas precisa cobrir:

Escopo anexado, com a lista de funcionalidades e os critérios de aceite de cada uma.
Cronograma com marcos e o que é entregue em cada um.
Forma de pagamento atrelada às entregas, não só ao calendário.
Cessão do código-fonte e da propriedade intelectual para a sua empresa após o pagamento.
Contas e acessos em nome da empresa: repositório, nuvem, domínio, lojas de aplicativo.
Processo de mudança de escopo: como é pedido, estimado e aprovado.
Garantia para correção de defeitos depois da entrega, com prazo definido.
Confidencialidade e tratamento de dados, incluindo o que cada parte faz com dados pessoais.
Saída: o que acontece se uma das partes quiser encerrar antes do fim.

Se o fornecedor resiste a algum desses pontos, especialmente à propriedade do código, considere isso um alerta sério.

Um roteiro de contratação em seis passos

Escreva o problema em uma página. O que precisa ser resolvido, para quem, quais sistemas existem hoje e o que é essencial. Se ainda está em dúvida entre construir e comprar, leia software sob medida vale a pena?.
Converse com três fornecedores. Mais que isso vira trabalho demais para comparar; menos, falta referência.
Use a mesma lista de perguntas com todos. Anote as respostas lado a lado.
Peça uma proposta com escopo, prazo e preço. Compare primeiro o escopo. Preços diferentes quase sempre significam escopos diferentes.
Converse com quem vai construir. Uma hora de conversa técnica mostra se a pessoa entendeu o problema.
Comece por uma primeira fase pequena. Um MVP ou um módulo. É o jeito mais barato de testar a relação antes de um compromisso maior. Veja o que é MVP.

Sinais de alerta que justificam desistir

Preço muito abaixo das outras propostas, sem explicação de onde vem a diferença.
Promessa de entregar tudo, rápido e barato, sem nenhum corte de escopo.
Recusa em colocar repositório e contas no nome da sua empresa.
Dificuldade em apresentar quem vai programar.
Respostas genéricas a perguntas específicas sobre o seu problema.
Pressão para assinar rápido por causa de "condição especial".

Na hora de escolher

Contratar bem uma software house é mais sobre processo do que sobre sorte. Escopo escrito, preço com regras claras, acesso direto a quem constrói, entregas frequentes e código no seu nome eliminam a maior parte dos riscos.

Na GMS Tech, você fala direto com o engenheiro que constrói, tem um responsável técnico do início ao fim e recebe escopo, prazo e preço fechados na primeira semana. O código é testado, documentado e fica com a sua empresa. Se quiser usar este checklist numa conversa conosco, fale com um engenheiro.