RFP para desenvolvimento de software: por que a maioria dos fundadores não-técnicos está usando o instrumento errado
Uma founder com quem conversamos no trimestre passado mandou o mesmo RFP de 11 páginas para cinco fábricas de software. Empresa pre-seed, dois pilotos enterprise assinados, janela de seis semanas para colocar uma v1 funcionando para o primeiro cliente pagante. O RFP era um template que ela tinha baixado de um blog de procurement: company background, project goals, scope of work, technical requirements, evaluation criteria, deadline. Parecia profissional. Parecia a coisa responsável a fazer.
Três fábricas não responderam. As duas que responderam mandaram propostas com R$ 450 mil de diferença sobre o mesmo escopo. Nenhuma fez a pergunta que importava, que era se ela realmente precisava de tudo que tinha escrito. Ela escolheu a mais barata. Seis meses depois estava no terceiro project manager e o cliente seguia usando uma planilha.
É assim que um RFP para desenvolvimento de software se parece quando o instrumento não combina com o trabalho. É também o que a maioria dos artigos que ranqueiam essa busca não enxerga: a pergunta não é como escrever o RFP, é se o RFP é a coisa certa para escrever.
O que um RFP para desenvolvimento de software realmente é
Um RFP, ou Request for Proposal, é um documento formal de procurement. O comprador envia para uma shortlist conhecida de vendors descrevendo o que precisa ser construído, em que prazo, sob quais restrições, e como as propostas serão avaliadas. Os vendors respondem com uma proposta estruturada: escopo, time, cronograma, preço, referências. O comprador avalia as respostas contra os critérios do documento e escolhe o vencedor.
O instrumento existe porque fazer procurement em escala é difícil. Quando um departamento de TI da Fortune 500 compra um CRM, uma agência regulada contrata um integrador, ou uma rede hospitalar seleciona um EHR, o RFP impõe três coisas: campo nivelado para os vendors, rastro documental para a decisão, e escopo contratual definido para o comprador não levar a culpa quando o projeto desandar. Para esse tipo de compra, o RFP é o documento certo.
Para um fundador não-técnico contratando uma construção custom de software no pre-seed, seed, ou Série A, essas três propriedades não se aplicam. Os fornecedores são uma comunidade pequena, não um mercado de procurement. Não tem comitê de auditoria para satisfazer. E o escopo ainda não está definido. Não tem como, porque a razão de ele estar terceirizando é justamente não saber, no nível de requisito, o que construir.
Por que founders recorrem ao RFP mesmo assim
Geralmente são três gatilhos. Nenhum deles é “o RFP é o melhor instrumento para esse trabalho.”
O primeiro é herança profissional. O founder passou dez anos em finanças, consultoria, ou cargo corporativo senior antes de fundar a empresa. Toda decisão de procurement da vida anterior usou um RFP. É a memória muscular do “estamos gastando dinheiro de verdade e precisamos ter cuidado.” Quando o orçamento é R$ 800 mil e o projeto vai durar mais que a próxima rodada, o RFP parece a versão adulta de “tomar três orçamentos.”
O segundo é medo de ser passado para trás. Dor #2 do ICP: todo freelancer queimou ele. Amigos levantaram pre-seed, pagaram R$ 1 milhão para uma agência, e receberam um app meio-funcionando. O founder recorre ao RFP porque o documento parece proteção: escopo claro, entregáveis claros, penalidades claras.
O terceiro é ótica para investidor. Um conselheiro ou advisor falou para “tomar três orçamentos.” Um CFO que nunca trabalhou com produto sugeriu formalizar o processo. O RFP é o artefato que prova que a due diligence aconteceu.
Os três gatilhos são legítimos. O erro é concluir que o RFP é a resposta para qualquer um deles. Cautela, proteção e due diligence no pre-seed se parecem com quase nada do que é procurement na empresa.
Três problemas do RFP para software custom em estágio inicial
Problema 1: o problema do escopo
O RFP pede que o comprador especifique o que quer construído. A Seção 3 é sempre “Escopo e Requisitos do Projeto.” Para software pacote, isso funciona: o comprador sabe que quer um CRM que faz X, Y e Z, e os vendors precificam contra essas features. Para software custom em estágio inicial, o founder ainda não sabe o que quer. Sabe a dor do cliente, sabe o resultado de negócio que precisa, e tem uma hipótese sobre a primeira fatia do sistema. O ponto inteiro de trabalhar com um parceiro é comprimir a distância entre hipótese e produto entregue.
Quando o RFP força o founder a escrever 40 requisitos que ele não validou, duas coisas ruins acontecem. Ele superespecifica, porque deixar campos em branco na seção de requisitos parece pouco profissional. E os vendors precificam contra o escopo superespecificado, não contra o problema real. Os 40 requisitos viram contrato, e qualquer desvio vira aditivo. O founder endureceu um chute em entregável antes de falar com um engenheiro.
As fábricas que enxergam isso (as boas) diriam para o founder jogar fora a seção de requisitos e começar a partir do problema do cliente. Não dirão isso dentro da proposta, porque o formato da proposta não tem lugar para “seu documento está no formato errado.”
Problema 2: o problema do bid
RFPs coletam propostas. Propostas são comparadas. O bid qualificado mais barato geralmente ganha, às vezes ajustado pelos pesos de avaliação que o comprador definiu antes.
Isso funciona para trabalho de commodity. Se você precisa de dez mil parafusos torneados na norma ISO, o bid qualificado mais barato é a resposta certa, porque o trabalho é genuinamente idêntico entre vendors. Software custom é o oposto. O trabalho não é idêntico. A fábrica que faz cinco perguntas afiadas sobre o problema e cobra um número mais alto está fazendo algo que a mais barata não está, mas nem o RFP nem o formato do bid capturam essa diferença.
Pior: o formato seleciona contra as fábricas com que você queria trabalhar. As boas ou nem se dão o trabalho de responder (preferem 30 minutos de conversa a três dias preenchendo formulário), ou aumentam escopo para se proteger do drift que vão sofrer, o que faz o bid parecer caro. As fábricas que respondem rápido com números baixos estão fazendo uma de três coisas: subestimando otimista para ganhar o deal, planejando aditivar até a margem aparecer, ou usando o build como treinamento de time junior. O mecanismo seleciona os parceiros errados.
Problema 3: o problema da relação
O RFP enquadra o engajamento como vendor e comprador. O vendor entrega; o comprador aceita ou rejeita. O contrato enumera penalidades por marcos perdidos. O trabalho é opaco entre checkpoints. O comprador tem visibilidade só nas portas que o documento definiu lá no início.
Software custom precisa do formato oposto: visibilidade semanal, iteração rápida, decisões compartilhadas sobre trade-offs que o founder não tinha como antecipar na semana zero. Uma fábrica que é parceira de verdade diz “a gente precisa repensar o marco três com base no que aprendemos no dois.” Um vendor sob contrato derivado de RFP diz “o marco três está em escopo; se você quer mudar, aqui está o aditivo.” A mesma fábrica faz uma ou outra coisa dependendo do contrato debaixo. O RFP quase sempre produz o segundo formato.
É por isso que source code escrow, cláusulas de lock-in, e provisões elaboradas de saída aparecem tanto em contrato de agência: são os mecanismos de proteção que uma relação de vendor exige. Quando a relação é uma parceria de verdade, a maioria deles é desnecessária.
O que mandar em vez disso: o brief de parceria em cinco parágrafos
Substitua o RFP por um documento de uma página. Cinco parágrafos curtos. Mande para duas ou três fábricas que você já tem em shortlist por referência, não cinco que achou no Google.
Parágrafo 1. O problema de negócio em linguagem direta. O que o seu cliente está pagando para você resolver? Duas ou três frases, sem jargão. “Corretores independentes de seguro em São Paulo gastam 6 horas por apólice reconciliando extratos de comissão de 14 seguradoras. Cobramos uma assinatura para fazer isso em 10 minutos.” Vale mais do que 40 requisitos. A fábrica aprende mais com esse parágrafo do que com a seção de requisitos inteira de qualquer template de RFP.
Parágrafo 2. A primeira coisa que você lançaria. Qual é a menor versão do sistema que faz um cliente pagante usar de verdade? Não o MVP de boca, a primeira versão que você teria orgulho de pôr na frente de um cliente pagante. Veja nosso artigo sobre como contratar um desenvolvedor para startup para o enquadramento. Um parágrafo, três ou quatro capacidades centrais. Se você ainda não consegue escrever esse parágrafo, o trabalho de discovery não está pronto.
Parágrafo 3. Sua faixa de orçamento. Um número real, não um piso ancorado para baixo. “Reservamos entre R$ 400 mil e R$ 600 mil para a primeira build.” Ou: “Temos R$ 300 mil e precisamos saber o que dá para entregar com isso.” Esconder o número não te traz melhor preço; te traz propostas calibradas no enquadramento errado. Se você não sabe a faixa certa, nosso artigo sobre contrato de preço fechado vs. tempo e materiais cobre as perguntas estruturais.
Parágrafo 4. Seu cronograma e o que está pressionando. “Precisamos da v1 em produção até 30 de agosto porque o piloto do nosso primeiro cliente enterprise começa em 1 de setembro.” A restrição é a informação real. Um cronograma tirado do ar (“queremos lançar no Q4”) não diz nada à fábrica sobre quais trade-offs você está disposto a aceitar.
Parágrafo 5. Três perguntas que você quer que a fábrica responda por escrito. Não “fale sobre sua empresa.” Coisas como: Vocês já construíram algo parecido para uma empresa em estágio similar? Quem especificamente estaria nesse projeto, por nome, e qual é o background dessa pessoa? Qual é a primeira coisa que vocês discordariam nesse brief? A terceira pergunta separa parceiros de vendors mais rápido que qualquer outro estímulo.
Uma fábrica que não consegue ou não quer responder esse documento em 48 horas não é fit. Uma fábrica que responde com três perguntas afiadas próprias é exatamente a fábrica que você quer continuar conversando.
Quando um RFP realmente é o instrumento certo
Três situações estreitas, na maior parte fora da compra de software custom em estágio inicial.
Comprando software de pacote. Você está escolhendo um CRM, um ERP, uma plataforma de dados de cliente, um HRIS. O escopo é definido pelo próprio produto. Os vendors são alvos reais de procurement com times de vendas que respondem RFP como prática padrão. O RFP funciona.
Indústrias reguladas com regras de procurement. Sistemas de saúde, instituições financeiras de certo porte, compradores próximos do governo. Seu time de contratos vai dizer que RFP é obrigatório e não tem argumento real contra. Use o instrumento que cabe na política. Só entenda que é a política dirigindo o documento, não a natureza do trabalho.
Trabalho genuinamente commodity com escopo fechado. Você já construiu a v1, o sistema está em produção, e precisa de um escopo conhecido de features adicionais que não exige discovery em formato de parceria. O RFP é razoável aqui porque o trabalho efetivamente virou commodity. A maioria dos founders não está nesse estado e não devia fingir que está.
Se você não está em um desses três casos, o brief de parceria é o documento certo.
O que perguntar na primeira conversa que nenhum RFP vai extrair
O brief em cinco parágrafos é o filtro. A primeira conversa de 30 minutos é onde a seleção de verdade acontece. Quatro perguntas que nenhum documento de procurement vai extrair:
1. “Me conta o último projeto que vocês recusaram.” Fábricas que nunca disseram não a um cliente estão dizendo sim para tudo. Esse é o pior sinal. As fábricas que valem a pena conseguem nomear o engajamento que recusaram e explicar por quê.
2. “Quem do seu time eu vou estar conversando na semana 4 do projeto?” Se a resposta é o fundador ou o vendedor, o time que você viu no pitch não é o time que está construindo. O nome de um engenheiro sênior específico é a resposta que você quer.
3. “O que vocês acham que está errado no meu brief?” Uma fábrica que diz “nada, está ótimo” está vendendo. Uma fábrica que aponta para o parágrafo 2 e diz “a primeira coisa que vocês lançariam não é o que vocês acham que é” está fazendo o trabalho dentro da conversa.
4. “Qual é o menor engajamento por onde a gente conseguiria começar?” Parceiros de verdade propõem um sprint de scoping ou discovery de duas a quatro semanas antes de cotar a build inteira. Fábricas que cotam R$ 900 mil na primeira ligação estão chutando.
Essas respostas não saem de um RFP escrito, por mais elaborada que seja a rubrica de avaliação.
FAQ
O que é um RFP em desenvolvimento de software? Um Request for Proposal é um documento formal de procurement que o comprador envia a vendors descrevendo o que quer construído, as restrições, e como as propostas serão avaliadas. O instrumento nasceu no procurement de TI corporativo e governo, onde seleção padronizada de vendor é obrigatória. Funciona bem para compra de software pacote e procurement regulado, e mal para software custom em estágio inicial onde o escopo ainda está emergindo. A entrada da Wikipedia sobre Request for proposal cobre a definição formal e a história.
Devo mandar um RFP para várias fábricas de software? Para uma build custom em pre-seed ou seed, não. Mande um brief de parceria de uma página para duas ou três fábricas que você já tem em shortlist por referência. O padrão RFP-para-cinco-fábricas seleciona fábricas que ganham por inflar bid, não por craft.
Qual é a diferença entre um RFP e um SOW em desenvolvimento de software? Um RFP é um documento de procurement usado antes da seleção do vendor: você manda para vários vendors, coleta propostas, e escolhe um. Um Statement of Work é um documento contratual assinado com o vendor que você escolheu: define escopo, entregáveis, cronograma e preço do engajamento real. Muitos founders confundem porque templates online misturam os dois. O RFP vem primeiro se você usar; o SOW sempre vem depois da seleção.
Posso usar um template de RFP que achei online? Pode. A maioria foi escrita para procurement de TI corporativo e vai superespecificar seu projeto em uma ordem de grandeza. Se você decidir que o RFP ainda é o instrumento certo para sua situação, esvazie a seção de requisitos e troque por um statement do problema e um parágrafo da-primeira-coisa-a-lançar. Melhor ainda: pule o template e mande o brief em cinco parágrafos.
E se uma fábrica pedir que eu mande um RFP? Algumas fábricas preferem o processo estruturado de resposta porque deixa rotear a proposta pelo pipeline interno delas. É uma preferência justa. Mande o brief de parceria primeiro e deixe que elas traduzam para qualquer artefato interno que precisem. Se elas insistirem que o brief precisa estar em formato RFP antes do engajamento, isso é um pequeno sinal de como a relação vai funcionar. Pesado de processo, com cara de vendor, lento para iterar. Leia de acordo.
Quão longo deve ser um RFP para desenvolvimento de software? Se você decidir mandar, duas páginas. O brief de cinco parágrafos no formato acima, mais meia página de critério de avaliação. Qualquer coisa mais longa veio do template e não está fazendo trabalho útil. RFPs de grau procurement passam de 20 a 40 páginas porque precisam passar por política e revisão jurídica. Nada disso se aplica à sua build.
O instrumento importa porque ele dá o formato da conversa. O RFP para desenvolvimento de software foi construído para um tipo específico de compra; quase nada nele cabe na compra que um fundador não-técnico está fazendo no pre-seed. Mande o documento que se ajusta ao trabalho, não o que parece mais profissional de fora.