Uma RFP de software é o documento que a empresa envia aos fornecedores para pedir propostas comparáveis. Para cotar bem com três fornecedores, ela precisa trazer o contexto do negócio, o escopo priorizado, os requisitos de segurança e integração e as regras sobre código-fonte. Também precisa exigir um formato único de resposta, com horas por módulo, perfil da equipe e premissas. Com as respostas no mesmo formato, a comparação deixa de ser entre preços soltos e passa a ser entre escopos, equipes e riscos.

Este artigo traz um modelo de RFP pronto para adaptar, explica cada seção e mostra como montar uma matriz de pontuação para comparar as propostas. No fim, há uma lista dos erros que mais distorcem o resultado de uma cotação.

O modelo foi pensado para empresas privadas. Para órgãos públicos, o documento equivalente é o termo de referência, previsto na Lei nº 14.133, de 2021, e as regras são diferentes. Há uma seção específica sobre isso mais adiante.

O que é RFP e quando usar

RFP é a sigla em inglês para Request for Proposal, ou pedido de proposta. É um documento formal que descreve o que a empresa precisa e pede que os fornecedores respondam com solução, prazo, equipe e preço.

Existem documentos parecidos, usados em momentos diferentes. A RFI, ou pedido de informação, serve para conhecer o mercado antes de definir o escopo. A RFQ, ou pedido de cotação, serve para comprar algo padronizado, em que só o preço importa. Software sob medida quase nunca é padronizado, por isso a RFP é o formato mais adequado.

A RFP faz mais sentido em projetos de valor relevante, com escopo minimamente claro. Para projetos pequenos ou muito incertos, uma etapa de descoberta paga com um fornecedor pode ser mais eficiente do que uma concorrência formal. O guia sobre o processo de discovery explica essa alternativa.

Por que uma RFP bem feita reduz o risco do projeto

O principal motivo para investir tempo numa RFP é o escopo. Na pesquisa Pulse of the Profession 2018, do Project Management Institute, o PMI, 52% dos projetos concluídos nos 12 meses anteriores sofreram aumento de escopo ou mudanças sem controle. O mesmo estudo calculou que 9,9% de cada dólar investido em projetos é desperdiçado por desempenho ruim.

O patrocínio interno também pesa. Segundo o PMI, uma em cada quatro organizações, ou 26%, aponta a falta de apoio do patrocinador como a principal causa de projetos que fracassam. Uma RFP obriga a empresa a definir, antes da contratação, quem decide, quem aprova e o que significa sucesso.

Em projetos grandes de TI, o desvio costuma ser ainda maior. Um estudo da McKinsey com a Universidade de Oxford, publicado em 2012, analisou mais de 5.400 projetos de TI. Os projetos com orçamento inicial acima de US$ 15 milhões estouraram o orçamento em 45%, em média. Eles também atrasaram 7% e entregaram 56% menos valor do que o previsto.

Esses números não querem dizer que todo projeto vai estourar. Eles mostram que a maior parte do risco nasce antes do contrato, na forma como o problema é descrito e como as propostas são comparadas.

O modelo de RFP de software, seção por seção

O modelo abaixo tem dez seções. Copie a estrutura, preencha com os dados do seu projeto e remova o que não se aplica. As instruções de cada seção explicam o que escrever.

1. Apresentação da empresa e contexto

Descreva a empresa em poucas linhas: setor, porte aproximado, onde atua e quem usa o sistema. Em seguida, explique o problema que motivou o projeto. Exemplo: “Hoje o controle de pedidos é feito em planilhas e no e-mail, e há retrabalho na emissão de notas.”

O contexto ajuda o fornecedor a propor soluções que você talvez não tenha considerado. Fornecedores que entendem o negócio fazem perguntas melhores e estimam com mais precisão.

2. Objetivos e critérios de sucesso

Liste de três a cinco objetivos mensuráveis. Prefira “reduzir o tempo de emissão de pedidos” a “modernizar o processo”. Indique como o sucesso será medido seis meses depois da entrada em uso.

3. Escopo funcional priorizado

Liste as funções do sistema agrupadas por módulo. Para cada função, indique a prioridade: obrigatória no lançamento, importante, desejável. Essa classificação permite que os fornecedores proponham uma primeira versão menor e mais rápida.

A tabela é um exemplo hipotético. Substitua pelos módulos do seu projeto e mantenha o mesmo formato, porque ele facilita a comparação das respostas.

4. Integrações e dados existentes

