Para comparar orçamentos de site ou sistema sem errar, não comece pelo valor final. Primeiro coloque as propostas na mesma base: o mesmo escopo, os custos que continuam depois do lançamento, de quem ficam o código e os acessos, como o prazo é dividido, que garantia existe e como as mudanças são cobradas. Só então a diferença de preço faz sentido, e muitas vezes ela se explica sozinha.
O foco aqui é o documento da proposta. Para a escolha da empresa em si, com portfólio e referências, veja como escolher uma empresa de desenvolvimento de software.
Por que os orçamentos para o mesmo projeto variam tanto?
Porque quase nunca é o mesmo projeto. Cada fornecedor interpreta o pedido e orça o que entendeu. As diferenças costumam estar em:
- Leitura do escopo: “loja com integração” pode ser uma conexão simples com o meio de pagamento ou a sincronização completa de estoque, preços e pedidos com o seu sistema de gestão.
- Caminho técnico: adaptar um modelo pronto, montar sobre uma plataforma com mensalidade ou desenvolver sob medida são trabalhos de tamanhos diferentes, com custos e limites diferentes ao longo do tempo.
- Equipe: uma proposta inclui design, programação, testes e alguém coordenando; outra cobre só a programação.
- O que vem junto: textos, configuração para buscadores, treinamento, migração de dados do sistema antigo, hospedagem.
- Margem para o desconhecido: diante de um pedido vago, há quem cobre mais para se proteger e há quem cote baixo e recupere a diferença depois, em cobranças extras.
Preço diferente não quer dizer que alguém está errado. Quer dizer que você precisa descobrir o que cada um está oferecendo.
Quais são os erros mais comuns ao comparar propostas?
1. Comparar escopos vagos ou diferentes
“Site institucional completo” ou “sistema de gestão personalizado” não dizem o que você vai receber. Se uma proposta lista as páginas e outra fala em “páginas necessárias”, você não está comparando coisas iguais.
O que conferir: a lista de páginas ou telas; as funcionalidades, como área do cliente, painel administrativo e relatórios; as integrações, como pagamento, frete e sistema de gestão; quem produz textos e imagens; quantas rodadas de ajuste no layout estão incluídas; e se o design é exclusivo ou adaptado de um modelo. O caminho mais simples é montar a sua própria lista de requisitos e pedir que todos orcem em cima dela. Se for um site institucional, este checklist do que um site precisa ter ajuda a montar a lista.
2. Deixar de fora os custos recorrentes
O valor do projeto paga a construção. Manter tudo no ar tem custos à parte, muitos deles mensais ou anuais, e uma proposta pode parecer mais barata só porque não fala deles.
O que conferir: hospedagem ou servidor; renovação do domínio; certificado de segurança, se não vier com a hospedagem; licenças de temas, plugins e softwares de terceiros; mensalidade de plataforma, que em alguns casos inclui porcentagem sobre as vendas; taxas do meio de pagamento; no caso de app, as contas de desenvolvedor nas lojas da Apple e do Google, que cobram taxas próprias; serviços pagos que o sistema usa, como envio de e-mails e mensagens; e manutenção. Para cada item, pergunte se está no valor, quem paga e em nome de quem fica a conta.
3. Não saber de quem serão o código, o domínio e os acessos
É o erro que aparece mais tarde e dá mais trabalho para desfazer. Se o domínio está no nome do fornecedor, a hospedagem está na conta dele e você não tem acesso ao código, trocar de empresa no futuro vira uma negociação.
O que conferir: se o contrato diz que o código feito sob medida passa a ser seu e a partir de quando (ligar a transferência à quitação é razoável, desde que esteja escrito); se o domínio será registrado em nome da sua empresa; se hospedagem, repositório do código, painel e ferramentas de análise ficam em contas suas ou com acesso de administrador para você; e, no caso de aplicativo, se ele será publicado na conta de desenvolvedor da sua empresa. Se o projeto roda sobre uma plataforma alugada, a plataforma não será sua. Nesse caso, confira se dá para exportar produtos, clientes e pedidos se um dia você quiser mudar.
4. Aceitar um prazo sem etapas nem entregas parciais
Uma data final sozinha não mostra como o projeto vai andar. Sem etapas, você só descobre que algo atrasou ou saiu diferente do esperado quando já é tarde para corrigir sem custo.
O que conferir: quais são as etapas (levantamento, layout, desenvolvimento, testes, lançamento); o que você vai ver e aprovar em cada uma; se o prazo conta dias úteis ou corridos; e o que depende de você, como envio de textos, aprovações e acessos. Em sistemas maiores, prefira propostas que entregam por módulos, com partes funcionando em intervalos curtos, a uma entrega única no fim. Pagamentos ligados às entregas também ajudam a manter o ritmo combinado.
5. Não ter nada definido para depois do lançamento
É normal surgirem ajustes depois que o projeto vai ao ar: um erro que só aparece com o uso real, uma tela que não se ajusta bem a determinado celular. Se a proposta termina no dia do lançamento, cada correção pode virar um novo orçamento.
O que conferir: se há garantia, por quanto tempo e o que ela cobre (corrigir erro é diferente de criar funcionalidade nova); como funciona o suporte, por qual canal e em quanto tempo há resposta; se existe plano de manutenção, o que ele inclui (atualizações de segurança, cópias de segurança, pequenos ajustes, evolução) e como é cobrado; e se você recebe treinamento para usar o painel.
6. Não entender como mudanças fora do escopo serão cobradas
Mudar de ideia no meio do projeto é normal. Você vê o layout e percebe que falta uma seção, ou a equipe comercial pede um relatório que ninguém tinha previsto. O problema é quando a proposta não diz como isso será tratado.
O que conferir: como um pedido extra é orçado (por hora, por pacote ou em nova proposta); se você aprova o valor antes de o trabalho começar; se a mudança altera o prazo; e se tudo fica registrado por escrito. Escopo vago somado a regra de mudança indefinida é a combinação que costuma transformar uma proposta barata em um projeto caro.
Que perguntas mandar a cada fornecedor antes de decidir?
Mande as mesmas perguntas, por escrito, para todos. Além de facilitar a comparação, as respostas mostram quem explica com clareza.
- Vocês podem listar as páginas, telas, funcionalidades e integrações incluídas no valor?
- O que não está incluído e eu vou precisar contratar à parte?
- Que custos mensais ou anuais terei depois do lançamento, e em nome de quem fica cada conta?
- Ao fim do projeto, o código, o domínio e os acessos serão meus? Isso está no contrato?
- Quais são as etapas, o que vou ver em cada uma e quando?
- O que vocês precisam de mim, e até quando, para o prazo valer?
- Existe garantia depois do lançamento? Por quanto tempo e o que ela cobre?
- Como funcionam o suporte e a manutenção depois da garantia?
- Se eu pedir algo fora do escopo, como isso é orçado e aprovado?
O que for combinado em reunião precisa aparecer na proposta final. Se não está escrito, não conte com isso.
Como decidir depois de comparar?
Coloque as respostas lado a lado, item por item. A proposta mais barata pode ser a certa se entrega o que você precisa e responde bem a tudo; a mais cara pode se justificar por algo que as outras deixaram de fora. O sinal de alerta é a proposta que não consegue responder: falta de clareza no orçamento tende a se repetir durante o projeto.
Sites, lojas virtuais, aplicativos e sistemas sob medida são o tipo de projeto que fazemos na OMS. Se quiser incluir a gente na comparação, mande o mesmo roteiro e conheça antes como trabalhamos.
