Freelancer ou software house: qual contratar e quando

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.
• 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.

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: 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.

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.

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.

Comparação lado a lado

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. 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. 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.

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, 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 e traga as perguntas deste texto.