Proposta comercial para dev freelancer: a estrutura de 7 blocos que fecha projeto (e o follow-up quando o cliente some)

Você fez a call. O cliente gostou, fez perguntas boas e disse “manda a proposta que eu vejo com meu sócio”. Você passou a noite montando um PDF com a stack, a lista de telas e um número no final. Mandou no WhatsApp. Ele visualizou. E nunca mais respondeu.

Isso acontece com quase todo dev que começa a freelar, e a explicação que a gente se dá costuma ser o preço: “devo ter cobrado caro”. Às vezes é isso. Na maioria das vezes, não é. O cliente sumiu porque recebeu um documento que não sabia ler, que não conseguia comparar com as outras propostas na mesa e que não dizia qual era o próximo passo. Na dúvida, ele não decide. E não decidir parece seguro.

Este artigo é sobre o documento que vem depois da call: o que colocar, em que ordem, como apresentar o preço e o que fazer quando o cliente some. Com a estrutura que eu uso e um exemplo com números.

Proposta não é orçamento: o que o cliente realmente compara

Vou te falar como funciona do lado de quem recebe os leads: boa parte das pessoas que chegam na OCA já falou com outro fornecedor ou ainda vai falar. O cliente não técnico não compara arquitetura. Ele não sabe se Next.js é melhor que Laravel para o caso dele, e não vai aprender até sexta. O que ele compara é risco:

• Esse dev entendeu o meu problema ou só anotou a lista de funcionalidades?
• Eu sei exatamente o que vou receber, e o que não vou?
• Se der errado no meio, o que acontece com o meu dinheiro?
• Quanto custa e quando fica pronto, sem asterisco?

Uma proposta que só tem stack e um número responde apenas a última pergunta. As outras três ficam no ar, e quem responde melhor costuma ganhar, mesmo cobrando mais. É comum o cliente fechar com a proposta mais cara porque era a única que dizia com clareza o que estava fora do escopo. Ele lê aquilo como honestidade.

A verdade incômoda: se você entrega bem e perde propostas, o problema raramente é técnico. É comunicação de risco.

A estrutura de proposta comercial em 7 blocos

Duas a quatro páginas. Mais do que isso, ninguém lê. Menos do que isso, falta o que protege você. Pode ser Google Docs, Notion ou Figma exportado em PDF. O formato importa menos que a ordem.

1. O problema, nas palavras do cliente

Abra com dois ou três parágrafos que repetem o que ele disse na call, usando os termos dele. “Hoje a equipe agenda 120 atendimentos por semana pelo WhatsApp e perde em média um por dia por conflito de horário.” Se ele ler e pensar “é isso”, você já está na frente. Por isso anotar números durante a call vale mais do que anotar funcionalidades.

2. O resultado esperado

O que muda quando o projeto estiver no ar. Não prometa faturamento. Descreva a operação: “a recepção para de confirmar horário manualmente, o paciente agenda e recebe lembrete sozinho”. É essa frase que o decisor vai repetir para o sócio.

3. Escopo: o que está incluído e o que não está

Liste entregas, não tarefas técnicas. “Painel para a recepção ver a agenda do dia” em vez de “CRUD de agendamentos”. Logo abaixo, uma seção explícita de fora do escopo: app nativo, integração com o emissor de nota fiscal, migração de dados antigos, o que for. Esse bloco é o que mais evita briga no terceiro mês.

4. Como o projeto vai andar

Marcos com data e o que o cliente vê em cada um. Três a cinco marcos para projetos de 6 a 12 semanas. Diga também como ele acompanha: uma reunião semanal de 30 minutos, um link de homologação, um resumo por escrito. Cliente não técnico tem medo de pagar e ficar no escuro.

5. Investimento em opções

Três opções de escopo com preço fechado. Detalho no próximo tópico porque é onde a maioria erra.

6. Condições

Forma de pagamento atrelada aos marcos, prazo de garantia, quem é dono do código e quando ele é entregue, e a validade da proposta. Use validade de 10 a 15 dias. Sem validade, a proposta vira uma opção eterna na gaveta do cliente, e o seu preço de outubro continua valendo em março.

7. Um único próximo passo

Termine com uma ação concreta: “Para começar em 20/10, basta responder com a opção escolhida. Envio o contrato no mesmo dia e a primeira parcela libera o kickoff.” Uma ação, uma data. Nada de “fico à disposição para dúvidas”.

Como apresentar o preço na proposta (com exemplo em reais)

Preço único transforma a decisão em sim ou não. Três opções transformam a decisão em “qual delas”. A conta é simples: quando o cliente está escolhendo entre opções suas, ele parou de comparar você com os outros.

Exemplo de um sistema web de agendamento para uma clínica com três unidades, com valores na faixa de um dev sênior em 2026:

Algumas regras que fazem isso funcionar:

