Entrega de projeto freelance: o checklist de handoff que evita suporte de graça e transforma cliente em indicação (código, acessos e documentação)

Você fechou o projeto, cumpriu o prazo e o sistema está no ar. O cliente mandou um “ficou ótimo, obrigado” no WhatsApp e pagou a última parcela. Três meses depois chega a mensagem. O domínio expirou, ou o app saiu da loja porque a conta de desenvolvedor venceu, ou a funcionária nova não sabe cadastrar produto. Você resolve de graça, porque parece feio cobrar. E aquele cliente que ia te indicar para metade dos conhecidos nunca indicou ninguém.

Se você é dev freelancer, provavelmente já passou por isso pelo menos uma vez. O problema não foi o código, foi a entrega. É o jeito como o projeto termina que decide se ele vira suporte gratuito sem fim ou se traz o próximo cliente por indicação.

Por que o cliente lembra da entrega e não do seu código

A verdade desconfortável é que o cliente não técnico não tem como avaliar a sua arquitetura. Ele não sabe se você usou Next.js ou PHP, se tem teste automatizado ou se o banco está bem modelado. Ele avalia outras coisas: se consegue usar o sistema sozinho, se sabe o que fazer quando algo der errado e se o projeto terminou com sensação de controle ou de abandono.

E o fim pesa demais na memória do cliente. Você pode ter feito dez semanas impecáveis. Se a última semana foi uma troca confusa de senhas por mensagem e um “qualquer coisa me chama”, é disso que ele vai lembrar quando um amigo perguntar se ele conhece um bom desenvolvedor.

A gente vê isso o tempo todo nos leads que chegam à OCA. Uma parte dos contatos vem de empresas que têm o sistema funcionando e nenhum controle sobre ele. O repositório está na conta pessoal de um dev que não responde mais, o servidor está no cartão de alguém que saiu da empresa e ninguém sabe onde fica o painel do gateway. Muitas vezes o código está razoável. A entrega é que nunca aconteceu.

Para a sua carreira, isso tem uma consequência direta. O freelancer vive de reputação acumulada, e a reputação se constrói no encerramento de cada projeto. Se você já entrega bem, o seu problema não é técnico, é distribuição. E uma entrega bem feita é o canal de distribuição mais barato que existe.

Checklist de handoff: o que entregar além do código

Handoff é o pacote que permite ao cliente operar o produto sem você e a qualquer outro dev continuar o trabalho. Na prática, são cinco blocos.

1. Repositório no nome do cliente

• Transfira o repositório para uma organização do cliente no GitHub ou no GitLab. Se houver manutenção contratada, você continua como colaborador.
• Escreva um README que permita rodar o projeto do zero, com as versões (Node, gerenciador de pacotes, Expo), os comandos e as variáveis de ambiente.
• Inclua um .env.example com todas as variáveis e uma linha explicando cada uma. O .env real nunca vai para o repositório.
• Crie uma tag de versão (v1.0.0) marcando exatamente o que foi aceito. Isso encerra a discussão sobre “isso já estava assim na entrega?”.

2. Contas e acessos no cartão do cliente

É o bloco que mais dá dor de cabeça. Faça um inventário de todas as contas que o produto usa e confirme que cada uma está no nome e no cartão do cliente:

• Domínio (Registro.br ou outro registrador) e DNS.
• Hospedagem e banco: Vercel, Supabase, AWS, Render.
• Lojas de aplicativo: Apple Developer Program (US$ 99 por ano) e Google Play Console (taxa única de US$ 25). A conta precisa ser do cliente, de preferência no CNPJ dele.
• Gateway de pagamento, e-mail transacional, APIs de IA, analytics e monitoramento de erros.

As credenciais vão por um gerenciador de senhas compartilhado, nunca por WhatsApp. O Bitwarden e o 1Password têm planos para isso. Operando o Revo em produção, com mais de 40 mil usuários, a gente aprendeu a tratar vencimento como risco técnico: certificado, cartão da hospedagem, conta da loja, chave de API. Nada disso aparece no code review, e qualquer um desses itens tira um produto do ar.

3. Duas documentações para dois leitores

A documentação técnica é para o próximo dev, que pode ser você daqui a um ano. Uma página basta. Coloque a visão geral da arquitetura, as decisões importantes e o porquê de cada uma, as dívidas técnicas conhecidas e o que você faria a seguir.

A documentação operacional é para o cliente e não leva jargão. Ela explica como cadastrar um usuário, como emitir um relatório e o que fazer se o login parar. Inclua também uma tabela com o custo mensal do produto. Quase nenhum freelancer entrega isso, e todo cliente agradece:

Os valores mudam com o volume de uso e com o câmbio. Mesmo assim, a tabela evita a pior conversa possível, que é o cliente descobrir um custo pela fatura do cartão.

4. Call de entrega gravada

Reserve de 60 a 90 minutos, grave a call e siga um roteiro fixo:

1. O cliente executa o fluxo principal sozinho, e você só observa.
2. Você mostra onde ficam os acessos e a documentação.
3. Vocês revisam juntos a tabela de custos e vencimentos.
4. Você explica o que entra na garantia e o que vira pedido novo.
5. Vocês combinam o próximo contato, que pode ser a manutenção mensal ou um check-in em 30 dias.

