# Freelancer ou software house: qual contratar e quando

> Contratar freelancer ou software house? Veja quando cada um faz sentido, os riscos de depender de uma pessoa só e 8 perguntas para decidir antes de assinar.

Fonte: https://pervian.tech/blog/freelancer-ou-software-house · Pervian Tech · publicado em 2026-10-01

A decisão costuma aparecer assim: a empresa precisa de um sistema para controlar pedidos, um portal para clientes ou uma integração entre o ERP e a loja virtual. Alguém conhece um desenvolvedor bom, que já fez um trabalho para um parente, e a proposta dele parece mais simples e mais rápida que a de uma empresa. A pergunta que fica na mesa é se vale a pena contratar um freelancer ou uma software house.

Na maioria das vezes, a comparação é feita pelo valor da proposta e pelo prazo prometido. O que quase nunca entra na conta é o que acontece seis meses depois: quem corrige o erro que apareceu no fechamento do mês, quem tem a senha do servidor, quem entende por que aquela regra de desconto foi escrita daquele jeito.

Em resumo: freelancer serve bem para trabalho pequeno, isolado e temporário; software house faz mais sentido quando o sistema sustenta a operação e vai evoluir por anos. Abaixo, comparamos as duas opções pelo que pesa para a empresa ao longo da vida do sistema, não só na assinatura do contrato.

## A resposta curta

Não existe opção certa para todos os casos. Existe a opção que combina com o tamanho do risco.

- **Freelancer** funciona bem para trabalhos delimitados, com começo e fim claros, que não sustentam uma operação crítica: uma landing page, um ajuste pontual, um protótipo para validar uma ideia, um relatório que alguém vai usar por alguns meses.
- **Software house** faz mais sentido quando o sistema vai rodar o dia a dia da empresa, precisa evoluir por anos, guarda dados de clientes ou funcionários, ou para a operação se sair do ar.

O critério não é o porte da empresa contratante. É **o que acontece com o negócio se a pessoa que escreveu o código sumir amanhã**. Se a resposta for "nada grave", um bom freelancer resolve. Se for "o faturamento para", a empresa precisa de um fornecedor com estrutura para não depender de uma pessoa só.

## Onde o freelancer funciona bem

Há muitos profissionais autônomos excelentes, e em vários cenários eles são a melhor escolha:

