Quantos projetos freelance dá para tocar ao mesmo tempo: a conta de capacidade que evita furar prazo

Você fechou o segundo projeto e ficou feliz. Fechou o terceiro e ficou orgulhoso. Na quarta semana, está respondendo mensagem de cliente às 23h, pedindo desculpa por atraso pela segunda vez e sentindo aquele aperto de quem sabe que alguma entrega vai estourar. Ninguém te ensinou a conta de capacidade, então você aceitou tudo que apareceu. É o erro mais comum de quem começa a viver de projeto, e é o que mais destrói reputação, porque o cliente não vê a sua agenda, ele só vê o prazo furado.

Vou te falar como funciona do lado de quem recebe os leads: na OCA a gente recusa ou repassa projeto toda semana. Não por luxo, por matemática. Este artigo é essa matemática.

A verdade desconfortável: você não tem 40 horas produtivas por semana

A primeira mentira que o dev conta para si mesmo é planejar como se toda hora acordada fosse hora de código faturável. Não é. Numa semana de 40 horas de trabalho, a conta real fica parecida com isto:

• Comunicação com clientes: 4 a 6 horas. Mensagem, call de alinhamento, responder dúvida, mandar update. Cada cliente ativo consome de 1 a 2 horas por semana só de conversa, mesmo quando está tudo bem.
• Administração do negócio: 2 a 4 horas. Nota fiscal, proposta nova, cobrança, contrato, contabilidade.
• Comercial: 3 a 5 horas, se você quer continuar tendo cliente daqui a três meses. Quem para de prospectar quando está cheio cria o vale de faturamento dois meses depois.
• Contexto e imprevisto: o custo invisível. Trocar de projeto no meio do dia queima de 20 a 30 minutos por troca até você render de novo. Três projetos com trocas diárias comem facilmente 4 horas semanais só em recarga de contexto.

Sobram entre 22 e 28 horas de produção real. Esse é o seu estoque. Tudo que você vende acima disso, você paga com noite, fim de semana ou prazo furado.

A conta de capacidade em três passos

A conta é simples, e é a mesma que a gente roda na OCA antes de aceitar qualquer projeto novo.

1. Estime o consumo semanal de cada projeto, não o total

Projeto de 120 horas não significa nada sozinho. A pergunta certa é: quantas horas por semana esse projeto exige para cumprir o prazo combinado? Um app de 120 horas com entrega em 6 semanas consome 20 horas semanais. Com entrega em 12 semanas, consome 10. O mesmo projeto pode caber ou não caber na sua agenda dependendo só do prazo negociado.

2. Some e compare com o estoque, com folga de 20%

Se você tem 25 horas produtivas e os projetos ativos somam 24, você está tecnicamente ok e praticamente quebrado. Bug em produção do cliente antigo, retrabalho de feedback, uma gripe. Qualquer imprevisto estoura tudo, porque não existe folga. Trabalhe com 80% de ocupação como teto: 25 horas de estoque significam no máximo 20 horas vendidas por semana. Os 20% restantes são o seu seguro, e semana que ninguém usa o seguro é semana que você adianta entrega ou prospecta.

3. Limite o número de frentes, não só o número de horas

Duas frentes de 10 horas rendem mais que quatro de 5, mesmo somando o mesmo. Cada projeto ativo carrega custo fixo de comunicação e contexto que não diminui quando o projeto é pequeno. Na prática, para um dev solo:

• 1 projeto grande (15 a 20 horas semanais) + 1 pequeno ou manutenção (5 horas): configuração mais saudável.
• 2 projetos médios (10 horas cada): funciona, exige disciplina de bloco (dias ou turnos dedicados por projeto, nunca troca no meio do dia).
• 3 ou mais projetos com desenvolvimento ativo: quase sempre termina em atraso em pelo menos um. Contratos de manutenção com demanda esporádica não contam nessa régua, projeto com sprint e prazo contam.

Como dizer não sem perder o cliente (e sem perder o dinheiro)

