Quantos projetos freelance dá para tocar ao mesmo tempo: a conta de capacidade que evita atraso e burnout

Você fechou o primeiro projeto. Depois o segundo. Aí apareceu um terceiro, pagando bem, e você pensou: "eu dou conta, é só apertar". Três semanas depois, os três estão atrasados, você responde cliente às 23h e a qualidade do código caiu junto com o seu sono. Ninguém te ensinou a fazer a conta de capacidade, e essa conta é a diferença entre um freelancer que constrói reputação e um que queima três clientes de uma vez.

Vou te falar como funciona do lado de quem recebe os leads: na OCA, a gente recusa ou repassa projeto toda semana. Não porque falta vontade, mas porque aceitar acima da capacidade destrói exatamente o que faz o cliente pagar bem: previsibilidade. Este artigo é a conta que a gente faz internamente, adaptada para quem trabalha sozinho.

A verdade desconfortável: sua semana não tem 40 horas produtivas

O erro clássico é planejar como se toda hora acordado fosse hora de código. Não é. Uma semana realista de um dev freelancer solo se divide mais ou menos assim:

• Código produtivo de verdade: 20 a 25 horas. Não 40. Foco profundo tem teto, e depois de 5 horas por dia a qualidade despenca.
• Comunicação com clientes: 4 a 8 horas. Call de alinhamento, responder WhatsApp, escrever status report, revisar feedback.
• Administrativo: 2 a 4 horas. Nota fiscal, proposta nova, contrato, cobrança, contabilidade.
• Comercial: 3 a 5 horas. Se você não prospecta enquanto entrega, o pipeline zera quando o projeto acaba, e você volta para a estaca zero.

Somando, sobram 20 a 25 horas de entrega real por semana. Quem vende 40 horas de código por semana está vendendo hora que não existe, e vai pagar com atraso ou com a própria saúde.

A conta de capacidade: quantos projetos cabem na sua agenda

A conta é simples. Pegue suas horas produtivas reais (digamos 22 por semana) e distribua entre os projetos ativos considerando o custo de troca de contexto:

• 1 projeto: 22 horas úteis. Zero perda por contexto. Velocidade máxima, mas risco máximo: se o cliente atrasar um pagamento ou pausar o projeto, sua renda vai a zero.
• 2 projetos: cerca de 10 horas úteis cada. Você perde 1 a 2 horas por semana só trocando de cabeça entre bases de código, mas ganha resiliência financeira. Para a maioria dos devs solo, este é o ponto ideal.
• 3 projetos: 6 a 7 horas úteis cada. A troca de contexto come 3 a 4 horas semanais. Só funciona se pelo menos um dos três for manutenção leve ou sustentação, não desenvolvimento ativo.
• 4 ou mais: você não está entregando quatro projetos, está atrasando quatro projetos em paralelo.

Uma regra prática que usamos: no máximo dois projetos de desenvolvimento ativo por dev, mais um ou dois contratos de manutenção. Manutenção é demanda intermitente e previsível, então convive bem com desenvolvimento. Dois projetos greenfield ao mesmo tempo já exigem disciplina; três é aposta.

Como montar a agenda: blocos, não malabarismo

Capacidade no papel não vale nada se a execução for reativa. O que funciona na prática:

Divida a semana em blocos por cliente

Segunda e terça para o projeto A, quarta e quinta para o projeto B, sexta para administrativo, comercial e imprevistos. Alternar cliente a cada duas horas parece flexível, mas cada troca custa 20 a 30 minutos para recarregar o contexto do código. Blocos de dia inteiro preservam o foco profundo.

Comunique a janela de resposta, não disponibilidade infinita

Cliente que recebe resposta às 23h aprende que você está disponível às 23h. Defina no início do projeto: "respondo mensagens em até 4 horas úteis, calls às terças e quintas". Isso não é frescura, é o que permite você entregar. Cliente sério respeita; cliente que exige resposta imediata para tudo é red flag de projeto que vai te consumir.

