O dono de uma distribuidora chamou um desenvolvedor freelancer para criar um sistema interno de pedidos. O orçamento parecia bom: valor fechado, prazo curto, pagamento em etapas. Seis meses depois, o sistema estava no ar, mas ninguém sabia onde ficava o repositório, o banco de dados rodava na conta pessoal do dev e cada ajuste custava uma negociação nova pelo WhatsApp.
O problema não foi contratar freelancer. O problema foi contratar uma pessoa para resolver uma responsabilidade que era maior do que uma pessoa.
Quem busca "contratar desenvolvedor para sistema" normalmente está tentando resolver uma dor urgente: planilha que não aguenta mais, processo manual que virou gargalo, sistema antigo que ninguém quer mexer. A pressa faz parecer que a pergunta principal é "onde encontro alguém que programa?". Não é.
A pergunta principal é: qual modelo de contratação aguenta o risco do sistema que você quer construir?
Contratar desenvolvedor para sistema não é a mesma coisa que contratar mão de obra
Um sistema interno tem pelo menos cinco camadas que alguém precisa assumir:
- entender o processo real da empresa
- definir escopo e prioridade
- escolher arquitetura e tecnologia
- escrever o código
- manter o sistema funcionando depois da entrega
O freelancer pode assumir parte disso. Uma software house pode assumir mais. Um time interno pode assumir quase tudo. O erro é contratar um modelo e esperar comportamento de outro.
Se você contrata alguém só pela hora de desenvolvimento e espera diagnóstico, documentação, suporte, deploy, backup, segurança e evolução, a conta vai quebrar em algum lugar. Às vezes quebra no prazo. Às vezes no suporte. Às vezes no dia em que o dev some e ninguém sabe publicar uma nova versão.
Quando freelancer faz sentido
Freelancer faz sentido quando o escopo é pequeno, isolado e fácil de validar.
Exemplos:
- criar uma tela nova em um sistema que já existe
- ajustar layout de uma área administrativa
- integrar uma API simples com documentação boa
- corrigir um bug bem descrito
- montar um protótipo que não vai direto para produção
Nesses casos, o risco é limitado. Se o trabalho atrasar, você troca de pessoa. Se a entrega vier ruim, o prejuízo fica contido.
O sinal verde para freelancer é este: se a pessoa parar amanhã, outro desenvolvedor consegue continuar em menos de dois dias porque tudo está documentado, versionado e acessível.
Se essa frase não é verdade, você não está contratando uma tarefa. Está contratando dependência.
Quando freelancer vira risco
O risco aparece quando o sistema vira peça central da operação.
Um sistema de pedidos que a equipe comercial usa todo dia não é "um projeto de tela". Um painel financeiro que fecha o mês não é "só um dashboard". Uma integração entre estoque, nota fiscal e cobrança não é "só uma API".
Esses projetos precisam de decisões que vão além do código:
- onde o sistema vai hospedar
- quem terá acesso ao banco de dados
- como o backup será testado
- quem corrige bug em produção
- qual é o plano se a tecnologia escolhida ficar fora de suporte
- como outro fornecedor assume o projeto depois
Se o orçamento não responde essas perguntas, ele está barato porque deixou parte do trabalho fora.
Um exemplo simples: um sistema interno pode exigir custo mensal de servidor, banco, monitoramento, e-mail transacional e backup. Em 24 meses, essa sustentação pode representar uma parte relevante do custo real. Se ninguém colocou isso na proposta, a surpresa não é acidente. É falta de escopo.
O ponto jurídico e operacional que quase sempre fica fora da conversa
Sistema não é só entrega técnica. É ativo da empresa. No Brasil, programa de computador tem lei própria, a Lei 9.609/1998, e o uso de software no país deve ser objeto de contrato de licença. Para um sistema feito sob encomenda, isso torna indispensável deixar por escrito quem pode usar, alterar, manter e transferir aquele código.
Na prática, o contrato precisa responder:
- se há cessão de direitos patrimoniais ou apenas licença de uso
- se a empresa pode contratar outro fornecedor para continuar o código
- se o código-fonte será entregue e em qual repositório
- se dependências, bibliotecas e serviços de terceiros estão regularizados
- se credenciais, domínio, hospedagem e banco ficam em contas da empresa
O mesmo vale para acesso técnico. O GitHub, por exemplo, permite controlar permissões por organização, equipe, colaborador externo e repositório. Isso é importante porque o sistema não deve depender de uma conta pessoal para existir.
Os 3 modelos de contratação e o que esperar de cada um
1. Freelancer
Bom para tarefas bem delimitadas, protótipos, ajustes e módulos pequenos.
Risco principal: dependência pessoal.
O que exigir:
- repositório na conta da sua empresa
- contrato com cessão de direitos
- documentação mínima de instalação
- entrega com checklist
- acesso direto a hospedagem, domínio e banco
2. Desenvolvedor alocado
Bom quando você precisa de alguém recorrente, mas já tem alguém técnico para coordenar.
Risco principal: contratar execução sem ter direção técnica.
Se ninguém na empresa sabe priorizar backlog, revisar arquitetura e validar entrega, o dev alocado vai receber tarefa ruim e entregar exatamente o que foi pedido. O problema é que o que foi pedido pode não ser o que a empresa precisava.
3. Empresa de desenvolvimento
Boa quando o sistema envolve processo crítico, integração, dados sensíveis ou manutenção depois da entrega.
Risco principal: contrato genérico e escopo aberto.
O ganho está em ter diagnóstico, arquitetura, implementação, documentação e continuidade no mesmo fluxo. Mas isso só vale se a proposta for específica. "Sistema completo" não quer dizer nada. "Módulo de pedidos com cadastro de cliente, cálculo de preço, aprovação e geração de PDF" começa a dizer.
Checklist antes de contratar qualquer desenvolvedor
Antes de assinar, peça resposta por escrito para estas perguntas:
- O código ficará em qual repositório e em nome de quem?
- Quem será dono das contas de hospedagem, banco de dados, e-mail e APIs?
- O que exatamente será entregue na primeira versão?
- O que está fora do escopo?
- Como bug em produção será tratado nos primeiros 90 dias?
- Qual é o custo mensal esperado de infraestrutura?
- Existe documentação de instalação e deploy?
- Outro desenvolvedor conseguiria assumir o projeto depois?
- O contrato inclui cessão de propriedade intelectual?
- Quem responde se o sistema ficar fora do ar?
Se o fornecedor responde "isso a gente vê depois", o risco já apareceu. E se ele diz que "o código é seu" mas não explica repositório, acesso, licença, deploy e documentação, a frase ainda não virou controle real.
A conta simples para decidir se você precisa de freelancer ou empresa
Use este filtro:
Projeto até R$ 10 mil, baixa criticidade, sem dado sensível: freelancer pode fazer sentido.
Projeto entre R$ 10 mil e R$ 40 mil, com uso interno recorrente: freelancer só faz sentido se houver governança forte da sua parte.
Projeto acima de R$ 40 mil, com operação diária, clientes, financeiro, estoque ou integração: trate como sistema crítico. O modelo precisa incluir documentação, sustentação e plano de continuidade.
O valor não é regra absoluta. É alerta. Um sistema barato pode ser crítico. Um sistema caro pode ser simples. Mas quando o projeto mistura valor alto, dado sensível e operação diária, contratar só pela hora mais barata quase sempre desloca o custo para depois.
O jeito certo de reduzir custo sem criar dependência
Se o orçamento está apertado, reduza escopo. Não reduza controle.
Reduzir escopo:
- primeira versão com menos telas
- menos integrações
- menos perfis de usuário
- menos automações no início
Reduzir controle:
- código na conta do dev
- sem contrato
- sem documentação
- sem acesso ao banco
- sem backup testado
A primeira lista diminui custo. A segunda cria risco.
Se você precisa cortar orçamento, peça para o fornecedor separar o projeto em fases. Mas cada fase precisa terminar com algo utilizável, documentado e sob controle da sua empresa.
O próximo passo antes de pedir orçamento
Escreva em uma página:
- qual processo o sistema vai substituir
- quem usa esse processo hoje
- quantas vezes por mês ele acontece
- quanto tempo cada execução consome
- quais erros aparecem com mais frequência
- quais sistemas precisam conversar com ele
- o que precisa estar pronto na primeira versão
Com essa página, você deixa de pedir "um sistema" e começa a pedir uma solução para um problema específico.
Depois disso, leia também como contratar desenvolvedor freelancer sem perder o código e quanto custa manter um sistema depois da entrega. Essas duas perguntas aparecem depois da assinatura, mas deveriam aparecer antes.
Fontes consultadas: Lei 9.609/1998, conhecida como Lei do Software, e documentação do GitHub sobre papéis em organizações.
Se você está prestes a contratar alguém para criar um sistema interno e ainda não sabe onde o código vai ficar, quem paga a infraestrutura e quem corrige bug em produção, vale parar antes de assinar. A Coffe&Code Labs faz desenvolvimento de sistemas para empresas com diagnóstico, escopo e continuidade técnica desde o início. Para revisar uma proposta que já está na sua mão, fale com a gente.