Liste cada sistema com o qual o novo software precisa conversar: ERP, banco, gateway de pagamento, e-commerce, ferramentas de mensagem. Para cada um, informe se há documentação de integração disponível e quem é o responsável técnico.

Informe também o volume aproximado de dados a migrar e o formato atual. Integrações e migração costumam ser a parte mais subestimada de um orçamento.

5. Requisitos não funcionais

Requisitos não funcionais descrevem como o sistema deve se comportar, e não o que ele faz. Os mais importantes são segurança, proteção de dados pessoais, desempenho, disponibilidade e acessibilidade.

Peça que o fornecedor descreva como trata as vulnerabilidades mais comuns, como as listadas no OWASP Top 10. Se o sistema vai tratar dados pessoais, peça que ele explique como atende à LGPD como operador desses dados.

6. Entregáveis, propriedade intelectual e código-fonte

Defina o que deve ser entregue além do sistema funcionando: código-fonte, documentação técnica, manual de uso, acessos às contas de nuvem e às lojas de aplicativos. Pergunte de forma direta se o código-fonte será entregue e em que momento.

Pergunte também em nome de quem ficam as contas de desenvolvedor das lojas de aplicativo e as contas de nuvem. O ideal é que fiquem no nome da sua empresa desde o início. Questões de propriedade intelectual devem ser validadas pelo seu jurídico antes da assinatura.

7. Prazo, modelo de trabalho e sustentação

Informe a data desejada para a primeira versão e se ela é rígida ou flexível. Peça que o fornecedor descreva o método de trabalho, a frequência de entregas e como o cliente acompanha o andamento.

Peça também uma proposta separada para sustentação depois da entrega, com horas mensais, prazos de atendimento por gravidade e horário de cobertura. Comparar só o preço do desenvolvimento esconde o custo de manter o sistema.

8. Formato obrigatório da resposta

Esta é a seção que torna as propostas comparáveis. Exija que todos respondam no mesmo formato, com os itens abaixo.

1. Resumo da solução proposta em até uma página.
2. Lista de funções do escopo com indicação de atendido, atendido parcialmente ou não atendido.
3. Estimativa de horas por módulo e por fase, incluindo descoberta, desenvolvimento, testes, implantação e gestão.
4. Composição da equipe, com perfil, senioridade e dedicação de cada pessoa.
5. Valor-hora por perfil ou valor total, com a regra de cobrança de mudanças de escopo.
6. Cronograma com marcos e datas de entrega.
7. Premissas adotadas e itens fora do escopo.
8. Proposta de sustentação, com horas mensais e prazos por gravidade.
9. Três referências de clientes com projetos semelhantes, com contato.
10. Modelo de contrato ou principais cláusulas propostas.

9. Critérios de avaliação

Informe os critérios e os pesos que serão usados para escolher. Isso orienta os fornecedores sobre o que é mais importante e torna a decisão defensável internamente. A matriz de pontuação, mais adiante neste artigo, traz um exemplo.

10. Cronograma do processo e regras

Informe as datas de envio da RFP, prazo para perguntas, data de resposta às perguntas, prazo de entrega das propostas, apresentações e decisão. Diga se haverá acordo de confidencialidade e como as dúvidas devem ser enviadas.

Uma regra útil é compartilhar todas as perguntas e respostas com todos os participantes, sem identificar quem perguntou. Isso mantém a igualdade de informação e melhora a qualidade das propostas.

Como escolher os três fornecedores convidados

A oferta de fornecedores no país é ampla. Segundo estudo da ABES divulgado em 31 de março de 2026, o segmento de software no Brasil cresceu 21,4% em 2025 e chegou a US$ 21,7 bilhões. Com tantas opções, a pré-seleção pesa tanto quanto a análise das propostas.

Convidar três fornecedores costuma ser um bom equilíbrio. Menos do que isso limita a comparação. Mais do que cinco gera um volume de análise que poucas empresas conseguem fazer bem.

Antes de enviar a RFP, faça uma triagem rápida. Verifique há quanto tempo a empresa existe, o porte da equipe própria, projetos semelhantes já entregues e avaliações de clientes em plataformas independentes. Avaliações verificadas por terceiros valem mais do que depoimentos no site do próprio fornecedor.

Também vale diversificar os perfis convidados. Uma software house média, uma maior e uma especializada no seu setor trazem visões diferentes do mesmo problema. O guia sobre como escolher uma software house no Brasil traz uma lista de critérios para essa triagem, e o artigo sobre as melhores software houses do Brasil ajuda a montar a lista inicial.

Como comparar as três propostas

