Software house: o que é, quando contratar e como escolher sem se arrepender

Software house é uma empresa que desenvolve software sob encomenda para outras empresas. Ela entende o processo, desenha o sistema, programa, testa, coloca no ar e, quando o contrato prevê, mantém o que entregou. Faz sentido contratar uma quando a sua empresa já decidiu que vale construir e não tem equipe própria para isso.

Escolher bem depende menos do portfólio e mais de duas perguntas. O fornecedor entendeu o seu processo antes de dar preço? O contrato deixa escrito quem fica com o código, as contas e os dados, e quem mantém o sistema depois da entrega? Este guia mostra o que perguntar e o que exigir de qualquer fornecedor. Ele não é orientação jurídica: o contrato deve passar por um advogado.

O que é uma software house

Uma software house cuida do ciclo inteiro de um sistema: levantamento, arquitetura, desenvolvimento, testes, implantação e manutenção. O mesmo tipo de fornecedor também é chamado de empresa de desenvolvimento de software, empresa de software personalizado ou empresa para desenvolver sistema. O que define o fornecedor não é o nome, e sim o que ele assume por escrito. Outros perfis disputam o mesmo projeto:

• Agência digital: foca em marketing, sites e campanhas; sistemas raramente são o centro do trabalho.
• Freelancer: um profissional independente, bom para escopos pequenos e bem delimitados.
• Fábrica de software: o termo costuma designar quem programa a partir de especificações prontas, com o levantamento a cargo de quem contrata.
• Consultoria: diagnostica, recomenda e às vezes acompanha a implantação de um sistema de mercado, sem necessariamente programar.

Antes de comparar preços, confirme em qual perfil cada proposta se encaixa.

Software house, freelancer ou equipe interna

A decisão costuma ficar entre três caminhos. A tabela é um modelo para orientar a conversa, não uma regra.

Opção	Quando serve	Risco principal	Continuidade	Quem responde por falhas
Software house	Projeto com várias frentes (dados, integrações, interface) e empresa sem equipe técnica	Depender do fornecedor sem regra escrita de saída	Depende do contrato de manutenção e da documentação	A empresa contratada, nos termos do contrato e da lei
Freelancer	Escopo pequeno e fechado, protótipo ou ajuste pontual	Conhecimento concentrado em uma pessoa	Frágil: se a pessoa sai, o projeto pode parar	O profissional, nos termos do contrato e da lei
Equipe interna	Software central para o negócio, com mudança constante	Custo fixo e tempo para contratar e reter	Alta, se houver documentação e mais de uma pessoa que conhece o sistema	A própria empresa

Modelo ilustrativo.

Mesmo com o desenvolvimento terceirizado, uma pessoa interna que conhece o processo faz diferença: ela valida entregas e guarda a memória do projeto. Se o ponto de partida é um protótipo montado com IA, o fornecedor entra para dar a ele arquitetura, testes e um responsável (veja o texto sobre vibe coding).

Quando faz sentido contratar

Contratar uma software house é a segunda decisão, não a primeira. Antes, a empresa precisa ter respondido se vale construir, e o guia software sob medida ou SaaS ajuda nessa escolha. Um sinal de que pode valer construir é perceber que você adapta a empresa à ferramenta, e não o contrário.

Também ajuda chegar com uma noção de custo: o texto sobre quanto custa desenvolver um sistema mostra do que o preço é feito. Se o projeto nasce de planilhas que já não dão conta, o guia para transformar planilha em sistema ajuda a organizar o que levar ao fornecedor.

Faz sentido contratar quando o processo está minimamente claro, alguém da empresa responde por ele e há orçamento para construir e para manter. Se a sua empresa não tem equipe para manter o sistema depois, isso entra no contrato desde o começo. Negociar manutenção depois da entrega enfraquece a sua posição, porque a operação já depende do sistema e de quem o conhece.

Antes do preço: houve levantamento?

Um sistema é feito de regras, exceções, perfis de acesso, integrações e dados. Ninguém estima isso com segurança sem entender a operação. Preço sem levantamento é sinal de risco: ou o escopo foi imaginado, ou a margem foi aumentada para cobrir o que ninguém perguntou.

Um levantamento sério pergunta, pelo menos:

• como o processo funciona hoje e onde ele trava;
• quem vai usar o sistema e com que permissões;
• quais sistemas precisam conversar, como ERP, CRM, WhatsApp e bancos;
• quais dados já existem, onde estão e em que estado;
• quais regras têm exceção e quem decide nesses casos.

Na LinieX, essa etapa se chama Diagnóstico e vem antes da proposta; o passo a passo de como funciona a contratação está na página inicial. Com qualquer fornecedor, peça o levantamento por escrito, com escopo, o que ficou fora dele e as premissas. É isso que permite comparar propostas.

O portfólio mostra o que o fornecedor entregou, não como ele cuida do sistema depois. Se puder, converse com um cliente dele sobre suporte, mudanças e acesso ao código.

Código, contas e dados: o que deixar escrito no contrato

Um contrato de desenvolvimento de software é testado de verdade quando a relação termina. É aí que se descobre quem tem as senhas, onde está o código e como tirar os dados. Resolva isso antes de assinar.

Quem fica com o código-fonte

A resposta curta é: depende do contrato. A Lei 9.609/1998, conhecida como Lei do Software, trata do assunto no art. 4º. O texto, conferido no Planalto em 19/09/2026, diz:

“Salvo estipulação em contrário, pertencerão exclusivamente ao empregador, contratante de serviços ou órgão público, os direitos relativos ao programa de computador, desenvolvido e elaborado durante a vigência de contrato ou de vínculo estatutário, expressamente destinado à pesquisa e desenvolvimento, ou em que a atividade do empregado, contratado de serviço ou servidor seja prevista, ou ainda, que decorra da própria natureza dos encargos concernentes a esses vínculos.”