Mande o link da gravação junto com a documentação. Quando a funcionária nova perguntar como cadastra produto, o cliente tem para onde encaminhar a dúvida, e esse lugar não é o seu WhatsApp.

5. Termo de aceite

O termo é um documento de uma página. Ele registra o que foi entregue (com referência à tag de versão), a data, o início da garantia e o aceite do cliente. O termo libera a última parcela e marca o fim do escopo. Sem aceite, o projeto nunca termina, só vai se arrastando.

Quanto tempo o handoff leva e como cobrar por ele

A conta é simples. Em um projeto de 6 a 10 semanas, um handoff completo leva de 8 a 16 horas, somando inventário de contas, migração da cobrança, documentação, call e aceite. Com a hora entre R$ 150 e R$ 250, isso dá de R$ 1.200 a R$ 4.000 de trabalho.

O número sobe quando o projeto tem app nas lojas, porque criar e verificar a conta de desenvolvedor do cliente pode levar de dias a semanas (a Apple exige número D-U-N-S para conta de empresa). Também sobe quando há muitas integrações ou quando o cliente nunca teve conta em serviço nenhum. Cai quando você monta modelos reutilizáveis de README, documentação operacional e termo de aceite.

O erro é deixar isso fora da proposta. Handoff sem orçamento é feito no fim do projeto, de graça e com você cansado, e sai malfeito. Coloque o handoff como um marco próprio, com os entregáveis listados. Isso também educa o cliente, que passa a ver valor em receber o produto organizado.

Como pedir indicação e depoimento depois da entrega

Não peça indicação na call de entrega. Nesse momento o cliente viu o produto, mas ainda não viu resultado. A hora certa é de duas a quatro semanas depois do go-live, quando aparece o primeiro sinal concreto: o primeiro pedido feito pelo sistema, a planilha aposentada, o atendimento mais rápido.

E faça um pedido específico. “Se souber de alguém, me indica” não gera nada. Funciona melhor um pedido que descreve a situação:

Oi, [nome]. Vi que o sistema já processou os primeiros [X] pedidos, que bom. Uma pergunta: você conhece alguém que ainda controla [processo] em planilha, como vocês faziam antes? Se fizer sentido, posso conversar com a pessoa sem compromisso.

No depoimento, facilite a vida do cliente. Mande três perguntas curtas: qual era o problema, o que mudou e como foi trabalhar junto. Outra opção é escrever um rascunho com o que ele já te disse e pedir que ajuste e aprove. Na mesma mensagem, peça autorização para mostrar o projeto no seu portfólio, com ou sem o nome da empresa.

As armadilhas que transformam entrega em suporte de graça

• Tudo no seu nome. Conta da Apple na sua conta pessoal, servidor no seu cartão. Durante o projeto parece mais rápido. Seis meses depois, você está pagando a hospedagem de um cliente que não responde, ou ele não consegue trocar de fornecedor e começa a falar mal de você.
• Entrega sem aceite. O “só mais um ajustezinho” vira mais duas semanas, e a última parcela fica presa a algo que ninguém definiu.
• Senha no WhatsApp. Ela se perde no histórico, vaza num print, e ninguém sabe qual é a versão atual.
• “Qualquer coisa me chama”. Soa gentil, mas funciona como um contrato de suporte ilimitado e sem preço. Troque essa frase por uma garantia com prazo definido e uma proposta de manutenção.
• Sumir depois do pagamento. Um check-in de 30 dias custa 15 minutos, e é ali que costumam nascer as indicações e os contratos recorrentes.

O que a OCA olha na entrega antes de repassar um projeto

Vou te falar como funciona do lado de quem recebe os leads. A OCA aparece no Google e nas IAs em buscas sobre desenvolvimento de software no Brasil, e isso traz dezenas de contatos de clientes por dia, mais do que o time consegue atender. Por isso estamos montando uma rede de parceiros: devs seniores e times pequenos que recebem projetos já qualificados e com escopo definido.

Quando a gente repassa um projeto, o nome da OCA continua na relação com o cliente. Por isso, a avaliação de um parceiro não para na qualidade do código. Também olhamos se ele fecha projeto direito: repositório e contas no nome do cliente, documentação que alguém consegue ler, aceite formal e comunicação clara até o último dia. É exatamente o checklist deste artigo.

Para o parceiro, a troca é direta. Você recebe projetos que já passaram por qualificação e definição de escopo, e gasta seu tempo entregando em vez de prospectar. Não prometemos volume nem aprovação automática, porque avaliamos cada perfil e o encaixe com cada projeto. Se quiser ver o tipo de produto que sai daqui, o portfólio de projetos da OCA mostra o que está em produção.

Entre para a rede de parceiros da OCA

Uma ação para esta semana

Entrando ou não na rede, pegue o último projeto que você entregou e faça o inventário de contas: domínio, hospedagem, banco, lojas, gateway e APIs. Ao lado de cada uma, anote em nome de quem ela está e em qual cartão é cobrada. Se alguma estiver no seu nome, mande hoje mesmo uma mensagem ao cliente propondo a migração. Isso leva uma tarde e evita a dor de cabeça mais comum do freelance.