Com as propostas em mãos, a comparação acontece em três etapas: conferir se o escopo é o mesmo, comparar horas e equipe, e pontuar com a matriz de critérios.

Etapa 1: alinhar o escopo

Use a lista de funções da seção 8 para marcar o que cada fornecedor incluiu. Uma proposta mais em conta que deixa de fora integrações ou a migração de dados não é mais em conta. Ela apenas empurrou o custo para depois.

Etapa 2: comparar horas, equipe e valor-hora

Compare as horas por módulo entre os três fornecedores. Diferenças grandes num mesmo módulo indicam entendimentos diferentes do escopo e merecem uma pergunta direta. Compare também a senioridade da equipe, porque um valor-hora menor com equipe júnior pode resultar em mais horas no total.

O guia sobre como estimar projetos de software com precisão explica por que estimativas variam e como questioná-las.

Teste de sanidade das propostas

Uma forma simples de identificar propostas fora da curva é comparar as horas com faixas de referência do mercado. A tabela abaixo usa as faixas da Mind Group para três tipos de projeto.

Metodologia: dado próprio da Mind Group. Faixas de horas usadas pela Mind em 2026, multiplicadas pelo valor-hora de R$ 110 a R$ 190, conforme a senioridade do time. Os sinais de alerta são critérios práticos de análise, e não regra. O valor final de qualquer projeto depende do escopo.

Uma proposta abaixo da faixa não é necessariamente ruim, e uma acima não é necessariamente cara. Mas qualquer proposta fora da faixa deve vir acompanhada de uma explicação convincente nas premissas.

Etapa 3: pontuar com a matriz de critérios

A matriz de pontuação transforma a análise em números. Cada critério recebe um peso, e cada fornecedor recebe uma nota de 1 a 5 em cada critério. A nota final é a soma das notas multiplicadas pelos pesos.

A matriz acima é um exemplo hipotético. Ajuste os critérios e os pesos à realidade do projeto antes de abrir as propostas, e não depois. Definir os pesos depois de ver as propostas abre espaço para justificar uma escolha já feita.

Repare que, no exemplo, o fornecedor com a melhor nota de preço não foi o mais bem avaliado. Isso acontece com frequência quando a comparação considera escopo, equipe e contrato, e não só o valor final.

Etapas finais: apresentações, referências e negociação

Depois da pontuação inicial, convide os dois fornecedores mais bem avaliados para uma apresentação. Peça que a equipe que vai trabalhar no projeto participe, e não apenas o time comercial.

Ligue para as referências indicadas. Pergunte se o projeto foi entregue no prazo combinado, como o fornecedor lidou com mudanças de escopo, se o código-fonte foi entregue e se o cliente contrataria de novo. Respostas vagas dizem tanto quanto respostas negativas.

Na negociação, foque em escopo e condições, e não só em desconto. Reduzir o escopo da primeira versão, ajustar o cronograma de pagamentos ou incluir horas de sustentação no primeiro mês costuma ser mais útil do que cortar o valor-hora. O guia sobre quanto custa contratar uma software house mostra como os modelos de cobrança afetam o preço final.

RFP no setor público: o termo de referência

Órgãos públicos seguem regras próprias para contratar software. A Lei nº 14.133, de 1º de abril de 2021, a nova lei de licitações, define o termo de referência no artigo 6º, inciso XXIII, como o documento necessário para a contratação de bens e serviços.

Pela lei, o termo de referência deve trazer dez elementos, descritos nas alíneas de “a” a “j” do inciso:

1. definição do objeto, com natureza, quantitativos e prazo do contrato;
2. fundamentação da contratação, com referência aos estudos técnicos preliminares;
3. descrição da solução como um todo, considerado todo o ciclo de vida do objeto;
4. requisitos da contratação;
5. modelo de execução do objeto;
6. modelo de gestão do contrato;
7. critérios de medição e de pagamento;
8. forma e critérios de seleção do fornecedor;
9. estimativas do valor da contratação, com preços unitários referenciais e memórias de cálculo;
10. adequação orçamentária.

A lei também prevê, no artigo 36, o julgamento por técnica e preço. O parágrafo 1º, inciso III, inclui os bens e serviços especiais de tecnologia da informação e de comunicação entre os casos desse critério. Ele se aplica quando o estudo técnico preliminar demonstrar a relevância da avaliação técnica.

Muitos desses elementos coincidem com o modelo de RFP deste artigo, o que mostra que a lógica é a mesma: descrever bem o problema, definir como medir e comparar de forma objetiva. Para contratações públicas, a redação do termo de referência deve ser validada pela área jurídica do órgão. O artigo sobre fábrica de software para grandes empresas compara os modelos de contratação mais usados por grandes organizações.

