# Como comparar propostas de software: checklist além do preço

> Como comparar propostas de desenvolvimento de software: escopo, premissas, equipe, garantia, sustentação e código. Use o checklist e veja o que você compra.

Fonte: https://pervian.tech/blog/como-comparar-propostas-de-software · Pervian Tech · publicado em 2026-10-01

Você pediu orçamento para três fornecedores e recebeu três documentos que não conversam entre si. Um tem duas páginas e um número no final. Outro tem trinta páginas, com cronograma, diagrama de arquitetura e uma lista de exclusões em letra pequena. O terceiro fala em "horas estimadas" e "sprints". Na reunião de diretoria, a primeira pergunta costuma ser: qual é a mais barata? E é justamente a pergunta errada.

Propostas de software parecem diferentes no preço porque, na maioria das vezes, estão vendendo coisas diferentes. Uma inclui integração com o ERP e a outra assume que você mesmo vai exportar planilhas. Uma prevê três meses de garantia e a outra cobra cada correção depois da entrega. Uma deixa o código no seu nome e a outra licencia o uso. Comparar só o total é comparar um carro completo com um chassi.

Este texto mostra como colocar propostas diferentes na mesma base, item por item, para que a decisão seja sobre o que está sendo comprado, e não sobre qual documento parece mais bonito.

## Resposta curta: como comparar propostas de desenvolvimento de software

Para comparar propostas de forma justa, monte uma tabela única e preencha, para cada fornecedor, os mesmos pontos:

1. **Escopo:** quais funcionalidades, integrações e perfis de usuário estão incluídos, e quais estão explicitamente fora.
2. **Premissas:** o que o fornecedor está assumindo sobre você (dados prontos, acesso a sistemas, disponibilidade de pessoas).
3. **Equipe:** quem trabalha no projeto, com qual dedicação e quem decide tecnicamente.
4. **Prazo e marcos:** quando você vê software funcionando, e não só quando o projeto "termina".
5. **Garantia e sustentação:** o que acontece depois da entrega, por quanto tempo e em que condições.
6. **Propriedade:** de quem é o código, o repositório, a nuvem e os dados.
7. **Riscos:** o que acontece quando algo muda, atrasa ou sai diferente do previsto.

Onde uma proposta silencia sobre um desses pontos, anote "não informado". Esse buraco é, quase sempre, um custo que vai aparecer depois.

## Por que propostas parecem incomparáveis

Cada fornecedor responde ao seu pedido com a própria interpretação dele. Se o pedido foi "um sistema para controlar pedidos e estoque", cada um imaginou um sistema diferente. Um pensou em cadastro, pedido e baixa de estoque. Outro incluiu emissão de nota, integração com transportadora e aplicativo para o vendedor externo. Os dois estão certos dentro do que imaginaram.

Há também modelos comerciais diferentes:

- **Escopo fechado:** o fornecedor se compromete com uma lista de entregas por um valor e prazo definidos. Parece mais seguro, mas costuma vir com muitas exclusões e uma margem para cobrir o risco que ele assumiu.
- **Tempo e material:** você paga pela capacidade da equipe ao longo do tempo. É mais flexível, mas exige acompanhamento próximo e uma boa forma de priorizar.
- **Híbrido:** uma fase inicial de entendimento com escopo fechado, seguida de ciclos de desenvolvimento com prioridade revista a cada etapa.

