Como avaliar e comparar 3 propostas de software sob medida

Três propostas na mesa. R$ 18 mil. R$ 32 mil. R$ 56 mil.

Mesmo escopo — sistema interno de gestão de pedidos, 8 telas, integração com o ERP que você já tem. Pelo menos é o que parece.

Seu sócio quer a de R$ 18 mil. “É só um sistema.” O responsável de TI quer a de R$ 56 mil. “É a mais séria.” Você está no meio, achando que a de R$ 32 mil parece razoável — mas sem saber se “parece OK” é OK real ou OK que vai virar enrosco em 6 meses.

Você precisa decidir. E não tem critério pra isso.

Comparar 3 propostas de software sob medida não é planilha de preço — é planilha de 9 dimensões ponderadas. Preço é só 1 das 9. A grande diferença de valor entre propostas quase sempre rastreia diferença de escopo, garantia, código entregue ou experiência do executor. Com 60 a 90 minutos de análise estruturada, você decide sem depender de intuição de sócio ou de média de preço. Quem decide por preço médio sem mapear essas 9 dimensões tende a pagar duas vezes: uma na contratação, outra refazendo em 8 a 12 meses.

Esse post é pra quem já recebeu as 3 propostas. Você passou pela etapa de pedir orçamento — agora está na decisão. Vou mostrar como comparar com critério, identificar bandeiras de alerta e saber quando a mais cara vale e quando a mais barata é a certa.

Por que “preço médio” é a decisão mais cara

A tentação do preço médio é enorme. R$ 18 mil parece arriscado demais. R$ 56 mil parece overhead demais. R$ 32 mil parece safe — o meio.

O problema: em software sob medida, o preço do meio frequentemente é o pior valor.

Isso acontece por uma razão simples: cada proposta está precificando escopos diferentes, mesmo que o documento diga “sistema de gestão de pedidos” nos três. A de R$ 18 mil pode ter excluído a integração com o ERP. A de R$ 56 mil pode estar incluindo 3 meses de manutenção pós-entrega. A de R$ 32 mil pode ter um prazo de 120 dias que ninguém deixou explícito.

Preço médio é como comparar a diária de um hostel, de um hotel de negócios e de um resort pela média e concluir que a melhor escolha é o intermediário. A média não diz nada sobre o que você está comprando.

A decisão honesta exige abrir o que está dentro de cada proposta — e comparar dimensão por dimensão, não número por número.

As 9 dimensões pra comparar (não só preço)

Essas 9 dimensões cobrem os pontos que mais frequentemente explicam diferença de valor entre propostas. Preço entra como uma das 9, não como a primeira nem a mais pesada.

Dimensão 1 — Escopo cravado

O que ENTRA e, principalmente, o que SAI explicitamente?

Proposta profissional lista funcionalidades por entregável: “Tela de cadastro de pedidos com X campos”, “Relatório de pedidos em aberto com filtro por data e status”, “Integração com API do Bling via webhook”. Não apenas “sistema de gestão completo”.

Perguntas de esclarecimento que valem fazer:

• “A integração com o nosso ERP está incluída ou é cobrada à parte?”
• “Relatórios estão inclusos ou são fase 2?”
• “Migração dos dados do sistema atual está no escopo?”

Se a proposta não lista por entregável, peça antes de comparar preço. Orçamento sem escopo discriminado não é comparável com os que têm.

Dimensão 2 — Tecnologia e stack

Qual linguagem, framework e banco de dados a casa vai usar?

Isso importa não pelo nome da tecnologia, mas por uma pergunta prática: se essa casa de software fechar as portas amanhã ou você quiser trocar de fornecedor em 2 anos, vai conseguir contratar alguém pra dar manutenção?

Stack padrão de mercado (Next.js, React, Node.js, PostgreSQL, Supabase) tem dezenas de profissionais disponíveis em qualquer cidade do Brasil. Stack proprietária ou framework obscuro reduz a zero o leque de quem pode assumir depois.

Pergunte diretamente: “Qual a stack tecnológica? Se eu precisar contratar outro desenvolvedor no futuro, ele vai conseguir trabalhar no código?”

Dimensão 3 — Código entregue no seu CNPJ