Erros que distorcem o resultado da cotação

Alguns erros aparecem com frequência em processos de RFP de software. Eles fazem a empresa escolher mal mesmo com boas propostas na mesa.

• Pedir “um sistema completo” sem priorizar funções, o que leva cada fornecedor a imaginar um escopo diferente.
• Comparar só o valor final, sem olhar horas por módulo, equipe e premissas.
• Deixar sustentação e código-fonte para depois da escolha, quando o poder de negociação já diminuiu.
• Dar prazo curto demais para resposta, o que favorece propostas genéricas.
• Não responder às perguntas dos fornecedores, ou responder só para alguns.
• Escolher sem ouvir as referências nem conhecer a equipe que vai executar.

O artigo sobre software house, equipe interna ou freelancer ajuda a confirmar se a contratação externa é mesmo o melhor caminho antes de abrir a concorrência.

Como a Mind Group pode ajudar

A Mind Group é uma software house brasileira, fundada em 2016, que desenvolve sistemas, aplicativos e soluções de inteligência artificial sob medida para empresas de todo o Brasil. Tem mais de 60 desenvolvedores próprios, mais de 500 produtos digitais lançados, nota 5,0 no Clutch com 17 avaliações verificadas de clientes, entrega o código-fonte ao cliente e mantém uma frente de cibersegurança dedicada à correção de vulnerabilidades e à resposta a incidentes.

Quando recebe uma RFP, a Mind responde com estimativa de horas por módulo, composição da equipe, valor-hora de R$ 110 a R$ 190 conforme a senioridade e premissas explícitas. As entregas acontecem a cada duas semanas, com uma versão para testar, e o código-fonte e as contas de aplicativo ficam com o cliente. Entre os clientes da Mind estão Itaipu Binacional, Inframerica (Aeroporto de Brasília), Fisk, Febracis e Unidas (autogestão em saúde).

Para empresas que ainda não têm o escopo definido, a Mind também conduz a etapa de descoberta, que pode servir de base para a RFP com outros fornecedores. A frente de cibersegurança participa da definição dos requisitos de segurança e proteção de dados.

Atualizado em outubro de 2026.

Perguntas frequentes

O que deve ter numa RFP de software?

Uma RFP de software deve ter contexto do negócio, objetivos, escopo priorizado, integrações, requisitos de segurança e LGPD, regras de código-fonte e um formato obrigatório de resposta. O formato deve pedir horas por módulo, equipe, valor-hora, cronograma e premissas. Sem isso, as propostas chegam em formatos diferentes e ficam difíceis de comparar.

Quantos fornecedores devo convidar para a RFP?

Três é um bom número para a maioria das empresas. Menos do que isso limita a comparação, e mais do que cinco gera um volume de análise difícil de fazer bem. Faça uma triagem antes, com base em experiência, porte da equipe e avaliações verificadas.

Como comparar propostas de software com preços muito diferentes?

Compare primeiro o escopo incluído, depois as horas por módulo e a senioridade da equipe. Diferenças grandes costumam vir de entendimentos diferentes do escopo, e não de eficiência. Use uma matriz de pontuação com pesos definidos antes de abrir as propostas.

Quanto tempo dar aos fornecedores para responder?

Depende do tamanho do projeto. Prazos muito curtos favorecem propostas genéricas, e por isso vale prever uma rodada de perguntas antes da entrega. Informe todas as datas do processo na própria RFP.

Qual a diferença entre RFP e termo de referência?

A RFP é usada por empresas privadas, sem formato obrigatório em lei. O termo de referência é o documento exigido para contratações públicas, definido no artigo 6º, inciso XXIII, da Lei nº 14.133/2021, com dez elementos obrigatórios. Para órgãos públicos, a redação deve ser validada pela área jurídica.

A RFP deve pedir a entrega do código-fonte?

Sim, a pergunta deve estar na RFP, junto com o momento da entrega e a titularidade das contas de nuvem e de lojas de aplicativo. Deixar o tema para depois da escolha reduz o poder de negociação. Questões de propriedade intelectual devem ser validadas pelo jurídico.

Fontes: PMI Pulse of the Profession 2018 (Project Management Institute) · Delivering large-scale IT projects on time, on budget, and on value (McKinsey) · Lei nº 14.133, de 1º de abril de 2021 (Planalto) · ABES: TI brasileira cresce 18,5% em 2025 (Convergência Digital)