Como escrever uma proposta de projeto freelance que fecha: a estrutura que a OCA usa (e os erros que matam a venda)

Você fez a call com o cliente, entendeu o problema, foi embora animado. Aí sentou pra escrever a proposta e travou. Acabou mandando um PDF de duas páginas com uma lista de funcionalidades e um preço no final. O cliente respondeu "vou analisar" e nunca mais apareceu. Se isso já aconteceu com você, o problema quase nunca foi o preço. Foi a proposta. A maioria dos devs escreve proposta como orçamento de oficina mecânica: lista de peças e valor. Cliente não compra lista de peças. Cliente compra a segurança de que você entendeu o problema dele e vai resolver sem dor de cabeça.

Vou te falar como funciona do lado de quem recebe os leads: na OCA a gente manda proposta toda semana, e a taxa de fechamento mudou de patamar quando a gente parou de vender funcionalidade e começou a vender diagnóstico. A estrutura que uso está toda aqui embaixo. Não tem segredo, tem método.

Por que sua proposta não fecha (e não é o preço)

Quando um cliente não técnico recebe três propostas, ele não consegue comparar qualidade de código. Ele compara o que consegue avaliar: quem demonstrou entender o negócio dele, quem foi mais claro sobre o que está incluso e quem passou menos sensação de risco. O preço só vira critério de desempate quando todo o resto empatou. E se a sua proposta é uma lista de features com um número no final, todo o resto empatou por baixo.

Os três erros que vejo com mais frequência em proposta de dev:

• Começar pela solução. A proposta abre com "desenvolvimento de aplicativo em React Native com backend Node". O cliente não sabe o que é isso e não deveria precisar saber. Ele quer ler o problema dele descrito com as palavras dele.
• Escopo em tópicos vagos. "Módulo de cadastro", "painel administrativo", "integração com pagamento". Cada um desses tópicos pode ser interpretado de cinco formas. Vagueza na proposta vira briga na entrega.
• Um preço só, pegar ou largar. Sem opções, a única decisão possível do cliente é sim ou não. E quando a decisão é binária e cara, a resposta padrão é "deixa eu pensar".

A estrutura de proposta que fecha: 7 blocos na ordem certa

Essa é a espinha dorsal que a OCA usa. Adapte o tom, mas respeite a ordem, porque ela segue a ordem em que o cliente decide.

1. Diagnóstico: o problema com as palavras do cliente

Um ou dois parágrafos descrevendo a situação atual do cliente e o que ela custa pra ele. Use as frases que ele mesmo falou na call. Se ele disse "a gente perde pedido porque o WhatsApp vira bagunça no fim de semana", escreva exatamente isso. Esse bloco sozinho já te separa de 80% das propostas concorrentes, porque prova que você ouviu.

2. Objetivo do projeto em uma frase

Não é a lista de features. É o resultado: "centralizar os pedidos em um sistema único para que nenhum pedido de fim de semana se perca". Se você não consegue escrever essa frase, você não entendeu o projeto e não deveria mandar proposta ainda. Volte e faça outra call.

3. Escopo cercado: o que entra e, principalmente, o que não entra

Aqui mora a diferença entre um projeto lucrativo e seis meses de retrabalho. Para cada entrega, descreva o comportamento, não o nome do módulo. Em vez de "painel administrativo", escreva "painel web onde o gestor visualiza pedidos do dia, altera status e exporta relatório em CSV. Não inclui gestão de estoque nem múltiplos níveis de permissão". A seção "fora do escopo" é a cláusula que salva sua margem. Tudo que o cliente mencionou na call e você não vai fazer nessa fase precisa estar listado ali, por escrito.

4. Fases e prazos com marcos de entrega

Quebre em fases com entregável visível: descoberta e protótipo (1 a 2 semanas), MVP funcional (4 a 8 semanas, dependendo do escopo), ajustes e publicação (1 a 2 semanas). Prazo sem marco é promessa; prazo com marco é plano. E cada marco deve estar amarrado a uma parcela do pagamento.

5. Investimento com duas ou três opções