O código-fonte vai ficar em repositório no seu CNPJ — ou na conta da casa de software?

Essa dimensão decide se você vai ser dono do sistema ou locatário. Código no repositório do cliente (GitHub, GitLab) significa que você leva o projeto pra onde quiser. Código na conta da casa de software significa dependência enquanto ela existir.

A pergunta direta: “O repositório Git fica no GitHub do meu CNPJ desde o primeiro commit?”

Resposta verde: sim, com você como owner e admin. Resposta vermelha: “fica na nossa conta por enquanto, passamos depois.”

Exploramos esse ponto com mais detalhe em como contratar software house pequena confiável — é um dos 5 sinais de qualificação que usa como filtro antes de contratar.

Dimensão 4 — Garantia pós-entrega

Quanto tempo? O que cobre?

Garantia de 30 dias que cobre apenas “bugs críticos” sem definição de “crítico” é garantia de papel. O que vale ter:

• Prazo mínimo: 30 dias corridos pós go-live
• Escopo claro: bugs nas funcionalidades descritas no escopo (não novas funcionalidades)
• Processo definido: como reportar, prazo de resposta, o que conta como bug vs mudança de escopo

Sem definição do que é “bug”, toda conversa sobre correção vira negociação sobre se é bug ou nova funcionalidade — e você perde essa negociação porque quem define os termos é quem escreveu o contrato.

Dimensão 5 — Prazo e cronograma realista

Quantos dias úteis? Com milestones ou só entrega final?

Faixas de prazo indicam modelos diferentes de trabalho:

• 3 a 12 dias úteis: casa enxuta com IA acelerando código bruto, escopo bem definido, entrega incremental
• 30 a 60 dias: equipe pequena, processo mais formalizado, revisões intermediárias
• 90 a 180 dias: agência com equipe maior, reuniões semanais, gerente de projeto, documentação formal

Nenhum prazo é necessariamente melhor — depende do seu escopo e do que você precisa. O sinal de alerta é prazo sem marco: “entregamos em aproximadamente 8 semanas” sem nenhuma definição do que acontece em cada semana.

Pergunte: “Quais são os milestones? O que eu vejo e aprovo em cada um antes de pagar a próxima parcela?”

Dimensão 6 — Forma de pagamento

A estrutura de pagamento diz muito sobre a confiança que a casa tem no próprio trabalho.

Modelos e o que indicam:

100% antecipado: maior risco pra você, zero risco pra eles. Sinal de que a casa precisa do capital antes de produzir — ou de que não confia em completar o projeto a ponto de só receber no final.

50% entrada + 50% na entrega: modelo equilibrado. Protege os dois lados.

30/30/40 por marcos (entrada + demo aprovada + go-live): modelo ideal. Você só paga a próxima parcela depois de aprovar a etapa anterior. Incentiva entrega incremental com qualidade.

100% na entrega: sinal de casa confiante no próprio trabalho — mas risco real pra eles em projetos maiores. Pode indicar empresa estabelecida ou pode ser promessa que não vai se sustentar.

O modelo por marcos é o que melhor alinha incentivos. Mais detalhes sobre pagamento e contrato em 7 cláusulas pra revisar no contrato de software sob medida.

Dimensão 7 — Quem vai executar

Quem específico? Com qual perfil?

Proposta de agência costuma dizer “nossa equipe de desenvolvimento”. Que equipe? Qual o perfil de sênioridade? Vai ter rotação de profissional no meio do projeto?

Para projetos sob medida de PME, o executor tem impacto enorme no resultado. Um sênior com 8 anos de experiência na stack específica entrega diferente de um pleno recém-promovido.

Pergunte: “Quem especificamente vai trabalhar no projeto? Pode me mostrar o perfil — LinkedIn ou portfolio de projetos comparáveis?”

Casa séria responde com nome, perfil e dois ou três projetos que o profissional entregou. Casa que responde “vai ser a pessoa mais adequada do nosso time” é sinal de que vai alocar quem tiver disponível.

Dimensão 8 — Comunicação e processo de change request

Como vai funcionar o contato? Slack diário, reunião semanal formal, só por e-mail?