O medo de recusar projeto é legítimo: você não sabe quando aparece o próximo. Só que aceitar sem capacidade não guarda o cliente, adia a perda. Ele descobre em quatro semanas que você não entrega, e aí você perde o projeto, a indicação e a reputação. Existem três respostas melhores que um sim impossível:

1. Negocie a data de início. "Consigo começar dia 15 do mês que vem com dedicação de verdade, ou começar amanhã atendendo mal. Prefiro te atender bem." Cliente sério espera duas ou três semanas por quem demonstra que leva prazo a sério. Quem não espera duas semanas era o cliente que ia te cobrar entrega diária.
2. Negocie o ritmo. Mesmo escopo, cronograma mais longo, com marcos claros. Muitos projetos não têm a urgência que o cliente declara na primeira call.
3. Repasse com curadoria. Indique outro dev de confiança e, se fizer sentido, fique com um papel de revisão. Isso não é teoria, é literalmente como a OCA cresceu: a demanda passou da capacidade do time e a resposta foi montar uma rede de repasse em vez de aceitar tudo e entregar mal.

Os sinais de que você já passou do limite

Quando a agenda estoura, o corpo e o projeto avisam antes da planilha. Reconheça os sintomas:

• Você começa o dia respondendo mensagens de clientes e só abre o editor depois do almoço.
• Os updates de progresso, que eram semanais e detalhados, viraram "tá andando, semana que vem te mostro".
• Você aceita reunião em qualquer horário porque não tem mais bloco protegido de produção.
• Bug simples leva dias para ser resolvido porque nunca é a prioridade de nenhum dos projetos.
• Você sente alívio quando um cliente some por uma semana. Esse é o mais grave: cliente sumido devia ser sinal de alerta, não de descanso.

Se marcou dois ou mais, a saída não é trabalhar mais rápido, é renegociar prazo com o projeto de menor risco agora, antes que ele estoure sozinho. Atraso comunicado com antecedência é gestão; atraso descoberto pelo cliente é quebra de confiança.

Capacidade é argumento de preço, não só de agenda

Tem um efeito colateral que pouca gente percebe: quem conhece a própria capacidade cobra melhor. Quando você sabe que tem 20 horas vendáveis por semana, cada hora tem custo de oportunidade concreto, e projeto que paga mal deixa de ser "dinheiro entrando" e vira "hora que eu poderia vender melhor". Dev sem conta de capacidade aceita R$ 60 a hora porque a agenda parece infinita. Dev com a conta feita entende que agenda é estoque finito e negocia como quem tem estoque finito. Se você já entrega bem, o seu problema não é técnico, é distribuição, e distribuição inclui saber o que recusar.

Onde a rede de parceiros entra nessa conta

Do lado da OCA, essa conta roda no sentido inverso. O blog e o SEO trazem dezenas de leads de clientes por dia, muito acima da capacidade do time. Em vez de inflar a equipe ou entregar mal, a gente qualifica os projetos, fecha escopo e repassa para uma rede de devs e times seniores de confiança. Para quem está na rede, isso significa projeto que chega com escopo cercado e cliente qualificado, sem custo de prospecção. Para entrar, o que a gente olha é justamente o que este artigo descreveu: histórico de entrega no prazo, comunicação de progresso decente e honestidade sobre a própria capacidade. Dev que diz "esse mês não consigo pegar mais nada" sobe na nossa lista, não desce, porque é o dev que não vai furar com o cliente que a gente repassou. Se você se encaixa nesse perfil, entre para a rede de parceiros da OCA e conta como está o seu pipeline hoje.

E uma ação para esta semana, independente de rede: abra uma planilha e faça a sua conta de capacidade. Horas produtivas reais, consumo semanal de cada projeto ativo, folga de 20%. Se o resultado der negativo, você não tem um problema de produtividade, tem um problema de excesso de venda, e a solução começa numa conversa de renegociação de prazo, não numa madrugada de código.