Antes de dar um número, a LT Cloud faz 3 perguntas que não têm nada a ver com dinheiro. Veja quais são e por que todo cliente deveria se fazer as mesmas.
Toda semana, um empreendedor liga para uma software house e faz a pergunta errada. Não porque “quanto custa” seja proibido mas porque é a única coisa que ele perguntou.
Antes de qualquer orçamento sair da LT Cloud, três perguntas passam pela mesa, e nenhuma delas é sobre dinheiro. Se você se fizer essas mesmas perguntas antes de procurar um fornecedor, chega à primeira reunião com um projeto que pode ser orçado com precisão em vez de um chute educado.
Por que “quanto custa” é a pergunta errada
Um número sem contexto não é um orçamento. É um chute com formatação profissional.
Quando uma software house responde “quanto custa” sem entender o problema por trás do pedido, ela está fazendo uma escolha: estimar em cima do que foi dito, não do que é necessário. O resultado aparece meses depois, na forma de escopo que cresceu, prazo que estourou e um cliente perguntando por que o app “simples” virou um projeto de seis meses.
Na LT Cloud, aprendemos isso. Depois de mais de 125 projetos entregues em setores como saúde, fintech, delivery e logística, ficou claro que a precisão de um orçamento não vem da planilha de horas. Vem da maturidade das respostas que o cliente traz antes de pedir o número.
Por isso, as três perguntas abaixo não são burocracia de vendas. Elas existem para proteger os dois lados: o cliente, de pagar por retrabalho que poderia ter sido evitado com uma conversa de vinte minutos; e o fornecedor, de assinar um compromisso de prazo sobre um escopo que ainda não existe de verdade.
Se o seu projeto ainda não tem resposta clara para as três, isso não significa que você não deve construir, significa que ainda não é hora de pedir um orçamento fechado. E é exatamente essa diferença que separa um projeto que dá certo de um que vira histórico de desconfiança entre cliente e fornecedor.
Pergunta 1: qual problema de negócio isso resolve, e como você vai medir que resolveu?
A maioria dos briefings chega como lista de features: “preciso de um app com login, cadastro, pagamento e um painel administrativo.” Isso descreve uma tela, não um problema.
A primeira pergunta que fazemos inverte a lógica: qual resultado de negócio essa lista de features deveria produzir? Reduzir o tempo de atendimento em 30%? Eliminar uma planilha que trava a operação toda sexta-feira? Permitir vender em um canal que hoje é 100% manual?
Sem essa resposta, dois projetos com a mesma lista de telas podem ter escopos completamente diferentes, e o preço vai variar de acordo. Um sistema de agendamento para uma clínica que quer reduzir faltas em 20% precisa de lembretes automáticos e regras de reagendamento. Um sistema de agendamento que só existe para “ter tudo digitalizado” pode ser metade disso.
O segundo pedaço da pergunta é o que mais separa projetos maduros dos que ainda estão engatinhando: como você vai medir que funcionou? Se a resposta é “vou saber quando ver”, o projeto ainda não está pronto para virar orçamento, está pronto para uma conversa de descoberta.
Quando o cliente chega com o problema de negócio amarrado a um número e não a uma lista de telas, o escopo se organiza sozinho em torno do que realmente move o ROI do projeto, e cada linha do orçamento passa a ter uma justificativa concreta.
Pergunta 2: qual é o prazo real e o que está em jogo se ele não for cumprido?
Todo cliente diz que precisa “o mais rápido possível.” Mas nem todo prazo apertado é real, e essa diferença muda completamente como um projeto deve ser orçado.
A segunda pergunta que fazemos separa dois tipos de urgência: a que tem uma consequência de negócio clara se não for cumprida (perder uma janela sazonal, cumprir uma exigência regulatória, lançar antes de um concorrente específico) e a que é apenas desconforto, o cliente quer logo, mas nada quebra se o projeto levar mais duas semanas.
Quando o prazo é real, isso muda a equação do orçamento: pode significar mais desenvolvedores trabalhando em paralelo, escopo reduzido para caber na janela, ou uma primeira versão mais simples para evoluir depois. Cada uma dessas opções tem um preço diferente e nenhuma delas aparece numa cotação genérica que ignora a pergunta.
Quando o prazo é elástico, o orçamento pode priorizar o caminho mais robusto e mais barato, mesmo que leve mais tempo sem pagar o prêmio de velocidade por uma urgência que não existe de verdade.
Na LT Cloud, pedimos para o cliente nomear a consequência específica de perder o prazo. Se a resposta for genérica, “porque eu quero logo”, isso não é motivo para descartar a urgência, mas é sinal de que vale reavaliar se compensa pagar mais para acelerar, ou se o dinheiro rende mais investido num escopo mais completo dentro de um prazo um pouco mais longo.
Como essas perguntas mudam o orçamento na prática
Um exemplo real ajuda a tornar isso concreto: um cliente do setor de saúde chegou pedindo “um app de telemedicina.” Sem mais contexto, esse pedido poderia custar qualquer coisa entre um MVP simples e uma plataforma completa de prontuário eletrônico.
As três perguntas mudaram tudo. O problema de negócio era reduzir o no-show em consultas de retorno, não criar uma central de telemedicina completa. Isso, sozinho, já cortou boa parte do escopo inicial imaginado.
Na sequência, ficou claro que partes do fluxo, como agenda e notificação podiam usar integrações prontas, enquanto o núcleo de atendimento por vídeo com prontuário integrado precisava ser sob medida, por causa de exigências específicas de conformidade do setor. E a validação semanal ficou concentrada em uma única responsável clínica, o que permitiu ciclos de entrega curtos e previsíveis.
Esse padrão se repete nos mais de 125 projetos que já entregamos, em fintech, delivery, educação, logística entre outros. O time-to-market de cada um desses projetos dependeu menos da complexidade técnica e mais da clareza com que essas três respostas chegaram até a mesa de orçamento.
O que acontece quando essas perguntas são puladas
Quando um fornecedor orça sem fazer essas perguntas, o risco não desaparece só é adiado. Ele volta na forma de aditivos de contrato, prazos renegociados e uma sensação, dos dois lados, de que “o projeto fugiu do controle.”
O padrão mais comum é o escopo crescer silenciosamente: cada reunião adiciona “só mais uma tela,” porque ninguém amarrou o projeto a um resultado de negócio mensurável desde o início. Sem essa âncora, não existe critério para dizer não.
O segundo padrão é a compra da ferramenta errada: sistemas sob medida caros demais para problemas que um SaaS resolveria em dias, ou o oposto, SaaS genérico tentando fazer o papel de um processo que exigia solução própria desde o primeiro dia.
E o terceiro é o mais silencioso: projetos tecnicamente perfeitos que travam porque ninguém, do lado do cliente, tinha autoridade para dizer “aprovado, pode seguir.” Nenhum desses três problemas é sobre código. Todos são sobre perguntas que não foram feitas antes de existir um número no papel.
Um orçamento preciso não começa em uma planilha, começa nas respostas que existem antes dela. As três perguntas acima existem para expor, com honestidade, se um projeto está maduro o suficiente para receber um número confiável.
Antes de pedir seu próximo orçamento a qualquer fornecedor, escreva as respostas para essas três perguntas em um parágrafo cada. Se alguma ficar em branco, agende uma conversa de diagnóstico com a LT Cloud, vamos ajudar a estruturar as respostas antes de falar de preço, para que o orçamento que você receber reflita o projeto que você realmente precisa construir.