E o que acontece se você quiser mudar algo no meio do projeto?

Processo de mudança sem definição vira atrito. Toda vez que você pede algo fora do escopo original, vai virar negociação sobre se é cobrado extra e quanto. O que evita isso:

• Canal de comunicação definido
• Prazo de resposta cravado (ex: “respondemos em até 1 dia útil em horário comercial”)
• Processo claro de change request: como solicitar, prazo de orçamento, o que conta como mudança de escopo

Dimensão 9 — Cases reais comparáveis

A casa entregou projeto parecido com o seu antes?

Não portfólio genérico com logotipos de marcas famosas. Cases comparáveis: mesmo tamanho de empresa (PME 10-50 funcionários), escopo similar (sistema interno, não e-commerce ou site), cliente que você pode ligar e perguntar.

Peça 2 ou 3 referências de clientes com perfil parecido. Casa confiável tem clientes que atendem o telefone.

A planilha ponderada (template em 3 passos)

Com as 9 dimensões mapeadas, a comparação fica estruturada. O método é simples:

Segundo o Sebrae (Guia de Contratação de TI para PMEs), mais de 60% dos contratos de software com PMEs brasileiras terminam com pelo menos uma disputa sobre escopo não documentado. A raiz do problema quase sempre é a mesma: preço comparado sem critério de escopo.

Passo 1 — Defina o peso de cada dimensão (soma total = 100 pontos)

Você decide o peso conforme o que importa mais pro seu caso. Um exemplo pra sistema interno de gestão:

Note que preço vale 10 dos 100 pontos. Não é irrelevante — mas não é o critério principal.

Passo 2 — Score de 1 a 5 pra cada proposta em cada dimensão

Pra cada dimensão, você atribui um score de 1 (péssimo) a 5 (ótimo) pra cada proposta. Exemplo real:

Passo 3 — Total ponderado (peso × score, soma por proposta)

Usando o exemplo acima:

• Proposta A: (20×2) + (8×3) + (15×5) + (12×1) + (10×4) + (8×3) + (10×4) + (7×3) + (10×5) = 40+24+75+12+40+24+40+21+50 = 326
• Proposta B: (20×4) + (8×4) + (15×3) + (12×3) + (10×3) + (8×4) + (10×2) + (7×3) + (10×3) = 80+32+45+36+30+32+20+21+30 = 326
• Proposta C: (20×5) + (8×4) + (15×4) + (12×4) + (10×2) + (8×3) + (10×3) + (7×4) + (10×1) = 100+32+60+48+20+24+30+28+10 = 352

Nesse exemplo, a de R$ 56 mil tem o melhor score — mas a diferença pra B é 26 pontos. Antes de decidir, vale pedir esclarecimento da Proposta B nas dimensões em que ela ficou abaixo: por que o código não vai pro repositório do cliente? A garantia de 30 dias pode aumentar? Se a B responder bem a esses dois pontos, a distância cai e o preço menor se torna decisivo.

Esse processo tem 60 a 90 minutos de trabalho. A decisão sai com argumento, não com intuição.

Bandeiras vermelhas — quando barata é armadilha

Há diferença entre proposta barata honesta e proposta barata perigosa. O Standish Group Chaos Report 2024 aponta que apenas 35% dos projetos de software são entregues no prazo e dentro do orçamento — e a principal causa de falha não é falta de tecnologia, é falta de escopo claro antes do início. As bandeiras abaixo aparecem quase sempre nas propostas que contribuem para essa estatística:

“Sistema de gestão completo — R$ 18.000” Sem escopo discriminado por funcionalidade. “Completo” não diz nada. Quando o projeto começar, tudo que você pedir que não estava na cabeça do vendedor vai ser cobrado extra.

Garantia “30 dias pra bug crítico” sem definição de crítico Você vai descobrir o que é “crítico” na hora que reportar o primeiro problema. Frequentemente, nada é crítico exceto o que para a produção total. Bug de relatório, erro de cálculo, dado duplicado — “não é crítico, é cobrado.”

“Código fica na nossa plataforma / em nosso servidor” Às vezes não é má-fé: a casa pode ter infraestrutura própria de deploy e achar que está facilitando. Mas o resultado é o mesmo: você não tem o código. Se a casa fechar, você perde o sistema.