Reserve buffer, porque imprevisto não é imprevisto

Em 7 anos entregando software, nunca vi uma semana sem imprevisto: bug em produção de um cliente antigo, deploy que quebrou, review que voltou. Se sua agenda está 100% alocada, qualquer imprevisto vira atraso em cascata. Aloque 80% e deixe 20% de folga. Parece perda de dinheiro; é o que garante que você cumpre prazo, e prazo cumprido é o que faz cliente indicar você.

As armadilhas de quem diz sim demais

O projeto "rapidinho" que entra na fresta. "É só uma landing page, uma semana no máximo." Não existe projeto de uma semana com cliente novo: tem onboarding, briefing, feedback, ajuste, deploy, nota fiscal. O rapidinho vira três semanas e desloca os projetos que pagam de verdade.

Aceitar agora para começar depois, sem contrato de reserva. Você fecha um projeto para daqui a um mês, o cliente some no meio do caminho e você recusou trabalho nesse intervalo. Se vai reservar agenda futura, cobre sinal na assinatura. Agenda reservada de graça é prejuízo silencioso.

Confundir pico de demanda com novo normal. Chegaram três propostas no mesmo mês e você aceita todas achando que agora é sempre assim. Aí passa três meses sufocado e os três meses seguintes vazio, porque não prospectou enquanto entregava. Demanda de freelancer é onda, e a agenda tem que assumir isso.

Medo de recusar. Todo dev no início acha que recusar projeto é queimar ponte. É o contrário: "minha agenda abre em março, posso te colocar na fila?" transmite exatamente o sinal de profissional demandado que faz o cliente valorizar sua hora. Quem aceita tudo na hora parece disponível demais, e disponível demais negocia por baixo.

E quando a demanda passa da sua capacidade?

Se você chegou ao ponto de recusar projeto bom por falta de agenda, parabéns: esse é um problema de gente que entrega bem. Você tem três saídas honestas:

1. Subir o preço. Demanda acima da capacidade é o sinal mais claro de que sua hora está barata. Reajuste para os próximos orçamentos e deixe o mercado filtrar.
2. Formar parceria com outro dev. Repassar projeto para alguém de confiança, com você fazendo a ponte com o cliente, é o embrião de uma operação maior. Mas exige alguém que você conheça de verdade: o nome em jogo é o seu.
3. Entrar em uma rede que já resolve a ponta comercial. O gargalo inverso também existe: tem dev com agenda livre e zero pipeline, e tem operação com pipeline transbordando e agenda cheia.

A OCA vive o segundo caso. A gente aparece no Google e nas IAs para buscas de desenvolvimento de software no Brasil, e isso traz dezenas de leads de clientes por dia, mais do que o time consegue atender. Isso não é teoria, é literalmente como a OCA cresceu. A resposta foi montar uma rede de parceiros: devs seniores e times pequenos que recebem projetos já qualificados, com escopo fechado e cliente educado sobre prazo e orçamento. O parceiro entra na parte que ele faz bem, que é entregar, sem carregar a parte comercial sozinho.

Sendo transparente sobre o que esperamos: entrega no prazo combinado, comunicação proativa quando algo ameaça o cronograma (antes do estouro, não depois) e código que outra pessoa consegue dar manutenção. Exatamente as habilidades que a gestão de capacidade deste artigo treina. Quem quiser ver o tipo de projeto que a gente constrói e repassa, o portfólio da OCA dá uma boa noção do padrão.

O próximo passo

Se você entrega bem e quer receber projetos qualificados sem montar a máquina comercial do zero:

Entre para a rede de parceiros da OCA

E independente disso, uma ação para esta semana: abra sua agenda e some quantas horas você vendeu contra quantas horas produtivas você tem de verdade, usando a conta lá de cima. Se o número vendido for maior que o real, você já sabe qual projeto está subsidiando o atraso dos outros. Resolver isso antes do estouro é mais barato do que pedir desculpa depois.