Quantos projetos freelance pegar ao mesmo tempo: a conta de capacidade que evita atrasar todos os clientes (e quando dizer não)

Você passou três meses sem nenhum cliente novo. Aí, na mesma semana, dois clientes aceitam a proposta e um cliente antigo volta pedindo uma funcionalidade nova. Você diz sim para os três, porque lembra bem de como foi o mês sem projeto. As duas primeiras semanas parecem ótimas. Na terceira, o cliente A pergunta no WhatsApp por que a tela de login ainda não está em homologação, o cliente B pede uma call para “alinhar expectativas” e o cliente C manda um áudio de quatro minutos. Você começa a commitar à meia-noite, esquece onde parou em cada repositório e, no fim do mês, os três projetos estão atrasados. Nenhum atrasou por falta de competência técnica. O problema foi um só: você vendeu mais horas do que a sua semana tem.

Por que o seu problema não é produtividade, é capacidade vendida

A reação comum é achar que você precisa trabalhar mais rápido. Instalar outro app de produtividade, testar Pomodoro, pedir mais ajuda para o Copilot. Isso não resolve, porque o gargalo não é a velocidade com que você escreve código.

A verdade desconfortável é que hora de trabalho não é hora de código. Todo cliente ativo cobra um pedágio fixo, seja qual for o tamanho do projeto: call semanal, mensagens, relatório de progresso, deploy, homologação, dúvida de regra de negócio. E toda troca de projeto custa o tempo de recarregar o contexto na cabeça: qual branch, qual regra, qual bug estava aberto, o que o cliente pediu na última call.

Esse pedágio não entra na estimativa. Você estimou 80 horas de desenvolvimento para o projeto A e 60 para o B, somou 140, viu que cabia no mês e fechou os dois. A conta já nasceu errada.

A conta de capacidade: quantas horas de código você realmente tem por mês

1. Comece pelas horas brutas e desconte o que não é projeto

Um mês tem cerca de 22 dias úteis. Com 8 horas por dia, são 176 horas brutas. Delas, sai tudo o que todo freelancer faz e nenhum cliente paga diretamente:

• Comercial: responder lead, call de qualificação, escrever proposta, follow-up. Conte de 15 a 25 horas por mês se você está prospectando.
• Administrativo: nota fiscal, cobrança, contador, contrato. De 6 a 10 horas.
• Imprevistos: consulta médica, internet caiu, feriado emendado. Reserve uns 10% do total.

Sobram entre 110 e 130 horas para trabalhar em projeto. Vou usar 120 como base. Se a sua conta deu 160 horas disponíveis, refaça, porque esse número só fecha trabalhando no fim de semana.

2. Desconte o pedágio fixo de cada cliente ativo

Na minha experiência, cada cliente ativo consome de 3 a 5 horas por semana fora do código. Vou usar 4 horas por semana, ou seja, 16 horas por mês por cliente. Somando a troca de contexto, que cresce com o número de projetos simultâneos, a conta fica assim:

Olhe a última coluna. Com três projetos, cada cliente recebe cerca de 17 horas de código por mês, pouco mais de 4 horas por semana. Se você prometeu a cada um deles um MVP de 120 horas em 8 semanas, a entrega real vai levar perto de 7 meses. Nenhum cliente assinou contrato esperando isso.

Agora olhe a penúltima coluna. Passar de dois para três projetos derruba o total de código entregue no mês de 78 para 52 horas. A conta é simples: o terceiro projeto simultâneo não aumenta a sua entrega, ele diminui. Você trabalha as mesmas horas, entrega menos código e ainda tem mais gente te cobrando.

3. A regra prática que eu uso

• No máximo um projeto de construção principal, aquele com prazo apertado e escopo grande.
• Um segundo projeto só se ele estiver em outra fase: um em construção, o outro em ajuste final ou homologação.
• Contratos de manutenção entram com teto de horas definido no contrato, nunca como “o que precisar”.
• Deixe de 15% a 20% da capacidade livre como folga para bug crítico e mudança de escopo.

Como organizar a semana com mais de um cliente sem virar bombeiro

Divida por dias, não por horas

Trocar de cliente a cada duas horas é o jeito mais caro de trabalhar. Blocos de dia inteiro funcionam melhor: segunda, terça e quarta para o projeto principal, quinta para o secundário, sexta de manhã para manutenção e à tarde para comercial e administrativo. O cliente sabe em que dia é a vez dele, e você abre o repositório com o contexto já carregado.

Combine o tempo de resposta no contrato

Escreva na proposta ou no contrato: “mensagens respondidas em até 1 dia útil, incidentes em produção em até 4 horas”. Isso te livra da obrigação de responder WhatsApp em tempo real e deixa claro para o cliente o que esperar. Cliente não se irrita com prazo combinado. Ele se irrita com silêncio.