“Começamos quando conseguirmos alocar” Sem data de início = a casa tem fila e você não sabe qual é a sua posição nela. Projeto pode começar em 2 semanas ou em 4 meses. Cronograma que não existe não é prazo.

“Nossa equipe é super qualificada” Sem nome, sem LinkedIn, sem case. Toda equipe que se descreve assim está escondendo que vai alocar quem estiver disponível no dia que o projeto entrar na fila.

“20% de entrada, 80% na entrega final” Pagamento 100% no final tem um risco real: conforme o projeto avança, você vai acumulando leverage sobre a casa de software. Se você não pagar, eles perderam meses de trabalho. Isso cria incentivo pra eles atrasarem a entrega até resolver outros contratos que já pagaram.

Bandeiras verdes — o que identifica proposta confiável

O inverso direto das bandeiras acima — e alguns sinais extras:

Escopo discriminado por entregável “Tela X com Y campos”, “Relatório Z com filtros A e B”, “Integração com API W via webhook no evento de novo pedido”. Quanto mais específico, menos margem pra interpretação posterior.

Garantia com prazo e escopo explícitos “30 dias corridos pós go-live aprovado, cobrindo bugs nas funcionalidades do escopo. Bug é comportamento diferente do especificado nas demos aprovadas.”

Código no GitHub do cliente desde o sprint 1 “O repositório fica na conta GitHub do seu CNPJ, com você como owner. A gente tem acesso de colaborador durante o desenvolvimento.”

Cronograma com data de início e milestones “Início em [data X]. Demo da Fase 1 em [data Y]. Go-live em [data Z]. Cada fase tem aceite formal antes de avançar.”

Profissional nominado ou perfil específico “O projeto vai ser executado por [nome], sênior com 7 anos em Next.js + Supabase. Aqui estão três projetos comparáveis que ele entregou.”

2 ou 3 clientes reais com telefone Casa confiável tem cliente que atende o telefone. Se a referência é só logotipo no portfólio, não é referência.

Quando a mais cara realmente vale

A proposta de R$ 56 mil pode ser a certa. Esses são os casos em que ela faz sentido:

Escopo maior de verdade. Você abriu o escopo das três propostas e a de R$ 56 mil tem mais funcionalidades — integração extra, módulo de relatório mais robusto, migração de dados incluída. A diferença de preço rastreia diferença de entrega.

Garantia de 6 meses ou mais. Para sistemas críticos (gestão financeira, controle de estoque, faturamento), garantia de 6 meses de suporte tem valor real. Você vai encontrar bugs em produção que os testes não pegaram. Seis meses de janela pra correção sem cobrança extra vale dinheiro.

Profissional sênior nominado com cases reais comparáveis. Sênior de verdade entrega diferente. Não pela stack — pela capacidade de antecipar problema de regra de negócio antes de ele se tornar retrabalho.

Stack ou integração especializada necessária. Se o seu sistema exige integração com SAP, com sistema legado específico, ou com API de setor regulado (financeiro, saúde), experiência prévia naquele contexto específico justifica premium.

O que NÃO justifica premium: overhead institucional sem ganho técnico real pra você. Agência com 30 pessoas, sala física, gerente de projeto dedicado, 3 reuniões semanais formais — se seu escopo é 8 telas de sistema interno, você vai pagar pela estrutura toda sem precisar dela.

Quando a mais barata é a certa

A proposta de R$ 18 mil pode ser a melhor compra. Esses são os casos:

Casa enxuta especializada, escopo fechado e realista. 1 ou 2 profissionais sênior que trabalham com stack padrão de mercado. O baixo preço vem da estrutura enxuta — sem overhead de gerente de projeto, sem sala física, sem comercial estruturado. Se o profissional é sênior e o escopo está discriminado, o preço baixo é vantagem, não sinal de problema.

Código no CNPJ do cliente e infra na conta do cliente. Casa pequeena que entrega o código no seu GitHub e a infra no seu Supabase está te dando independência. Você pode contratar qualquer outro profissional amanhã sem depender deles.

