Software house ou freelancer: o que muda na prática
Raphael Belfort9 min de leitura

Software house ou freelancer: o que muda na prática

A pergunta costuma ser feita como se fosse sobre preço. Raramente é.

Já trabalhei com autônomos melhores que muita empresa, e já vi agência grande entregar coisa ruim com nota fiscal bonita. A escolha não é sobre quem programa melhor. É sobre o que acontece depois.

O que você está comprando em cada caso

Do freelancer você compra execução. Alguém com domínio técnico específico resolve um problema definido, geralmente mais rápido e mais barato, com contato direto e sem camada de intermediação.

Da software house você compra continuidade. Um processo, um contrato, mais de uma pessoa capaz de mexer no mesmo código, e alguém que continua existindo depois da entrega.

Quando o que você precisa é execução, pagar por continuidade é desperdício. Quando precisa de continuidade, economizar nela é o erro mais caro que dá para cometer nesse tipo de contratação.

O fator de risco que decide

A pergunta que separa os dois casos é simples: se isso quebrar numa sexta à noite, quanto custa cada hora parada?

Se a resposta for “nada, resolvo na segunda”, freelancer é uma escolha perfeitamente razoável. Site institucional, landing page de campanha, ajuste pontual — o risco de indisponibilidade é baixo e o custo de errar é baixo.

Se a resposta for “meu faturamento para”, a conta muda. E-commerce, sistema de agendamento, qualquer coisa que a operação usa todo dia. Aí você não está comprando código, está comprando a garantia de que alguém atende.

O ponto único de falha

Todo freelancer é, por definição, um ponto único de falha. Não é crítica — é aritmética.

Ele pode ficar doente, mudar de país, ser contratado em regime integral por outra empresa ou simplesmente cansar. Nenhuma dessas coisas é má-fé, e todas deixam você com um sistema que ninguém mais conhece.

O antídoto não é evitar autônomos. É exigir, de qualquer fornecedor, três coisas: acesso ao repositório desde o primeiro dia, código legível o suficiente para outra pessoa continuar, e um documento curto explicando como subir o projeto do zero.

Fornecedor que resiste a isso está te vendendo dependência, e dependência é sempre mais cara do que o desconto que a justificava.

Onde a software house decepciona

Justiça: ela também tem modo de falhar, e são falhas conhecidas.

A pessoa que vendeu não é a que executa. Você conversa com alguém sênior na proposta e recebe um time diferente na entrega.

Camadas demais. Um pedido de mudança de meia hora passa por gerente de projeto, alinhamento e priorização, e leva duas semanas.

Processo que serve à agência, não a você. Reuniões de status que existem para preencher relatório, e não para decidir nada.

Vale perguntar diretamente: quem escreve o código do meu projeto, e eu falo com essa pessoa? A resposta diz mais sobre a empresa do que o portfólio inteiro.

Um caminho do meio que funciona

Freelancer para o que é pontual e delimitado. Parceiro fixo para o que a operação usa todo dia.

Muita empresa faz isso naturalmente sem chamar assim: contrata alguém para uma landing page de campanha e mantém um fornecedor de confiança para o sistema principal. É uma alocação de risco sensata, não uma incoerência.

As perguntas que valem para os dois

Independente do modelo, pergunte antes de assinar:

Quem é o dono do código? Precisa estar escrito. “Fica com a gente até o final do contrato” não é a mesma coisa que “é seu”.

O que acontece se eu quiser trocar? Um fornecedor confiante responde isso sem desconforto.

Como funciona o suporte depois da entrega? Prazo de resposta, canal, o que está incluso e o que é cobrado à parte.

Posso falar com um cliente seu de dois anos atrás? Cliente novo elogia qualquer um. Cliente de dois anos sabe como é o relacionamento depois que a euforia da entrega passou.

O erro mais caro

Não é escolher o modelo errado. É escolher qualquer um dos dois sem contrato claro sobre propriedade, acesso e suporte.

Com isso resolvido, os dois caminhos funcionam. Sem isso, os dois viram problema — só que em prazos diferentes.

Perguntas frequentes

Não. Os melhores desenvolvedores que já trabalhamos junto eram autônomos. A diferença não está na qualidade do que sai, está no que acontece quando essa pessoa fica doente, muda de área ou some — e num sistema que a sua empresa usa todo dia, isso não é detalhe.

A hora costuma ser, sim. O projeto inteiro nem sempre, porque parte do que você paga a mais é justamente o que evita retrabalho, atraso e a conta de emergência quando algo quebra numa sexta à noite.

Três cláusulas: o código e os dados são seus, o repositório é acessível desde o primeiro dia, e existe documentação mínima de como subir o projeto do zero. Com isso, trocar de fornecedor deixa de ser uma catástrofe e vira um transtorno administrável.

Conte onde está o gargalo. A gente responde se dá para resolver.

Começar agora