Apresente o preço em formato de escolha, não de veredito. Uma versão enxuta (só o essencial pra resolver o problema central), a recomendada (essencial mais o que dá robustez) e, se fizer sentido, uma completa. A conta é simples: quando existe opção, a pergunta na cabeça do cliente muda de "fecho ou não fecho?" para "qual eu fecho?". Só não invente opção artificial pra inflar a do meio; cliente percebe.

6. Condições: pagamento, garantia e o que você precisa dele

Sinal de 30 a 40% pra entrar na agenda, parcelas atreladas aos marcos, última parcela na entrega. Período de garantia definido (30 a 90 dias para correção de bugs do escopo entregue, não para features novas). E a lista do que o cliente precisa fornecer: acessos, conteúdo, decisões. Atraso do lado dele estende o prazo do seu lado, e isso escrito na proposta evita a conversa mais desgastante do freelance.

7. Validade e próximo passo

Proposta sem validade apodrece na caixa de entrada. Coloque 10 a 15 dias, com justificativa real: sua agenda de início depende do aceite. E termine com um próximo passo concreto: "para iniciar, basta responder este e-mail confirmando a opção escolhida; envio o contrato no mesmo dia". Nunca termine com "fico à disposição". Disposição não fecha projeto.

Quanto detalhe colocar antes de fechar: o limite da consultoria grátis

Tem uma armadilha aqui. Proposta boa demonstra que você entendeu o problema, mas não entrega a solução de graça. Se você mandar arquitetura detalhada, modelagem de dados e definição de stack no documento, o cliente pode pegar sua proposta e executar com o dev mais barato que aparecer. Aconteceu comigo no começo e acontece com todo mundo uma vez.

A régua que uso: a proposta descreve o quê e quanto, nunca o como em profundidade. Diagnóstico e comportamento das entregas, sim. Diagrama de arquitetura e escolhas técnicas justificadas, só depois do sinal pago. Se o cliente exige o detalhamento técnico antes de fechar, isso tem nome: fase de descoberta, e é paga.

Os erros que matam a proposta depois de enviada

• Mandar e sumir. Proposta enviada sem follow-up agendado é proposta perdida. Combine na própria call: "te mando até quinta e te chamo na segunda pra tirar dúvidas". Assim o follow-up é compromisso, não insistência.
• Negociar preço cortando margem em vez de cortar escopo. Se o cliente diz que está caro, a resposta certa é "o que a gente tira da primeira fase?", nunca "consigo fazer por menos". Desconto sem contrapartida ensina o cliente que seu preço era inflado.
• Proposta genérica reaproveitada. Cliente percebe template em dez segundos. Reaproveite a estrutura, nunca o diagnóstico.
• PDF de 15 páginas. Ninguém lê. Três a cinco páginas resolvem qualquer projeto de freelance. Clareza vende mais que volume.

O que uma proposta bem escrita diz sobre você (do lado de quem repassa projeto)

Isso não é teoria, é literalmente como a OCA cresceu. A gente aparece no Google e nas IAs, e chegam mais leads de cliente por dia do que o time consegue atender. Parte desses projetos a gente repassa para uma rede de devs parceiros de confiança, com escopo fechado e cliente já qualificado.

E sabe qual é um dos primeiros filtros quando avalio um dev pra rede? Como ele se comunica por escrito. Um parceiro que sabe cercar escopo, definir marco e documentar o que não entra no projeto é um parceiro que não vai gerar problema com o cliente lá na frente. Se você já entrega bem, o seu problema não é técnico, é distribuição. E a proposta é exatamente o ponto onde competência técnica encontra distribuição: é o documento que transforma conversa em contrato.

Se você quer receber projetos já escopados, com cliente vetado e sem precisar caçar lead, a porta é essa:

Entre para a rede de parceiros da OCA

O próximo passo desta semana

Independente da rede, faça isto: pegue a última proposta que você enviou e não fechou. Reescreva só o primeiro bloco, trocando a descrição da solução por um diagnóstico com as palavras do cliente. Depois adicione a seção "fora do escopo". Essas duas mudanças sozinhas já colocam sua próxima proposta na frente da maioria. Quer ver como uma equipe que fecha projeto toda semana se apresenta? O portfólio da OCA mostra o padrão de comunicação que a gente espera dos parceiros também.