Imagine a cena.
É o fim da tarde. Há três PDFs abertos na tela e todos prometem resolver o mesmo problema. Um cabe em duas páginas e custa bem menos. Outro traz um cronograma bonito, dezenas de funcionalidades e um valor que assusta. O terceiro faz perguntas que ninguém tinha feito e apresenta uma primeira etapa menor.
A vontade é colocar os três preços em uma planilha, ordenar do menor para o maior e seguir em frente.
Só que existe um problema: talvez você não esteja comparando três preços para o mesmo software.
Uma proposta pode incluir levantamento, protótipo, migração de dados, testes, publicação e suporte. Outra pode chamar de “sistema completo” apenas a programação das telas, deixando cadastro inicial, infraestrutura, segurança, treinamento e correções para uma conversa futura.
O número no rodapé parece objetivo. O que existe por trás dele nem sempre é.
Este guia mostra como comparar um orçamento de software sob medida de forma prática, mesmo que você não seja da área de tecnologia. A ideia não é transformar a decisão em uma auditoria interminável. É ajudar você a descobrir o que será entregue, o que continuará sendo sua responsabilidade e quais custos podem aparecer depois.
Resposta curta: faça todas as propostas responderem ao mesmo resumo do problema e compare quatro camadas: entrega, qualidade, controle e operação. Depois avalie o custo total, não apenas o valor inicial.
Antes de comparar preços, confirme se a pergunta é a mesma
“Preciso de um sistema para organizar minha operação” pode significar coisas muito diferentes.
Para uma empresa, isso pode ser uma agenda compartilhada com histórico do cliente. Para outra, envolve aplicativo de campo, funcionamento sem internet, integração financeira, permissões por filial e migração de milhares de registros. As duas usam a palavra sistema, mas o esforço, o risco e a responsabilidade são diferentes.
Antes de pedir uma nova rodada de preços, escreva um resumo de uma página com:
- o problema atual: onde a informação se perde, atrasa ou exige retrabalho;
- quem usa: perfis de usuário, quantidade aproximada de pessoas e locais de uso;
- o primeiro fluxo: do início ao resultado que precisa ficar registrado;
- integrações necessárias: ERP, WhatsApp, pagamento, e-mail, planilhas ou equipamentos;
- dados existentes: onde estão, quem entende a estrutura e se precisam ser migrados;
- restrições reais: prazo regulatório, contrato que termina, sazonalidade ou limite técnico;
- resultado esperado: o que deverá melhorar e como a empresa perceberá isso;
- o que fica de fora da primeira versão: uma lista curta de não objetivos.
Esse resumo não precisa antecipar todas as telas. Ele serve para impedir que cada fornecedor preencha os vazios com uma interpretação diferente.
Se a operação ainda depende de arquivos duplicados, mensagens e controles paralelos, o artigo sobre quando a planilha vira gargalo ajuda a descrever o problema antes de descrevê-lo como software.
As quatro camadas de uma proposta comparável
Um orçamento fica mais fácil de analisar quando você o separa em quatro blocos:
- Entrega: o que será construído, o que não será e como você aceitará cada resultado.
- Qualidade: como serão tratados testes, segurança, privacidade, desempenho e confiabilidade.
- Controle: quem terá acesso ao código, aos dados, às contas e à documentação.
- Operação: o que acontece depois da publicação, quanto custa manter e como o produto evolui.
O valor da proposta continua importante. A diferença é que agora ele vem acompanhado do produto, das responsabilidades e dos riscos que representa.
1. Entrega: o que existirá no final de cada etapa?
A primeira pergunta não é “quantas telas estão incluídas?”. É qual parte do trabalho estará realmente funcionando.
Uma proposta pode listar:
- login;
- cadastro de clientes;
- dashboard;
- relatórios;
- aplicativo;
- painel administrativo.
A lista parece completa, mas ainda deixa dúvidas essenciais. Quem pode editar o quê? O aplicativo precisa funcionar sem sinal? Qual dado entra no relatório? O sistema envia notificações? Há importação do histórico? O que acontece quando uma integração fica indisponível?
Procure entregas descritas como fluxos verificáveis. Por exemplo:
Um atendente registra o pedido, agenda uma visita e atribui um técnico. O técnico recebe os dados necessários, registra a execução e anexa evidências. A operação acompanha pendências e o cliente recebe uma atualização.
Esse formato conecta funcionalidades a uma rotina que pode ser demonstrada e aceita.
Escopo bom também explica o que ficou de fora
Exclusão não é sinal de uma proposta ruim. Muitas vezes, é sinal de que alguém fez escolhas.
Uma primeira versão pode deixar de fora:
- aplicativo nativo, usando uma interface web adaptada ao celular;
- integração automática com um sistema antigo;
- relatórios avançados;
- funcionamento offline;
- migração de anexos históricos;
- automações que dependem de dados ainda desorganizados.
O problema começa quando essas ausências só aparecem depois da assinatura.
Leia a seção de exclusões com a mesma atenção dedicada ao preço. Se ela não existir, peça que seja criada.
Critério de aceite reduz discussão subjetiva
“Funcionalidade concluída” pode significar código escrito, tela disponível para teste ou fluxo validado em produção. Definam o significado antes.
Um critério de aceite útil responde:
- qual situação será testada;
- quem fará a validação;
- quais dados serão usados;
- qual resultado deve acontecer;
- como defeitos serão registrados e corrigidos;
- quanto tempo o cliente terá para avaliar.
O modelo de requisitos mínimos do Governo Digital é voltado aos órgãos do Sisp, não às empresas privadas. Ainda assim, deixa um princípio útil para qualquer contratação: requisitos de qualidade precisam se transformar em critérios de aceitação dos produtos entregues.
Você não precisa copiar um modelo público. Precisa conseguir responder: “como saberemos que esta etapa está pronta?”.
2. Qualidade: o que impede o sistema de virar um problema novo?
Quando duas propostas descrevem as mesmas telas, a diferença pode estar no que o usuário não vê durante a demonstração.
Pergunte como o projeto tratará:
- testes dos fluxos principais;
- erros e situações incomuns;
- permissões de acesso;
- registro de ações importantes;
- cópias de segurança e restauração;
- proteção de dados pessoais;
- dependências de terceiros;
- desempenho nos horários de maior uso;
- monitoramento depois da publicação;
- atualização de componentes e correções de segurança.
Não aceite “seguimos boas práticas” como única resposta. Peça um exemplo de evidência: plano de testes, ambiente de homologação, relatório de execução, revisão de código, rotina de backup testada ou critérios de segurança aplicáveis ao projeto.
Segurança precisa entrar antes do código
A OWASP Secure by Design orienta que requisitos de segurança sejam definidos no planejamento e acompanhados ao longo do ciclo de vida. A OWASP ASVS oferece requisitos que podem servir de base para desenvolvimento, verificação e até especificação contratual de segurança.
Isso não significa exigir uma sigla sem contexto em todo projeto. Significa discutir cedo questões como:
- quais dados são sensíveis;
- quem pode acessar cada informação;
- como contas administrativas serão protegidas;
- onde segredos e credenciais ficarão;
- quais ações precisam de rastreabilidade;
- o que deve acontecer quando uma integração falhar.
Se o sistema tratar dados pessoais, a LGPD entra na conversa desde a definição do fluxo. O software não torna a empresa automaticamente adequada à lei, mas a arquitetura pode facilitar ou dificultar controle de acesso, retenção, correção, exportação e exclusão de dados.
3. Controle: de quem são os acessos, os dados e a continuidade?
É possível receber um sistema funcionando e, ainda assim, ficar sem controle sobre ele.
Antes de contratar, esclareça quem terá acesso a:
- repositório do código-fonte;
- ambientes de desenvolvimento, teste e produção;
- conta de hospedagem e serviços em nuvem;
- domínio e configurações de DNS;
- banco de dados e cópias de segurança;
- contas de envio de e-mail, mensagens e notificações;
- lojas de aplicativos, quando existirem;
- ferramentas de monitoramento e análise;
- documentação técnica e de uso.
Também pergunte em qual conta cada serviço será criado. Quando tudo fica em uma conta exclusiva do fornecedor, uma troca de equipe pode exigir uma migração que ninguém havia planejado.
Código-fonte exige uma conversa contratual clara
“Código incluso” é uma frase insuficiente.
O contrato precisa esclarecer direitos de uso e alteração, acesso ao repositório, componentes licenciados por terceiros, bibliotecas abertas, possibilidade de contratar outra equipe e condições de transição. A resposta depende do modelo do projeto, por isso decisões de propriedade intelectual devem ser revisadas por um profissional jurídico quando forem relevantes para o negócio.
Do ponto de vista operacional, há uma pergunta simples:
Se a relação com o fornecedor terminar de forma organizada, outra equipe terá código, dados, acessos e documentação suficientes para continuar o trabalho?
Você não precisa planejar uma ruptura. Precisa evitar que a continuidade dependa de uma senha que só outra empresa possui.
4. Operação: quanto custa manter o sistema útil?
A entrega em produção não encerra a vida do software. É ali que começam usuários reais, dados reais, falhas de integração, dúvidas, picos de acesso e mudanças no processo.
Separe pelo menos cinco itens:
- Infraestrutura: hospedagem, banco de dados, armazenamento, envio de e-mail, mensagens, mapas e outros serviços.
- Suporte: dúvidas, incidentes e orientação aos usuários.
- Garantia: correção de defeitos relacionados ao que foi aceito.
- Manutenção: atualizações técnicas, segurança, monitoramento e continuidade operacional.
- Evolução: novas regras, integrações, relatórios e funcionalidades.
Esses serviços podem ser cobrados por mensalidade, pacote de horas, demanda ou contrato separado. Nenhum modelo é automaticamente melhor. O importante é saber:
- o que está incluído;
- o que gera cobrança adicional;
- qual canal deve ser usado;
- quais são os horários de atendimento;
- como urgência e prioridade são definidas;
- quais prazos são assumidos;
- quem monitora a aplicação;
- como mudanças serão estimadas.
Uma proposta barata pode excluir operação. Outra mais alta pode incluir meses de suporte, observabilidade e pequenas evoluções. Sem separar os componentes, a comparação fica injusta para os dois lados.
Uma matriz simples para colocar as propostas na mesma mesa
Crie uma tabela e peça evidências curtas. “Sim” ou “incluído” não basta quando o item é importante.
| Critério | Pergunta para comparar | Evidência esperada |
|---|---|---|
| Problema | A proposta descreve a dor e o resultado desejado? | Resumo do contexto e objetivo |
| Primeiro fluxo | O que funcionará de ponta a ponta? | Cenário demonstrável |
| Escopo | O que entra e o que fica de fora? | Lista de inclusões e exclusões |
| Aceite | Como cada etapa será aprovada? | Critérios e responsabilidade de validação |
| Qualidade | Como testes, erros e desempenho serão tratados? | Estratégia e evidências de teste |
| Segurança e dados | Quais controles são necessários para este risco? | Requisitos, responsáveis e validações |
| Controle | Quem acessa código, dados, nuvem e documentação? | Relação de contas, permissões e entregáveis |
| Implantação | Como o sistema chegará aos usuários? | Plano de publicação, migração e treinamento |
| Operação | Quem cuida depois do lançamento? | Suporte, garantia, manutenção e limites |
| Custo total | Quais gastos existem além do projeto? | Estimativa de recorrências e serviços de terceiros |
| Mudanças | O que acontece quando o escopo mudar? | Processo de análise, aprovação e cobrança |
| Continuidade | Outra equipe consegue assumir? | Código, acessos, dados e documentação transferíveis |
Você pode classificar cada linha como clara, parcial ou não respondida. A coluna vazia revela mais do que uma nota inventada com falsa precisão.
Um exemplo: três propostas para a mesma operação de campo
Considere uma empresa de serviços que recebe pedidos, agenda visitas e envia técnicos. Hoje, endereço, relato do cliente, fotos e status ficam espalhados entre mensagens e uma planilha.
Ela envia o mesmo resumo a três fornecedores.
Proposta A: “sistema completo” em poucas linhas
A proposta lista cadastro, agenda, aplicativo e dashboard. O prazo é curto e o preço é o menor. Não menciona migração, funcionamento sem internet, publicação, critérios de aceite nem suporte.
Ela pode ser uma ótima oferta. Também pode depender de várias premissas ainda não declaradas.
Proposta B: tudo de uma vez
A segunda proposta descreve aplicativo nativo, portal do cliente, financeiro, estoque, roteirização e relatórios avançados. Traz uma equipe maior, prazo mais longo e preço alto.
O documento parece completo, mas talvez resolva em uma única contratação problemas que a empresa ainda nem validou. O risco aqui pode ser financiar um escopo grande antes de aprender com o uso.
Proposta C: descoberta curta e primeiro fluxo
A terceira começa com uma etapa de descoberta. Depois entrega um fluxo: pedido, agendamento, visita, evidência e encerramento. As integrações menos urgentes ficam para uma fase posterior. Critérios de aceite, acessos e custos recorrentes aparecem desde o início.
Ela não é automaticamente a melhor. Se o negócio já tiver requisitos estáveis, escala conhecida e prazo obrigatório, a Proposta B pode fazer mais sentido. Se a Proposta A responder às lacunas e comprovar a entrega, o menor preço pode ser legítimo.
O ponto é outro: só depois de preencher as lacunas as três opções se tornam comparáveis.
Preço fechado ou descoberta primeiro?
Quando o fluxo está conhecido, as regras são estáveis e as integrações foram verificadas, uma proposta por etapas com preço definido pode funcionar bem.
Quando há dúvidas sobre processo, dados antigos, integrações ou prioridade, pressionar por um valor fechado pode produzir duas reações:
- o fornecedor adiciona uma margem grande para se proteger;
- o fornecedor assume o cenário mais simples e as diferenças viram mudanças cobradas depois.
Nesse caso, uma descoberta curta pode entregar:
- mapa do processo atual;
- usuários e necessidades;
- recorte da primeira versão;
- protótipo dos fluxos críticos;
- inventário de dados e integrações;
- riscos e decisões pendentes;
- plano de etapas;
- faixa revisada de investimento.
A descoberta não deveria ser apenas uma sequência de reuniões. Combine quais artefatos você receberá e se eles poderão orientar outra equipe caso o desenvolvimento não continue com o mesmo fornecedor.
Se você está num estágio ainda anterior, o guia sobre como tirar uma ideia de empresa do papel mostra como sair da intenção e chegar a um primeiro fluxo testável.
Compare o custo total, não apenas o projeto inicial
Para cada opção, some as categorias que se aplicam ao seu cenário:
- descoberta e desenho;
- desenvolvimento;
- migração e limpeza de dados;
- integrações e serviços de terceiros;
- publicação e configuração inicial;
- treinamento e adoção;
- infraestrutura recorrente;
- licenças por usuário ou por consumo;
- suporte e manutenção;
- monitoramento e segurança;
- tempo da equipe interna;
- evolução previsível após o primeiro uso;
- custo de transição ou encerramento.
Escolha um período coerente com a decisão e use o mesmo horizonte para todas as propostas. Não há necessidade de prever cada centavo. O objetivo é descobrir se uma oferta desloca custos para depois.
Também registre o que pode variar por volume: usuários, mensagens, armazenamento, transações, mapas, chamadas de IA ou processamento de arquivos. Peça exemplos de como acompanhar esses consumos.
Doze perguntas para fazer antes de assinar
Leve esta lista para a próxima conversa:
- Qual problema vocês entenderam que estamos tentando resolver?
- Qual é o primeiro fluxo que estará funcionando de ponta a ponta?
- O que está explicitamente fora desta proposta?
- Quais decisões e materiais dependem da nossa equipe?
- Como cada etapa será demonstrada e aceita?
- Quais dados serão migrados e quem prepara esses dados?
- Quais integrações já foram verificadas e quais ainda são hipóteses?
- Como testes, segurança, privacidade e backup serão comprovados?
- Em quais contas ficarão código, infraestrutura, domínio e serviços externos?
- O que acontece depois da publicação: garantia, suporte, manutenção e evolução?
- Quais custos recorrentes ou variáveis não estão no valor principal?
- Se outra equipe assumir o produto, o que será entregue na transição?
Uma conversa madura não exige respostas perfeitas para tudo. Exige que as incertezas sejam nomeadas e recebam um responsável.
Sinais de alerta em um orçamento de software
Desconfie quando encontrar:
- “tudo incluso” sem escopo ou exclusões;
- prazo firme antes de verificar dados e integrações;
- dezenas de funcionalidades sem um primeiro fluxo prioritário;
- “segurança padrão” sem requisitos proporcionais ao risco;
- ausência de critérios de aceite;
- suporte “a combinar” após a publicação;
- custos de nuvem e serviços externos ignorados;
- nenhuma definição sobre código, contas, dados e documentação;
- mudança de escopo tratada apenas como conflito, sem processo;
- dependência permanente do fornecedor apresentada como conveniência;
- proposta que não reserva participação da equipe do cliente.
O último ponto é importante. Software sob medida exige decisões do negócio. Quando ninguém do cliente tem tempo para validar fluxos, preparar dados e responder dúvidas, o desenvolvimento passa a operar por suposições.
O menor preço pode ser a melhor escolha
Preço baixo não é defeito. Ele pode vir de decisões inteligentes:
- usar um produto existente em vez de construir tudo;
- reduzir o primeiro escopo;
- aproveitar uma integração pronta;
- começar pela interface web em vez de dois aplicativos nativos;
- adiar relatórios pouco usados;
- manter uma etapa manual até haver volume para automatizar;
- eliminar uma regra que só existia por causa da planilha antiga.
Uma boa proposta menor explica por que consegue custar menos e quais limites acompanham essa escolha.
O erro é confundir silêncio com eficiência.
Se o orçamento está apertado, diminua o primeiro compromisso
Quando todas as propostas passam do valor disponível, evite cortar testes, segurança e controle de acesso de forma indiscriminada. Reduza o tamanho do problema inicial.
Uma sequência possível é:
- Descobrir: mapear processo, dados, riscos e prioridade.
- Entregar: colocar um fluxo pequeno em uso real.
- Estabilizar: corrigir, medir adoção e resolver pontos de operação.
- Expandir: adicionar integrações e novos fluxos com base no aprendizado.
Esse modelo preserva qualidade sem exigir que a empresa aposte todo o orçamento antes de observar o comportamento dos usuários.
Em alguns casos, a melhor decisão será não desenvolver. Um SaaS já existente, uma automação simples ou uma melhoria de processo podem resolver o suficiente. Uma equipe confiável deveria conseguir dizer isso.
Se a necessidade for contínua e envolver várias frentes, vale também entender quando uma equipe de TI terceirizada faz sentido, em vez de tratar cada melhoria como um projeto isolado.
Como uma boa proposta costuma se comportar
Uma boa proposta pode ser menos confortável de ler.
Ela faz perguntas. Expõe dependências. Admite que uma integração precisa ser testada. Separa o essencial do desejável. Mostra o que o cliente precisará fazer. Não promete uma data mágica para uma ideia que ainda muda a cada reunião.
Também deixa espaço para adaptação. Software é construído com informação incompleta, e o uso real ensina coisas que nenhum documento antecipa. O contrato precisa organizar a mudança, não fingir que ela nunca acontecerá.
No fim, confiança não nasce de uma promessa ampla. Nasce de pequenos sinais:
- o problema foi entendido;
- as escolhas estão visíveis;
- as responsabilidades têm nome;
- os resultados podem ser verificados;
- a empresa mantém controle sobre o que é estratégico;
- os custos futuros não estão escondidos.
A decisão mais segura é a que você consegue explicar
Depois de comparar as propostas, você deveria conseguir dizer em linguagem simples:
Escolhemos esta opção porque ela resolve primeiro este fluxo, inclui estas entregas, trata estes riscos, mantém estes acessos conosco e terá este custo para operar. Estes itens ficarão para depois.
Se a decisão só pode ser defendida com “era a mais barata” ou “parecia a empresa mais técnica”, ainda faltam informações.
Um orçamento de software sob medida não precisa prever o futuro inteiro. Precisa transformar uma necessidade em um compromisso compreensível, verificável e sustentável.
Na Foyth Tech, ajudamos empresas a transformar processos confusos em um primeiro escopo claro — e a construir por etapas, com acesso, qualidade e operação pensados desde o início. Se você está diante de propostas difíceis de comparar ou ainda precisa organizar a demanda, converse com a Foyth Tech.
Este conteúdo é informativo e não substitui análise jurídica, contábil ou de proteção de dados aplicável ao seu contrato e à sua operação.