- **Escopo pequeno e fechado.** Um formulário que grava num banco, uma automação que lê uma planilha e envia e-mails, uma página institucional. O trabalho cabe na cabeça de uma pessoa e termina. Site e campanha costumam ir para agência, como explicamos em [agência digital ou software house](https://pervian.tech/blog/agencia-digital-ou-software-house).
- **Especialidade rara.** Às vezes a empresa precisa de alguém que domine uma tecnologia específica por algumas semanas, e um especialista autônomo resolve melhor do que ninguém.
- **Reforço de equipe interna.** Se a empresa já tem um time técnico que revisa o código, define padrões e guarda os acessos, o freelancer entra como mão de obra adicional, e o conhecimento fica dentro de casa.
- **Protótipo para validar uma ideia.** Antes de investir num produto, vale testar se os clientes usam. O protótipo pode ser descartado depois.

Nos quatro casos, o ponto comum é que **o risco de continuidade é baixo** ou alguém da empresa absorve esse risco.

## Riscos: continuidade, conhecimento e disponibilidade

Os problemas com freelancer raramente vêm de falta de competência técnica. Vêm do fato de que o projeto depende de uma única pessoa, e pessoas mudam de vida.

### Continuidade

O desenvolvedor autônomo pode aceitar um emprego fixo, mudar de área, ficar doente, ter um filho ou simplesmente pegar um cliente maior. Nenhuma dessas situações é má-fé. Mas para a empresa o efeito é o mesmo: o [sistema fica sem ninguém que saiba mexer nele](https://pervian.tech/blog/sistema-dependente-de-um-programador).

Um exemplo comum: uma distribuidora contrata um desenvolvedor para fazer o sistema de pedidos dos representantes. Funciona bem por um ano. Aí muda uma regra de tributação, o cálculo precisa ser ajustado, e o desenvolvedor não responde mais. A empresa descobre que ninguém sabe onde o sistema está hospedado.

### Conhecimento concentrado

Mesmo quando a pessoa continua disponível, todo o conhecimento do sistema está na cabeça dela: por que a tabela tem aquele campo, qual rotina roda de madrugada, qual integração quebra quando o fornecedor muda o arquivo. Sem documentação e sem uma segunda pessoa que conheça o código, **qualquer outro profissional que assumir vai precisar de semanas só para entender o que existe** antes de conseguir mudar algo com segurança.

Esse é o mesmo mecanismo que gera [dívida técnica](https://pervian.tech/blog/divida-tecnica-explicada-para-gestores): atalhos que só o autor conhece e que cobram juros de quem vem depois. Se o sistema já chegou nesse ponto, o caminho para retomá-lo está em [como assumir um sistema legado sem documentação](https://pervian.tech/blog/assumir-sistema-legado-sem-documentacao).

### Disponibilidade

Freelancer atende vários clientes ao mesmo tempo. Se o sistema cai na segunda-feira de manhã e ele está entregando outro projeto, a sua urgência entra na fila. Não há plantão, não há substituto, não há compromisso formal de tempo de resposta, a não ser que isso esteja no contrato, e mesmo assim uma pessoa só não consegue garantir cobertura em férias ou doença.

Para sistemas que sustentam a operação, vale entender o que é um acordo de nível de serviço e o que exigir dele. Escrevemos sobre isso em [SLA de suporte e sustentação de software](https://pervian.tech/blog/sla-de-suporte-e-sustentacao-de-software).

### Segurança e acessos

Projetos tocados por uma pessoa só tendem a concentrar os acessos nela: a conta da nuvem no e-mail pessoal do desenvolvedor, o domínio registrado no CPF dele, o repositório de código na conta dele. Quando a relação termina, a empresa precisa pedir de volta o que deveria ter sido dela desde o início.

Somam-se a isso práticas que dependem de disciplina individual: backup testado, atualização de bibliotecas, senhas guardadas em lugar seguro, separação entre ambiente de teste e de produção. Um profissional cuidadoso faz tudo isso. O problema é que a empresa, em geral, não tem como verificar.

## O que uma software house acrescenta

Uma software house não é melhor por definição. Existem fornecedores ruins de todos os tamanhos. O que uma empresa de desenvolvimento estruturada deveria acrescentar é **processo que reduz a dependência de pessoas específicas**:

- **Mais de uma pessoa conhece o sistema.** Revisão de código, documentação mínima e rodízio fazem com que a saída de um desenvolvedor não pare o projeto.
- **Papéis separados.** Quem levanta requisitos, quem desenha a arquitetura, quem programa e quem testa. Em projetos pequenos uma pessoa acumula funções, mas existe alguém para revisar.
- **Ambientes e testes.** Ambiente de homologação para o cliente validar antes de ir para produção, testes automatizados nas partes críticas, publicação automatizada, sem depender de alguém repetir passos de memória.
- **Capacidade de crescer.** Se o projeto precisa acelerar, ou ganhar um aplicativo, uma integração ou um painel de dados, o fornecedor consegue alocar mais gente sem recomeçar do zero.
- **Sustentação formal.** Suporte depois da entrega, com canal definido e tempo de resposta combinado em contrato.
- **Responsabilidade que não depende de uma pessoa.** Contrato com CNPJ, cláusulas de confidencialidade e de tratamento de dados, e uma empresa que continua obrigada mesmo que o desenvolvedor do projeto saia. Um autônomo também pode formalizar contrato e emitir nota, mas a obrigação continua concentrada nele.

Na prática, o que a empresa compra de uma software house é **previsibilidade**. O código pode até ser escrito por uma pessoa só em algumas fases, mas o conhecimento, os acessos e a responsabilidade não ficam presos a ela.

Para avaliar se um fornecedor entrega isso de fato, e não só no discurso comercial, vale ler [como escolher uma software house](https://pervian.tech/blog/como-escolher-uma-software-house).

## Comparação lado a lado

| Critério | Freelancer | Software house |
|---|---|---|
| Continuidade se alguém sair | Depende de uma pessoa | Conhecimento distribuído na equipe |
| Disponibilidade para incidentes | Concorre com outros clientes | Sustentação com tempo de resposta em contrato |
| Revisão de código e testes | Depende da disciplina individual | Faz parte do processo, quando o fornecedor é sério |
| Capacidade de crescer o projeto | Limitada à agenda de uma pessoa | Equipe pode ser ampliada |
| Contrato e responsabilidade | Muitas vezes informal, mas pode ser formalizado | Contrato formal com a empresa fornecedora |
| Agilidade em escopo pequeno | Alta, pouca burocracia | Pode ter mais etapas antes de começar |
| Especialidade pontual | Ótima opção | Nem sempre tem o especialista |
| Comunicação | Direta com quem programa | Depende do fornecedor; o ideal é falar com quem desenvolve |

A última linha merece atenção: uma das vantagens reais do freelancer é falar direto com quem escreve o código. Uma boa software house preserva isso, colocando quem desenvolve nas conversas com o cliente em vez de um intermediário comercial.

## Contrato, código e acessos em qualquer caso

Independentemente de quem a empresa contratar, alguns cuidados valem sempre. São eles que transformam um risco grande num risco administrável.

### Código-fonte e propriedade

O contrato precisa dizer de quem é o código, o que acontece com ele ao fim da relação e quais bibliotecas de terceiros foram usadas. Código entregue sem cessão de direitos clara pode gerar discussão justamente quando a empresa precisar trocar de fornecedor. Detalhamos as cláusulas em [propriedade do código-fonte no contrato](https://pervian.tech/blog/propriedade-do-codigo-fonte-no-contrato). Para a redação final, valide com o jurídico da empresa.

### Relação de trabalho

Se o autônomo passa a cumprir horário fixo, receber ordens diretas como um funcionário e trabalhar só para a sua empresa por tempo indeterminado, a relação pode ser questionada na Justiça do Trabalho como vínculo de emprego, independentemente do que diz o contrato. Isso não acontece com um trabalho de escopo definido e entrega combinada, mas vale conversar com o jurídico antes de transformar um freelancer em "funcionário sem carteira".

### Acessos no nome da empresa

- Repositório de código numa conta da empresa, com o fornecedor como convidado.
- Conta da nuvem e do servidor no CNPJ e no e-mail corporativo.
- Domínio registrado no CNPJ.
- Senhas guardadas num cofre de senhas da empresa, não numa conversa de aplicativo.
- Credenciais de integrações (banco, gateway de pagamento, ERP) criadas pela empresa e compartilhadas com permissão mínima.

### Entregáveis de transição

Documentação de como instalar e publicar o sistema, descrição das integrações e das rotinas automáticas, e uma lista das contas externas usadas. Isso não precisa ser um manual extenso; precisa permitir que outra pessoa assuma.

### Dados pessoais

Se o sistema trata dados de clientes ou funcionários, em geral o fornecedor atua como operador desses dados nos termos da LGPD, e a sua empresa continua como controladora. Mais detalhes em [LGPD no desenvolvimento de sistemas](https://pervian.tech/blog/lgpd-no-desenvolvimento-de-sistemas). O contrato deve prever confidencialidade, uso dos dados só para a finalidade combinada e o que acontece com cópias ao fim da relação. Os detalhes jurídicos variam caso a caso: confirme com o seu advogado.

## Combinações possíveis

A escolha não precisa ser excludente. Alguns arranjos que funcionam:

- **Software house no núcleo, freelancer na periferia.** O sistema central (pedidos, financeiro, estoque) fica com um fornecedor estruturado; trabalhos pontuais, como uma página de campanha, vão para autônomos.
- **Freelancer com revisão externa.** A empresa mantém o profissional autônomo, mas contrata uma revisão periódica de código, segurança e infraestrutura para não ficar às cegas.
- **Protótipo com freelancer, produto com software house.** A ideia é validada de forma rápida; quando provar que tem uso, o produto é reescrito ou consolidado por uma equipe com processo.
- **Time interno com apoio de software house.** A empresa contrata um ou dois desenvolvedores próprios e usa o fornecedor para arquitetura, picos de demanda e sustentação fora do horário.

O que não costuma funcionar é deixar um sistema crítico crescer anos nas mãos de uma pessoa só, sem revisão, sem documentação e com os acessos fora da empresa.

## Perguntas para decidir

Responda com a equipe antes de assinar qualquer proposta:

1. **Se este sistema parar por um dia, o que acontece com a operação?** Quanto mais grave, mais peso para continuidade e sustentação.
2. **Por quanto tempo o sistema vai ser usado e alterado?** Projetos que vão evoluir por anos precisam de conhecimento distribuído.
3. **O sistema vai guardar dados de clientes, funcionários ou pagamentos?** Se sim, segurança e contrato formal deixam de ser opcionais.
4. **Alguém na empresa tem condição de revisar o trabalho técnico?** Sem isso, a empresa depende inteiramente da disciplina do fornecedor.
5. **Quem vai atender um problema à noite, no fim de semana ou nas férias do desenvolvedor?** Tem que existir um nome e um canal.
6. **Os acessos (código, nuvem, domínio) vão ficar no nome da empresa desde o primeiro dia?** Se a resposta for "depois a gente transfere", corrija agora.
7. **Se o fornecedor sair, outra equipe consegue assumir em pouco tempo?** Peça para ver o que será entregue como documentação.
8. **O projeto tende a crescer?** Um aplicativo, uma integração nova, um painel de indicadores. Verifique se quem vai fazer o primeiro passo consegue acompanhar os seguintes.

Se a maioria das respostas apontar para operação crítica, vida longa e dados sensíveis, o critério de preço passa a ser secundário. Se apontar para algo pequeno, temporário e isolado, um bom freelancer com contrato e acessos bem resolvidos é uma escolha razoável.

Para ver outros textos sobre contratação de software, consulte a categoria [contratação](https://pervian.tech/blog/categoria/contratacao).

## Perguntas frequentes

### É mais barato contratar freelancer ou software house?

Na proposta inicial, o freelancer costuma parecer mais barato, porque tem estrutura menor. A comparação justa, porém, inclui o que vem depois: correções, sustentação, disponibilidade em incidentes e o esforço de outra pessoa entender o sistema se o autor sair. Em sistema crítico e de vida longa, esses custos costumam pesar mais que a diferença da proposta.

### Contratar freelancer pode gerar vínculo empregatício?

Pode. Se o freelancer passa a cumprir horário fixo, receber ordens diretas como funcionário e trabalhar só para a empresa por tempo indeterminado, a relação pode ser reconhecida como vínculo de emprego na Justiça do Trabalho, independentemente do contrato. Trabalho com escopo definido e entrega combinada não costuma ter esse risco, mas vale consultar o jurídico.

### Quem fica com o código-fonte de um sistema feito por freelancer?

Depende do contrato. A cessão de direitos sobre o código-fonte deve estar prevista por escrito, dizendo de quem é o código e o que acontece com ele ao fim da relação. Além disso, repositório, conta da nuvem e domínio devem ficar no nome da empresa desde o primeiro dia, com o freelancer como convidado, e não o contrário.

### Como saber se uma software house é confiável?

Uma software house confiável mostra processo, não só portfólio: mais de uma pessoa conhece cada sistema, há revisão de código, ambiente de homologação, sustentação com tempo de resposta em contrato e acessos no nome do cliente. Vale pedir para conversar com quem vai desenvolver e para ver a documentação que será entregue ao fim do projeto.

## Como a Pervian Tech trabalha projetos

Na Pervian Tech, começamos pelo diagnóstico: entender o que o sistema precisa fazer, quanto a operação depende dele e o que já existe hoje. Às vezes a conclusão é que o trabalho é pequeno e não precisa de uma estrutura grande; quando isso acontece, dizemos.

Nos projetos de [desenvolvimento web sob medida](https://pervian.tech/servicos/desenvolvimento-web), o repositório, a nuvem e o domínio ficam no nome do cliente desde o início, o código passa por revisão de mais de uma pessoa, há ambiente de homologação para validar antes de publicar, e a sustentação é combinada antes do lançamento. Quem participa das reuniões é quem desenha e escreve o sistema. Se a empresa já tem um desenvolvedor, interno ou autônomo, também trabalhamos junto com ele.

Cada projeto é sob medida, e o investimento é definido sob consulta, depois de um diagnóstico inicial gratuito. Se você está entre um freelancer e uma software house para o próximo sistema, [conte o que precisa](https://pervian.tech/#contato) e traga as perguntas deste texto.