Para quem contrata, há duas leituras práticas. A primeira está no começo da frase: “salvo estipulação em contrário”. O contrato pode dizer outra coisa, e por isso recomendamos uma cláusula expressa sobre a titularidade do código e a licença do que o fornecedor já tinha.

A segunda: a lei fala de direitos sobre o programa, não de acesso ao repositório, às senhas e aos dados. Ter o direito no papel sem ter o código na mão é o cenário que o checklist acima tenta evitar.

LGPD: quem responde por quê

Se o sistema guarda nome, telefone ou e-mail de clientes, funcionários ou contatos, ele trata dados pessoais, e recomendamos tratar da LGPD no contrato. A Lei 13.709/2018 define dois papéis que importam aqui. Controlador é a pessoa natural ou jurídica “a quem competem as decisões referentes ao tratamento de dados pessoais” (art. 5º, VI). Operador é quem “realiza o tratamento de dados pessoais em nome do controlador” (art. 5º, VII).

Pela definição, o que conta é quem toma as decisões. Se a sua empresa decide para que os dados servem e o fornecedor trabalha no sistema com acesso a eles, o desenho se aproxima de controlador e operador. Três regras da lei pesam na negociação:

• o operador “deverá realizar o tratamento segundo as instruções fornecidas pelo controlador” (art. 39);
• controlador e operador devem adotar “medidas de segurança, técnicas e administrativas aptas a proteger os dados pessoais de acessos não autorizados e de situações acidentais ou ilícitas” (art. 46). O § 2º manda observá-las “desde a fase de concepção do produto ou do serviço até a sua execução”;
• o operador responde solidariamente pelos danos causados pelo tratamento quando descumprir a legislação de proteção de dados ou não seguir as instruções lícitas do controlador. Ficam de fora as exclusões do art. 43 (art. 42, § 1º, I).

No contrato, isso vira cláusulas concretas: o papel de cada parte, as instruções sobre o uso dos dados e as medidas de segurança. Diga também quem mais tem acesso aos dados, como o provedor de nuvem. Defina o destino dos dados no fim do contrato e em quanto tempo o fornecedor avisa sobre um incidente. Esse prazo pesa porque a comunicação é dever do controlador. Pelo art. 48, ele deve comunicar à Autoridade Nacional de Proteção de Dados (ANPD) e aos titulares o incidente de segurança “que possa acarretar risco ou dano relevante aos titulares”.

Qualidade: homologação, testes e manutenção

O contrato também deve dizer como a qualidade será verificada, com cinco itens por escrito:

• Ambiente de homologação: uma cópia do sistema, separada da produção, onde a sua equipe testa cada entrega antes dos usuários, de preferência sem dados pessoais reais.
• Testes nos fluxos críticos: o que não pode falhar, como faturamento e integrações fiscais, precisa de testes automáticos a cada mudança.
• Critérios de aceite: o que precisa funcionar para aprovar uma entrega, quem aprova e em quanto tempo.
• Acordo de nível de serviço (SLA, na sigla em inglês): tempo de resposta e de solução por gravidade, horário e canal de atendimento.
• Manutenção: o que está incluído, o que é cobrado à parte e como pedir.

Vale separar a manutenção em três tipos e definir cada um por escrito:

Tipo	O que é	Exemplo	O que definir
Corretiva	Corrigir erro no que foi entregue	Um relatório soma o mesmo pedido duas vezes	Prazo de correção e se está incluída no preço
Adaptativa	Ajustar o sistema a mudanças externas	Um serviço integrado muda a versão da própria API	Como é acionada e cobrada
Evolutiva	Criar funções novas ou mudar regras	A empresa passa a vender um novo tipo de pedido	Como é orçada e priorizada

Modelo ilustrativo.

Sem essa separação, “manutenção inclusa” pode significar só correção de erro, e qualquer mudança vira um orçamento novo.

Sinais de alerta

Nenhum sinal isolado condena um fornecedor, mas vários juntos pedem mais perguntas.

• Preço sem levantamento: ninguém perguntou como o processo funciona, e o valor já está na mesa.
• Prazo sem escopo: a data vem antes de alguém definir o que será entregue.
• Contrato sem uma linha sobre código, contas e dados: o que não foi escrito vira discussão na saída.
• Nenhum ambiente de teste: as entregas vão direto para quem usa o sistema.
• Ninguém nomeado como responsável: nenhuma pessoa do fornecedor responde pelo projeto.
• Promessa de resultado sem medição: “vai dobrar a produtividade”, sem ponto de partida nem forma de medir.

Perguntas frequentes

Em resumo

Escolha quem faz levantamento antes de dar preço e diz, por escrito, o que ficou fora do escopo. Deixe no contrato o que pesa no fim da relação: código e repositório, contas de nuvem e domínio, dados, documentação e manutenção. Defina também os papéis na LGPD e como a qualidade será verificada.

Este texto não é orientação jurídica. Use-o como roteiro de perguntas e leve o contrato a um advogado antes de assinar.

Fontes

1. Presidência da República (Planalto). Lei nº 9.609, de 19 de fevereiro de 1998 (Lei do Software). 1998. Acesso em 19/09/2026. Art. 4º, conferido no texto do Planalto.
2. Presidência da República (Planalto). Lei nº 13.709, de 14 de agosto de 2018 (LGPD). 2018. Acesso em 19/09/2026. Arts. 5º, VI e VII; 39; 42, § 1º, I; 46, caput e § 2º; e 48, conferidos no texto compilado do Planalto.