Nenhum modelo é melhor em absoluto. O problema é comparar um [escopo fechado enxuto com um contrato por capacidade](https://pervian.tech/blog/escopo-fechado-ou-contrato-agil) como se fossem a mesma coisa. Se uma proposta vem de fora, veja [software house no Brasil ou no exterior](https://pervian.tech/blog/software-house-no-brasil-ou-no-exterior).

A forma mais eficaz de reduzir essa diferença é antes de pedir proposta: escrever o problema, os processos envolvidos e as integrações necessárias, mesmo que em poucas páginas. Quando o problema ainda está nebuloso, faz sentido contratar uma etapa de [discovery de software](https://pervian.tech/blog/discovery-de-software) antes de pedir o desenvolvimento completo, para que todos os fornecedores orcem a partir do mesmo entendimento.

## Escopo e premissas: o que está e não está incluso

O escopo é onde mora a maior parte da diferença entre propostas. Leia cada uma procurando três coisas.

### O que está descrito como entrega

Uma proposta séria descreve funcionalidades em termos que você consegue verificar. "Módulo de vendas" não diz nada. "Cadastro de pedido com tabela de preço por cliente, aprovação de desconto acima de um limite pelo gerente e envio do pedido aprovado ao ERP" diz. Se não dá para saber, ao final, se a entrega foi cumprida, o escopo está vago demais.

Confira também os itens que costumam ficar implícitos:

- **Perfis de acesso:** quantos tipos de usuário, com quais permissões.
- **Relatórios:** quais, com quais filtros e se exportam para planilha.
- **Integrações:** com quais sistemas, em que direção e com que frequência.
- **Migração de dados:** quem traz os dados do sistema antigo e quem limpa os registros duplicados.
- **Plataformas:** navegador, celular, tablet, funcionamento sem internet.
- **Acessibilidade:** qual padrão a entrega segue e como será verificado, com base num [checklist de acessibilidade](https://pervian.tech/blog/acessibilidade-em-sistemas-web).

### O que está explicitamente excluído

Leia a lista de exclusões com mais atenção do que a de inclusões. É ali que aparecem frases como "integrações com sistemas de terceiros serão orçadas à parte" ou "a carga inicial de dados é de responsabilidade do cliente". Uma proposta que parece mais enxuta pode ter simplesmente empurrado metade do trabalho para fora.

### As premissas que recaem sobre você

Toda proposta assume coisas sobre a sua empresa. Exemplos comuns:

- o fornecedor do ERP vai liberar acesso à API em tempo hábil;
- haverá uma pessoa da sua equipe disponível para validar entregas toda semana;
- os dados do sistema atual estão consistentes;
- as regras de negócio não vão mudar durante o projeto.

Se uma premissa falhar, quem paga? Uma proposta madura diz isso de forma clara. Uma proposta frágil deixa para discutir quando o problema acontecer, e nesse momento você já está no meio do projeto, sem poder de negociação.

## Equipe, prazo e marcos de entrega

Duas propostas com o mesmo escopo podem resultar em projetos muito diferentes dependendo de quem vai trabalhar neles.

Pergunte:

- **Quem são as pessoas?** Nomes e papéis de quem vai desenhar e escrever o sistema, não só do comercial.
- **Qual a dedicação?** Exclusiva, parcial ou compartilhada com outros clientes.
- **Quem toma as decisões técnicas?** Existe alguém responsável pela arquitetura, ou cada desenvolvedor decide por conta própria?
- **Como são feitos a revisão de código e os testes?** Se a resposta for genérica, peça um exemplo concreto.

Sobre prazo, desconfie de uma data única de entrega no fim. O que importa é **quando você vê software funcionando pela primeira vez** e com que frequência isso se repete. Um projeto com entregas parciais a cada duas ou três semanas permite corrigir rumo cedo. Um projeto que só mostra o resultado ao final concentra todo o risco num único dia.

Os prazos variam muito conforme o escopo, as integrações e a disponibilidade da sua equipe para validar. Por isso, compare a **estrutura de marcos** e não apenas a data final: o que será entregue em cada marco, como você valida e o que acontece se a validação reprovar.

Para aprofundar como avaliar o fornecedor em si, e não só o documento, o texto sobre [como escolher uma software house](https://pervian.tech/blog/como-escolher-uma-software-house) traz critérios práticos.

## Garantia, suporte e sustentação

Software não termina no lançamento. Depois dele vêm correções, ajustes de uso, atualização de bibliotecas, mudanças de regra fiscal e pedidos novos da operação. As propostas tratam esse período de formas muito diferentes, e aqui está uma das maiores fontes de custo escondido.

Separe três conceitos que muitas vezes aparecem misturados:

| Conceito | O que cobre | Pergunta para o fornecedor |
|---|---|---|
| **Garantia** | Correção de defeitos no que foi entregue, sem custo adicional | Por quanto tempo? O que conta como defeito e o que conta como mudança? |
| **Suporte** | Atendimento a dúvidas e incidentes em produção | Qual o canal, o horário e o tempo de resposta por gravidade? |
| **Sustentação** | Evolução contínua, atualizações, monitoramento e melhorias | Existe um modelo definido? Como é dimensionado e reajustado? |

Uma proposta que não fala de sustentação não está mais barata. Ela só deixou essa conversa para depois do lançamento, quando você já depende do sistema e trocar de fornecedor fica difícil. O ideal é que o modelo de pós-entrega esteja combinado antes de assinar. O post sobre [SLA de suporte e sustentação de software](https://pervian.tech/blog/sla-de-suporte-e-sustentacao-de-software) detalha o que pedir em cada nível.

## Propriedade do código e dos dados

Este é o ponto que menos aparece nas propostas e o que mais pesa quando a relação com o fornecedor acaba. Verifique:

- **Código-fonte:** o contrato prevê cessão dos direitos patrimoniais à sua empresa, ou apenas uma licença de uso? Sem cláusula clara, a titularidade pode virar discussão justamente quando você mais precisar do código.
- **Repositório:** o código fica num repositório em nome da sua empresa desde o primeiro dia, ou só é entregue no final?
- **Infraestrutura:** a conta de nuvem, os domínios e os certificados ficam no seu nome?
- **Dados:** os dados do sistema são seus, em formato que você consegue exportar, e o fornecedor trata dados pessoais de acordo com a LGPD?
- **Componentes de terceiros:** a proposta usa alguma plataforma ou módulo próprio do fornecedor que você não poderá levar se trocar de parceiro?

Duas propostas com o mesmo escopo podem ter valores muito diferentes porque uma está vendendo o sistema e a outra está alugando. Ambos os modelos podem fazer sentido, mas precisam ser comparados como o que são. O texto sobre [propriedade do código-fonte no contrato](https://pervian.tech/blog/propriedade-do-codigo-fonte-no-contrato) explica as cláusulas que protegem a empresa. Na dúvida sobre a redação, valide com o seu jurídico.

## Riscos que cada proposta transfere a você

Toda proposta distribui riscos entre as partes. A pergunta útil é: **se algo der errado, quem absorve?**

Alguns riscos para mapear em cada proposta:

- **Mudança de escopo:** existe um processo para pedir mudanças, estimar o impacto e aprovar antes de executar? Ou cada mudança vira uma negociação?
- **Atraso causado por terceiros:** se o fornecedor do ERP demorar a liberar a integração, o prazo é revisto? Há custo adicional?
- **Rotatividade da equipe:** se o desenvolvedor principal sair, como o conhecimento é preservado? Existe [documentação mínima](https://pervian.tech/blog/documentacao-de-software-minima) prevista?
- **Desempenho:** a proposta define volumes esperados (usuários simultâneos, pedidos por dia) e se compromete com o sistema funcionando nesses volumes?
- **Saída:** se a relação terminar, o que você recebe e em quanto tempo? Código, documentação, acessos, dados?
- **Dependência tecnológica:** a tecnologia escolhida é comum no mercado, ou só aquele fornecedor sabe mantê-la?

Uma proposta de escopo fechado muito barata costuma transferir quase todos esses riscos para você em forma de exclusões e aditivos. Uma proposta mais detalhada pode parecer cara justamente porque assumiu parte deles. Coloque isso na conta antes de decidir.

## Checklist prático para comparar propostas

Monte uma planilha com uma coluna por fornecedor e uma linha para cada item abaixo. Marque "sim", "não" ou "não informado".

**Escopo e premissas**

- As funcionalidades estão descritas de forma verificável?
- Existe lista explícita do que está fora?
- Integrações estão nomeadas, com direção e frequência?
- A migração de dados está incluída e com responsável definido?
- As premissas sobre a sua empresa estão escritas?

**Equipe e entregas**

- Sei quem vai trabalhar no projeto e com qual dedicação?
- Há um responsável técnico pela arquitetura?
- Vejo software funcionando em ciclos curtos?
- Os critérios de aceite de cada marco estão definidos?
- [Testes automatizados](https://pervian.tech/blog/testes-automatizados-para-gestores) e revisão de código fazem parte do processo?

**Pós-entrega**

- O período e o alcance da garantia estão claros?
- Existe modelo de suporte com tempo de resposta por gravidade?
- A sustentação está proposta, e não apenas mencionada?

**Propriedade e saída**

- O contrato prevê cessão do código-fonte?
- Repositório, nuvem e domínios ficam no nome da empresa?
- Os dados são exportáveis em formato aberto?
- Há entregáveis de transição em caso de encerramento?

**Riscos**

- Há processo formal para mudanças de escopo?
- A proposta diz o que acontece quando uma premissa falha?
- A tecnologia escolhida tem mercado para manutenção futura?

Só depois de preencher a tabela vale olhar para o investimento. Muitas vezes a proposta mais barata é a que tem mais linhas em "não informado".

## Perguntas para fazer antes de decidir

Uma reunião com cada finalista, com as mesmas perguntas, ajuda a desempatar e revela como o fornecedor pensa:

- "Quais partes deste escopo você considera mais arriscadas, e por quê?"
- "O que você sugeriria deixar para uma segunda fase?"
- "Me mostre um exemplo de como vocês registram e aprovam uma mudança de escopo."
- "Se eu quiser trocar de fornecedor daqui a um tempo, o que recebo e como é a transição?"
- "Quem da equipe técnica vai participar das reuniões comigo?"
- "Como vocês tratam dados pessoais durante o desenvolvimento e nos ambientes de teste?"

Preste atenção à qualidade das respostas mais do que ao conteúdo. Um fornecedor que aponta riscos, questiona requisitos e sugere cortes está tratando o projeto como algo que precisa funcionar. Um que concorda com tudo está tratando como uma venda.

## Perguntas frequentes

### Qual a diferença entre escopo fechado e tempo e material em projetos de software?

No escopo fechado, o fornecedor se compromete com uma lista de entregas por valor e prazo definidos, geralmente com exclusões e margem para cobrir o risco. Em tempo e material, a empresa paga pela capacidade da equipe ao longo do tempo, com mais flexibilidade e mais acompanhamento. Nenhum dos dois modelos é melhor em absoluto.

### Vale a pena escolher a proposta de software mais barata?

Só depois de comparar o que cada proposta inclui. A proposta de software mais barata costuma ter mais exclusões, mais premissas que recaem sobre o cliente e pouca ou nenhuma sustentação prevista. Com os itens lado a lado, a diferença de valor muitas vezes reflete escopo menor ou riscos transferidos ao cliente, e não eficiência.

### Por que propostas de software para o mesmo projeto são tão diferentes?

Porque cada fornecedor interpreta o pedido de um jeito e orça um sistema diferente. Integrações, migração de dados, garantia, sustentação e propriedade do código explicam a maior parte da distância entre propostas de software. Um documento de requisitos claro, enviado igual a todos os fornecedores, reduz essa diferença antes mesmo de as propostas chegarem.

### Preciso de um discovery antes de pedir propostas de software?

Depende de quanto o problema está claro. Se processos, integrações e regras já estão descritos, dá para pedir propostas de software diretamente. Se o problema ainda está nebuloso, uma etapa de discovery antes do desenvolvimento faz todos os fornecedores orçarem a partir do mesmo entendimento e reduz as surpresas durante o projeto.

## Como a Pervian Tech trabalha propostas

Na Pervian Tech, não enviamos proposta antes de entender o problema. Começamos por um diagnóstico inicial gratuito com quem vai de fato desenhar o sistema: mapeamos os processos, as integrações e as restrições, e só então escrevemos a proposta. Nela, o escopo é descrito em entregas verificáveis, as exclusões e premissas ficam explícitas, os marcos têm critérios de aceite e o modelo de garantia, suporte e sustentação já vem definido. O repositório e a infraestrutura ficam no nome do cliente desde o início.

Quando o problema ainda não está claro o suficiente para orçar com segurança, recomendamos uma etapa de entendimento antes do desenvolvimento. Esse trabalho faz parte da nossa atuação em [arquitetura de software](https://pervian.tech/servicos/arquitetura-de-software), e outros textos sobre o tema estão em [contratação de software](https://pervian.tech/blog/categoria/contratacao).

Cada projeto é sob medida, e o investimento é definido sob consulta. Se você tem propostas na mesa e quer uma segunda opinião técnica sobre o que cada uma está realmente oferecendo, [fale com a gente](https://pervian.tech/#contato).