Prazo cravado em dias úteis com milestone explícito. Casa de R$ 18 mil que diz “7 dias úteis, com demo aprovada no dia 5 e go-live no dia 7” está sendo mais precisa do que proposta de R$ 56 mil que diz “estimativa de 90 dias”.

Cases reais comparáveis. Se a casa de R$ 18 mil tem 3 clientes parecidos com você que entregaram no prazo e com o código correto, isso é prova que vale mais do que o nome da agência grande.

O que NÃO é barato-confiável: proposta sem escopo + executor desconhecido + sem garantia + código na conta da casa. Isso é barato-arriscado. A diferença entre os dois está nas respostas às perguntas das 9 dimensões — não no preço em si.

Como a Adrion entra nesse comparativo

Vou ser direto sobre onde a Adrion ganha e onde perde — porque isso é mais útil pra você do que pitch de vendas.

A Adrion ganha quando:

• Você tem escopo bem definido (regras mapeadas, fluxos claros, integrações identificadas)
• Quer prazo em dias úteis (não em “estimativa de meses”)
• Precisa de código no GitHub do seu CNPJ desde o sprint 1
• Quer pagamento por milestones com marco de aceite formal
• Precisa de sistema pronto em 3 a 12 dias úteis (conforme escopo)
• Quer diagnóstico honesto antes — inclusive que a resposta pode ser “não é hora de sob medida”

Antes de orçar, a gente faz uma sessão de diagnóstico de 15 minutos. Se o escopo não está maduro o suficiente, indico antes de você pagar qualquer valor. Um passo anterior que resolve muito isso: como mapear a regra da Joana antes de pedir orçamento.

A Adrion perde quando:

• Você precisa de gerente de projeto dedicado com presença física semanal
• Sua empresa exige processo formal com ATA de reunião, escopo em documento Word de 40 páginas e aprovação de diretoria em 3 camadas
• A operação é complexa do ponto de vista fiscal (NF-e em volume alto, SPED Contábil, regime tributário misto) — esse contexto pede agência com especialista fiscal na equipe
• Você precisa de integração com SAP, Protheus ou sistema legado de grande porte

Nesses cenários, agência maior é a resposta certa — e prefiro indicar do que aceitar projeto que não cabe na operação. Empurrar projeto que não cabe queima reputação que leva 15 anos pra construir.

Se você está no momento de decidir entre proposta Adrion e outras, a sessão de briefing estruturado que uso como etapa anterior ajuda a verificar se o escopo está maduro: briefing de software em 90 minutos.

E se você ainda está no momento de escolher a casa (antes de receber propostas), o passo anterior que cobre isso: como contratar software house pequena confiável.

Depois da decisão, o próximo passo é o contrato — e ele tem 7 cláusulas que merecem revisão antes de assinar: 7 armadilhas no contrato de software sob medida.

Antes de fechar a decisão

Você tem 3 propostas, a planilha ponderada preenchida e os scores calculados. Antes de assinar, um passo final:

Pegue as top 2 propostas pelo score. Identifique as 2 ou 3 dimensões em que a segunda colocada ficou abaixo. Peça reunião de esclarecimento com cada uma — 30 minutos, foco nas dimensões de dúvida.

“A proposta de vocês não especifica o executor. Quem vai trabalhar no projeto especificamente?” “A garantia menciona 30 dias, mas o que está coberto? Se aparecer bug de cálculo no relatório no dia 25, está no escopo da garantia?” “O repositório vai ficar no GitHub de vocês ou no meu?”

As respostas a essas perguntas vão separar o que parece bom do que é bom.

Se quiser uma análise técnica das 3 propostas antes de decidir — não jurídica, mas de quem lê proposta de sistema dos dois lados —, manda “auditoria propostas” no WhatsApp. São 30 minutos, sem custo, sem pitch. Em uns 20-25% dos casos a resposta é “a mais barata está correta pra o seu caso.” O restante, a gente identifica a dimensão que está escondendo risco.

Sobre o autor: Lucas Américo dos Reis é fundador do Grupo Adrion. Atua em telecom corporativo e arquitetura de sistemas desde 2008 (GVT, Brasil Telecom, Oi, Claro, Embratel, Vivo). LinkedIn