• A opção do meio é a que você quer vender. Monte ela primeiro, com o escopo que resolve o problema de verdade. As outras saem dela.
• A opção menor corta escopo, não qualidade. Mesmo padrão de código, mesmos testes, menos funcionalidades.
• Nada de “a partir de” ou “aproximadamente”. Se o escopo está incerto demais para cravar um número, você precisa de uma fase de discovery paga antes, não de uma proposta.
• Mostre o valor da parcela de entrada. Para muito cliente pequeno, a pergunta real é “quanto sai do caixa este mês”.

Esses números se movem com integrações (cada API de terceiro mal documentada pode somar uma a duas semanas), com quem fornece o design e com o nível de exigência de segurança e LGPD. Deixe isso escrito como premissa da proposta.

A proposta não vai sozinha no WhatsApp

O erro mais caro é mandar o PDF e esperar. Marque uma call de 20 a 30 minutos para apresentar a proposta, de preferência até 48 horas depois da conversa inicial, enquanto o problema ainda está quente na cabeça do cliente. Compartilhe a tela, passe bloco por bloco e pare no escopo e no fora do escopo. Objeção dita em voz alta você responde na hora. Objeção pensada sozinho às 23h vira silêncio.

Se o decisor não estiver na call, peça para ele estar. Proposta repassada por intermediário perde metade do contexto no caminho.

Cliente sumiu depois da proposta: o follow-up que não soa desesperado

Mesmo com tudo certo, parte dos clientes vai sumir. Quase sempre não é rejeição, é prioridade. A cadência que funciona é curta e tem fim:

1. Dia 2: “Oi, Fulano. Conseguiu ver a proposta com o seu sócio? Se ajudar, faço uma call de 15 minutos com vocês dois para tirar dúvidas.”
2. Dia 5: mande algo útil, não uma cobrança. “Lembrei de vocês: coloquei o lembrete por WhatsApp na opção Recomendada porque é o que mais costuma reduzir falta em agenda. Se quiser, te explico como funciona.”
3. Dia 10, perto da validade: “A proposta vale até sexta. Depois disso preciso reavaliar a data de início. Querem seguir, ajustar o escopo ou deixar para depois?”
4. Encerramento: “Como não tive retorno, vou entender que o momento não é agora. Quando fizer sentido retomar, é só me chamar.”

A mensagem de encerramento costuma ser a que mais recebe resposta, porque dá ao cliente uma saída educada. E a resposta “deixar para depois” também é informação: você para de contar com aquele dinheiro e ajusta o seu pipeline em vez de esperar um projeto que não vem.

Os erros que fazem a proposta perder (mesmo com preço certo)

• Proposta de 20 páginas com arquitetura detalhada. O cliente não lê, e você entregou de graça o plano para o concorrente executar.
• Template genérico com o nome trocado. Se o bloco do problema serve para qualquer cliente, ele não convence nenhum.
• Desconto oferecido antes de alguém pedir. “Consigo fazer por menos se fechar essa semana”, escrito na própria proposta, comunica que o preço é chute.
• Sem fora do escopo. Funciona até a primeira reunião em que alguém diz “mas eu achei que o app estava incluído”.
• Pagamento 100% no final. Isso não é proposta, é empréstimo sem juros para o cliente.
• Uma semana para mandar. Enquanto você caprichava, outro dev mandou algo razoável em dois dias e já marcou a apresentação.

Por que a OCA olha a sua proposta antes do seu código

Vou ser transparente sobre o motivo de eu insistir nesse assunto. A OCA aparece no Google e nas IAs quando alguém procura desenvolvimento de software no Brasil, e isso traz dezenas de leads por dia, mais do que o nosso time consegue atender. Isso não é teoria, é literalmente como a OCA cresceu. Por isso estamos montando uma rede de parceiros: devs e pequenos times seniores que recebem projetos já qualificados e com escopo.

O que a gente observa antes de repassar um projeto não é só código. É se você consegue colocar escopo no papel, dizer o que não está incluído, propor marcos e manter o cliente informado sem ninguém precisar cobrar. Se você sabe escrever uma proposta como a deste artigo, metade da conversa já está feita. A outra metade é o seu histórico de entrega, que você pode mostrar do jeito que a gente mostra os projetos que a OCA tem em produção.

O que o parceiro ganha: projetos que chegaram por demanda real, com o cliente pré-qualificado, sem disputar preço em plataforma. O que a gente não promete: volume fixo de projetos nem entrada automática na rede. Cada parceiro passa por conversa e avaliação, e o encaixe depende do tipo de projeto que está chegando naquele momento.

O próximo passo para esta semana

Pegue a última proposta que você perdeu ou que ficou sem resposta. Reescreva com os 7 blocos: problema nas palavras do cliente, resultado esperado, escopo e fora do escopo, marcos, três opções de preço, condições com validade e um único próximo passo. Compare com a versão original. Se a nova cabe em três páginas e responde as quatro perguntas de risco, ela vira o seu modelo para os próximos clientes.

Se você já entrega bem, o seu problema não é técnico, é distribuição. E se quiser receber projetos sem depender só do seu próprio pipeline, me chama:

Entre para a rede de parceiros da OCA