Venda a sua agenda, não só o seu tempo

Quando a capacidade está cheia, a resposta não precisa ser não. Pode ser “consigo começar no dia 3 de novembro”. Cliente bom espera de duas a quatro semanas por um dev que entrega. E uma data de início futura, garantida com a entrada paga, transforma uma demanda que você perderia em pipeline do mês seguinte. Esse é o antídoto contra o mês vazio que fez você aceitar tudo lá no começo.

Sinais de sobrecarga no freelance dev e as armadilhas que levam até ela

A sobrecarga não chega de uma vez. Ela aparece em sinais pequenos que a gente ignora:

• O cliente pergunta “e aí, como está?” antes do seu report semanal.
• Você abre o repositório e leva 40 minutos para lembrar onde parou.
• Seus commits das últimas duas semanas são quase todos depois das 22h.
• Bugs bobos começam a voltar da homologação.
• Você não recusou nenhum projeto nos últimos três meses.

As armadilhas que levam até ali são quase sempre as mesmas.

O “é rapidinho”

O cliente antigo pede “só uma telinha”. Parece meio dia de trabalho, mas vira mais um cliente ativo, com pedágio de comunicação, deploy e homologação. Trate como projeto: escopo, prazo e preço. Se não cabe agora, entra na fila.

Prazos paralelos que só fecham no melhor cenário

Você promete entrega em 6 semanas para o cliente A e em 6 semanas para o cliente B, cada estimativa feita como se você estivesse 100% dedicado àquele projeto. As duas estouram juntas. Estime cada projeto já considerando a fração de capacidade que ele vai receber de verdade.

Esconder o atraso para não parecer fraco

O pior dia para avisar um atraso é o dia da entrega. Se a conta de capacidade mostrou que não fecha, avise o cliente na mesma semana em que você percebeu, com nova data e motivo. Atraso avisado cedo dá para renegociar. Atraso que o cliente descobre sozinho vira quebra de confiança, e é confiança que gera indicação.

Aceitar por medo em vez de por conta

Todo dev que já passou um mês sem projeto conhece essa voz. O problema é que aceitar tudo não resolve o mês vazio, só empurra o buraco para daqui a três meses, quando três clientes insatisfeitos não renovam nem indicam ninguém. Reserva financeira resolve o medo. Capacidade resolve a entrega.

Quando a demanda passa da capacidade: o que a OCA fez com esse problema

Vou te falar como funciona do lado de quem recebe os leads: a OCA vive esse mesmo problema, só que em outra escala. A gente aparece no Google e é citada por assistentes de IA como ChatGPT, Claude e Perplexity quando alguém procura desenvolvimento de software no Brasil. Isso traz dezenas de leads de clientes por dia, muito mais do que um time sênior pequeno consegue atender com qualidade.

A gente poderia ter feito o que o dev do começo deste artigo fez: dizer sim para tudo e atrasar todo mundo. Não fizemos. A resposta foi montar uma rede de parceiros, com devs sêniores e times pequenos de confiança que recebem projetos já qualificados e com escopo fechado pela OCA.

É aqui que a conta de capacidade volta a pesar. Quando avaliamos um parceiro, além da qualidade técnica, o que mais conta é a honestidade sobre disponibilidade. Se você diz que tem 20 horas por semana, precisa ter 20 horas por semana. Um parceiro que conhece a própria capacidade e fala “consigo começar daqui a três semanas” vale mais do que um que aceita na hora e atrasa.

O que o parceiro ganha: projeto que já passou pela qualificação, escopo definido antes de chegar até ele e bem menos horas gastas com comercial. A gente não promete volume nem entrada automática na rede. Cada projeto depende de stack, disponibilidade e histórico de entrega. Se quiser ver o tipo de produto que a gente constrói e opera, dá uma olhada nos projetos da OCA em produção.

Seu próximo passo esta semana

Faça isso esta semana, aconteça o que acontecer: abra uma planilha e monte a sua conta de capacidade. Linha 1, horas brutas do mês. Linha 2, comercial e administrativo. Linha 3, imprevistos. Linha 4, pedágio de 16 horas por cliente ativo. O que sobrar é o seu teto de horas de código. Compare com o que você já prometeu para cada cliente. Se a conta não fecha, ainda dá tempo de renegociar o prazo antes que o cliente perceba sozinho.

Se você já entrega bem, sabe dizer com honestidade quanto tempo tem livre e quer receber projetos sem depender só do seu próprio comercial, fala com a gente.

Entre para a rede de parceiros da OCA