Mudança de escopo no meio do projeto freelance: como cobrar change request sem perder o cliente (com o texto pronto)
Lucas Annunziato · · 8 min de leitura
Você fechou o projeto por R$ 28 mil, oito semanas, escopo escrito na proposta. Na semana três chega um áudio no WhatsApp: "rapidinho, dá pra colocar um filtro por data naquela listagem?". Você coloca. Semana quatro: "esqueci de falar, precisa exportar em Excel também". Você coloca. Semana seis: "o financeiro quer um segundo nível de aprovação". Você coloca.
Na semana nove, o cliente acha que o projeto está atrasado e você acha que trabalhou de graça. Os dois estão certos ao mesmo tempo, e o culpado não é nenhum dos dois. É a ausência de um processo para tratar pedido novo depois que o contrato já começou.
Por que o prejuízo nunca vem do pedido grande
Quando o cliente pede um módulo inteiro, todo dev sabe responder. Você abre o orçamento, manda o adendo, negocia prazo. O pedido grande vem com etiqueta de pedido grande.
O prejuízo vem do que parece mesquinhez recusar. A conta é simples: doze pedidos de três horas ao longo do projeto dão 36 horas. A R$ 150 a hora, são R$ 5.400 de trabalho não faturado dentro de um contrato de R$ 28 mil. Quase 20% do valor do projeto evaporou em coisas que, uma a uma, custavam menos do que a conversa para cobrar por elas.
E o dano não para no dinheiro. Essas 36 horas empurraram a entrega em três semanas. Três semanas que atrasaram o próximo projeto, que atrasaram o pagamento do próximo marco, que fizeram você aceitar o projeto seguinte com desconto porque o caixa apertou. Escopo aberto não é um problema de um contrato, é um problema de agenda que se propaga por trimestres.
A verdade incômoda: o cliente não está te sacaneando
A leitura fácil é que o cliente é folgado e quer tirar vantagem. Na prática, quase nunca é isso. Software é invisível. O cliente não tem a menor noção se um filtro por data custa vinte minutos ou dois dias, e não existe motivo para ele ter. Ele está pedindo aquilo que faria o produto funcionar melhor para a operação dele, que é exatamente o que você quer que ele faça.
O problema é o que acontece depois do pedido. Se você respondeu "deixa comigo" na primeira vez sem falar de horas, você ensinou ao cliente que pedido novo é de graça. Ele vai repetir o comportamento porque você validou o comportamento. O contrato assinado na semana zero deixa de existir no instante do primeiro sim silencioso.
Cercar escopo não é desconfiar do cliente. É dar a ele a informação que ele não tem para decidir se aquele ajuste vale o custo.
Classifique o pedido antes de responder qualquer coisa
Antes de cobrar, você precisa saber o que é cobrável. Misturar bug com requisito novo é a forma mais rápida de parecer oportunista. Toda solicitação cai em uma destas quatro caixas.
| Tipo | Exemplo | Quem paga |
|---|---|---|
| Defeito | Está na proposta, foi entregue, não funciona | Você. Corrige e não cobra. |
| Refinamento | Trocar o texto de um botão, ajustar espaçamento, reordenar colunas | Ninguém. Sai do orçamento de refino já reservado. |
| Mudança de escopo | A tela existe, mas o comportamento combinado muda | Cliente, via change request. |
| Requisito novo | Funcionalidade que não estava em lugar nenhum | Cliente, via change request ou fase 2. |
Essa classificação resolve 80% do atrito. O cliente não briga com "isso é uma funcionalidade nova", ele briga com "agora você quer cobrar por tudo". Quando você conserta bug de graça na frente dele, a cobrança do requisito novo vira óbvia.
O processo de change request que cabe em um dev solo
Não precisa de comitê nem de ferramenta cara. Precisa de cinco regras que você cumpre sem exceção.
- Reserve o orçamento de refino na proposta. Escreva que o projeto inclui de 10% a 15% das horas para ajustes finos durante o desenvolvimento. Isso mata a discussão sobre mudar cor de botão e deixa claro que existe um limite.
- Um canal só, e por escrito. Áudio de WhatsApp não é especificação. Peça que todo pedido novo vire uma mensagem escrita, um card ou um e-mail. Você pode transcrever você mesmo e mandar de volta para confirmar, mas o registro tem que existir.
- Responda em até 24 horas com os três números. Horas estimadas, valor e impacto no prazo. Sempre os três. Change request que só mexe no preço e não mexe na data é a armadilha mais comum do freelance brasileiro.
- Tenha um bloco mínimo. Trabalhe com blocos de 4 horas. Pedido de 40 minutos entra em um lote junto com os próximos, e você fecha o lote quando ele atinge o bloco. Isso evita tanto o trabalho grátis quanto a microcobrança que irrita cliente.
- Aprovação escrita antes da primeira linha de código. Um "aprovado" no e-mail resolve. Para valores maiores, um adendo assinado em ZapSign ou Clicksign leva cinco minutos e vale como prova.
Sobre preço: em 2026, dev sênior freelancer no Brasil cobra entre R$ 90 e R$ 250 a hora, dependendo de stack, nicho e de quem é o cliente. O change request cobra a sua hora cheia, não uma hora com desconto. Se a hora do projeto saiu mais barata por causa do volume contratado, o pedido avulso não tem esse volume para justificar desconto. Isso não é ganância, é o motivo de existir preço por pacote.
O texto que você manda quando chega o "só um ajustezinho"
Boa, faz sentido esse filtro. Ele não estava no escopo fechado, então entra como solicitação de mudança. Estimo 6 horas, R$ 900, e empurra a entrega da fase 2 em 3 dias úteis. Se fizer sentido, me responde aqui com um ok que eu já encaixo no sprint atual. Se preferir, dá pra deixar para a fase seguinte e manter a data original de entrega.
Repare no que esse texto faz. Concorda com o mérito do pedido, nomeia o tipo, dá os três números e devolve a decisão para o cliente com duas saídas honestas. Ninguém se sente cobrado, todo mundo se sente informado. Na OCA a gente usa essa mesma estrutura em projeto de R$ 15 mil e em projeto de R$ 300 mil, e o texto muda pouquíssimo.
O que continua derrubando freelancer mesmo com processo
- "Depois a gente acerta." Change request acumulado para faturar no final nunca é pago inteiro. No final o cliente está avaliando a entrega, não lembrando de pedidos de dois meses atrás. Cobre no momento, ou inclua no marco seguinte com o valor já discriminado.
- Cobrar dinheiro e esquecer o prazo. Você fatura as 6 horas e continua devendo a entrega na data antiga. Resultado: recebeu certo e virou o dev que atrasa.
- Escrever a especificação do CR de graça. Se o pedido exige duas ou três horas só para entender o que o cliente quer, isso é descoberta e faz parte do CR. Estime primeiro por cima, e só detalhe depois do aceite.
- Tratar cada CR como renegociação de contrato. Se você faz cara de drama toda vez, o cliente para de pedir e o produto piora. Change request tem que ser rotina chata e rápida, não evento tenso.
- Deixar o cronograma de pagamento parado. Se o escopo cresceu 20%, os marcos precisam refletir isso. Senão você financia o crescimento do projeto com o seu caixa.
Escopo cercado é o que faz você receber o próximo projeto
Aqui entra a parte que quase ninguém conta. Vou te falar como funciona do lado de quem recebe os leads: a OCA aparece no Google e nas IAs para busca de desenvolvimento de software no Brasil, e isso traz mais demanda do que o time consegue atender. Por isso a gente mantém uma rede de parceiros, devs e times pequenos que recebem projetos já vendidos e escopados.
O filtro para entrar nessa rede não é só código. Todo mundo que chega entrega bem tecnicamente. O que separa os parceiros que continuam recebendo projeto dos que recebem um só é exatamente isso: saber dizer "isso é fora do escopo, custa X e empurra Y" sem criar crise com o cliente. Dev que absorve tudo calado estoura prazo, estoura margem e some. Dev que trata mudança como processo entrega na data e volta a ser chamado.
Isso não é teoria, é literalmente como a OCA cresceu. O portfólio de produtos que a gente opera, do Revo com mais de 40 mil usuários aos sistemas sob medida em produção, foi construído com essa disciplina de escopo, não com heroísmo de madrugada.
Se você já entrega bem, o seu problema não é técnico, é distribuição. A rede de parceiros existe para resolver o lado da demanda, e o que a gente espera do outro lado é senioridade técnica, comunicação direta com o cliente e previsibilidade de prazo. Sem promessa de volume, sem exclusividade, sem taxa de entrada.
Entre para a rede de parceiros da OCA
Independente disso, faça uma coisa esta semana: abra o projeto que você está tocando agora e liste todos os pedidos que entraram depois da assinatura. Some as horas. Se passar de 10% do contrato, você já está financiando o cliente. Mande o texto do change request no próximo pedido que chegar, mesmo que seja pequeno. A primeira vez é desconfortável. A partir da segunda, vira só mais uma mensagem no dia.
