Orçamento de site superfaturado: como identificar os sinais

Identificar um orçamento de site superfaturado é difícil para quem não tem background técnico. O valor de um site depende de tantas variáveis que comparar duas propostas lado a lado raramente é uma comparação justa. A pergunta certa não é “isso está caro”, é “o que exatamente está sendo cobrado, e isso corresponde ao que realmente será entregue?”

Recebo com frequência clientes que já tinham outro orçamento em mãos e queriam uma segunda opinião. Na maioria das vezes, o problema não era o valor em si: era a falta de clareza sobre o que aquele valor cobria, e o que ficaria de fora.

Este guia existe para dar a você os critérios técnicos e contratuais que um gestor sem formação em TI normalmente não tem. Com eles, você consegue comparar propostas de forma justa, identificar exclusões estratégicas e proteger a empresa antes de assinar.

Por que comparar orçamentos de site é enganoso

Dois orçamentos com valores parecidos podem estar cobrindo escopos completamente diferentes. Um pode incluir apenas o desenvolvimento, enquanto o outro já contempla hospedagem no primeiro ano, treinamento da equipe e suporte pós-lançamento. O oposto também é comum: dois valores muito diferentes, com o mais barato excluindo funcionalidades essenciais que só aparecem depois, como custo adicional.

Esse é um padrão clássico de superfaturamento disfarçado: o preço inicial parece atrativo, mas itens críticos como suporte fora do horário comercial, segurança avançada e manutenção contínua foram simplesmente omitidos da proposta. Eles reaparecem depois como “pedido de alteração” ou cobranças avulsas, corroendo o orçamento que parecia controlado.

O problema dos custos ocultos em soluções desconectadas

Existe outro risco que raramente aparece em orçamentos: o custo de longo prazo de ferramentas e sistemas mal integrados. Quando um fornecedor utiliza soluções isoladas — cada função numa plataforma diferente, sem integração nativa — o custo de propriedade total (TCO) pode superar em muito o que foi orçado inicialmente.

A troca constante de contexto entre ferramentas diferentes pode consumir até 40% do tempo produtivo da equipe que precisará operar o sistema no dia a dia. Isso não aparece na proposta como um custo direto, mas é pago mês a mês em perda de produtividade. Plataformas construídas por aquisições de múltiplos sistemas tendem a ter bases de código díspares, tornando integrações futuras progressivamente mais complexas e caras.

Antes de julgar se um preço está alto ou baixo, é preciso entender exatamente o que está incluído em cada proposta, item por item. Comparar apenas o número final é garantia de comparar coisas incomparáveis.

Sinais reais de orçamento de site superfaturado

Existem padrões que sinalizam cobrança desproporcional ao trabalho envolvido. Nenhum deles, isolado, é prova definitiva de problema. Mas a combinação de dois ou mais deles num mesmo orçamento merece atenção redobrada.

Valor genérico sem detalhamento de escopo

Se o orçamento não especifica quantas páginas, quais funcionalidades e qual nível de customização está incluído, é impossível avaliar se o valor faz sentido. Propostas sérias descrevem o que será entregue com precisão suficiente para gerar um contrato claro.

Um escopo bem definido é o ponto de partida de qualquer proposta séria. Sem ele, tanto o fornecedor quanto o cliente ficam expostos: o fornecedor pode cobrar por escopo ampliado mais tarde, e o cliente não tem base para contestar. Peça sempre uma proposta com escopo detalhado antes de qualquer aprovação.

Cobrança por funcionalidades padrão como se fossem customizadas

Um formulário de contato básico, uma galeria de imagens ou uma página de blog são recursos nativos em praticamente qualquer CMS moderno — WordPress, por exemplo, já inclui isso sem nenhuma linha de código adicional. Se esses itens aparecem como “desenvolvimento customizado” com valor individual elevado, vale questionar com detalhe o que exatamente está sendo cobrado e por quê aquela abordagem foi escolhida em vez de uma solução nativa.

Isso não significa que customização real não possa custar mais. Significa que você tem o direito de entender a justificativa técnica antes de aceitar.

Ausência de SLA por escrito

Promessas verbais de suporte não têm validade contratual. Um SLA (Service Level Agreement) real é um compromisso formalizado com métricas específicas: tempo máximo de resposta a chamados, tempo máximo de resolução por tipo de problema e disponibilidade garantida do sistema. E ele deve incluir consequências claras em caso de descumprimento.

Segundo padrões utilizados em grandes contratações corporativas (referenciados pelo GoodFirms), a ausência de SLA por escrito é um dos sinais críticos de alerta mais consistentes em avaliação de fornecedores de tecnologia. Um fornecedor que não aceita formalizar suas promessas em contrato está implicitamente comunicando que não confia na própria capacidade de cumpri-las.

Plano de onboarding vago ou inexistente

O processo de início de um projeto de desenvolvimento ou manutenção importa tanto quanto a entrega final. Um fornecedor sem um plano documentado de avaliação do ambiente atual, levantamento de requisitos e migração tende a iniciar o projeto sem visibilidade real do que existe, gerando retrabalho caro depois.

Pergunte diretamente: “Como é o processo de início do projeto? Existe um checklist de avaliação do ambiente atual?” A qualidade da resposta diz muito sobre a maturidade do fornecedor.

Ausência de menção a conformidade e segurança

Um orçamento que não menciona requisitos de segurança específicos ou conformidade com legislações aplicáveis (como a LGPD no Brasil) está excluindo custos que serão necessários mais cedo ou mais tarde. Segurança não é opcional — é parte do custo real de qualquer sistema que processe dados de usuários.

O padrão OWASP de práticas de codificação segura define um conjunto mínimo de requisitos que qualquer fornecedor sério deveria ser capaz de mencionar: validação de entrada no lado do servidor, codificação de saída para sistemas de destino, gerenciamento centralizado de autenticação e sessões com hashes criptográficos adequados, e uso de TLS para conexões que exijam autenticação. Se nada disso aparece na proposta, vale perguntar explicitamente como a segurança está sendo tratada.

Ausência de justificativa técnica para a complexidade

Um profissional sério consegue explicar, em linguagem acessível, por que determinada funcionalidade leva mais tempo e mais custo. Não é necessário entender os detalhes técnicos, mas você deve ser capaz de entender a lógica: “essa integração exige comunicação com uma API externa que não tem documentação pública, então precisamos de tempo adicional para engenharia reversa” é uma justificativa compreensível. “É complexo” sem explicação não é.

Preço significativamente abaixo da média sem justificativa de escopo

Um orçamento muito mais barato que os demais geralmente não indica maior eficiência: indica menor escopo. Itens que foram omitidos para baixar o preço inicial reaparecem depois como “fora do escopo original”. Os mais comuns são: suporte pós-lançamento, configuração de segurança, adequação a requisitos de conformidade, treinamento da equipe e otimização de performance.

Comparar propostas pelo preço antes de comparar pelo escopo é o erro mais comum e mais caro nesse processo.

Pressão para fechar rápido sem tempo de avaliar

Um orçamento sério permite tempo para você comparar propostas, questionar itens, buscar uma segunda opinião e consultar juridicamente se necessário. Pressão para decidir imediatamente, com prazo artificial de validade de 24 ou 48 horas, costuma ser uma técnica comercial que sinaliza falta de confiança no próprio valor cobrado.

O que um orçamento técnico deve incluir: checklist completo de avaliação

Use este checklist antes de aprovar qualquer proposta de desenvolvimento ou manutenção de site. Cada item representa uma proteção real contra custos futuros não previstos.

#	Critério	O que verificar
1	Escopo detalhado	A proposta lista páginas, funcionalidades e nível de customização?
2	Exclusões explícitas	O que não está incluso está claramente listado?
3	SLA por escrito	Há tempo de resposta garantido com penalidades definidas?
4	Plano de onboarding	Existe processo documentado de avaliação do ambiente e migração?
5	Direitos de IP	O contrato define entregáveis como propriedade integral do cliente?
6	IP de terceiros	O fornecedor lista software e licenças de terceiros integrados?
7	Segurança por design	A proposta menciona conformidade com OWASP ou LGPD?
8	Métricas de performance	Há critérios técnicos de aceitação definidos?
9	Suporte pós-lançamento	Prazo e escopo do suporte após entrega estão claros?
10	Direito de auditoria	O contrato permite auditoria de registros e código-fonte?

Por que o direito de auditoria importa

Contratos robustos com fornecedores de tecnologia devem prever o direito de auditoria de registros, sistemas e código-fonte por um período relevante após a entrega, para verificar conformidade com impostos, segurança e privacidade. Esse é o padrão em contratos corporativos de empresas como Microsoft, e sua ausência em contratos menores é uma lacuna que pode custar caro em caso de disputas futuras.

O que realmente justifica variação de preço justo de site

Nem toda diferença de valor é sinal de problema. Entender o que legitimamente justifica variação de preço é tão importante quanto saber identificar superfaturamento.

Fatores que aumentam o custo de forma justificada

Nível de customização visual e funcional. Um layout genérico baseado em template custa menos do que um design construído a partir da identidade visual da empresa, com componentes exclusivos e experiência de usuário pensada para o público específico. A diferença não é arbitrária: é horas de trabalho especializado de design e desenvolvimento.

Complexidade de integrações. Conectar o site a um sistema de pagamento, a um CRM, a uma API externa ou a um ERP interno exige mapeamento de requisitos, desenvolvimento de conectores, tratamento de erros e testes de integração. Cada integração de sistemas tem seu próprio conjunto de variáveis, e fornecedores experientes sabem que subestimar esse trabalho é um erro frequente e caro.

Experiência e portfólio do profissional. Um desenvolvedor freelancer com histórico comprovado de entregas bem-sucedidas em projetos parecidos com o seu cobra mais porque representa menor risco para quem contrata. Não é superfaturamento: é o custo do risco transferido para o fornecedor. Um profissional iniciante pode custar menos na proposta e muito mais no resultado final.

Qualidade e metodologia de desenvolvimento. Fornecedores que utilizam controle de versão adequado com Git, ambientes separados de staging e produção, CI/CD e revisão de código cobram mais porque entregam mais estabilidade e menos risco de regressões. O custo da qualidade aparece no orçamento; o custo da falta de qualidade aparece depois.

O que está incluído além do desenvolvimento. SEO técnico inicial, configuração de monitoramento, backup automatizado, suporte pós-lançamento e treinamento da equipe agregam custo na proposta, mas eliminam custos não planejados depois.

Modelos de precificação e como eles afetam a comparação

Propostas de desenvolvimento e manutenção podem seguir modelos diferentes de precificação, e isso afeta diretamente como você as compara:

Por projeto (fixed price): valor fechado para um escopo definido. Vantagem: previsibilidade. Risco: escopo mal definido gera disputas sobre o que está ou não incluído.
Por hora (time & materials): cobrado conforme o tempo trabalhado. Vantagem: flexível para projetos com requisitos em evolução. Risco: custo final imprevisível sem gestão ativa.
Por usuário ou por dispositivo: modelo comum em manutenção gerenciada. Previsível, mas pode encarecer conforme o crescimento da empresa.
Tarifa fixa em camadas (tiered flat-rate): valor mensal fixo por nível de serviço. Oferece maior previsibilidade orçamentária e é o modelo mais transparente para comparação entre fornecedores.

Quando os orçamentos que você recebeu usam modelos diferentes, compare o custo total esperado para 12 meses, não apenas o valor inicial.

Qualidade técnica: o que está por trás do código entregue

Superfaturamento não é apenas sobre preço. Existe o problema inverso, igualmente grave: pagar um valor razoável e receber código de baixa qualidade que gera dívida técnica crescente.

A rubrica de qualidade de código

Segundo pesquisa publicada pelo GitHub Blog, um código de qualidade pode ser avaliado objetivamente por cinco critérios:

Critério	O que significa	Por que importa
Legibilidade	Nomenclatura clara, padrões consistentes	Facilita manutenção por qualquer desenvolvedor
Reusabilidade	Componentes reutilizáveis, sem duplicação desnecessária	Reduz custo de novas funcionalidades
Concisão	Princípio DRY (Don’t Repeat Yourself)	Menos código para manter e testar
Manutenibilidade	Funcionalidade clara, poucas dependências externas	Facilita evoluções e correções futuras
Resiliência	Tratamento antecipado de erros e falhas	Reduz downtime e comportamentos inesperados

Código que não atende a esses critérios não é apenas esteticamente ruim: ele acumula dívida técnica. Cada nova funcionalidade num código mal estruturado custa mais para implementar, cada bug leva mais tempo para localizar e cada atualização tem maior risco de quebrar algo que funcionava.

O impacto financeiro da dívida técnica

A dívida técnica é invisível no curto prazo. O site funciona, o cliente aceita a entrega, e o contrato é encerrado. O custo real aparece entre seis e dezoito meses depois, quando pequenas alterações se tornam projetos complexos, quando atualizações de segurança quebram funcionalidades, ou quando nenhum desenvolvedor novo consegue entender o que foi entregue sem horas de análise.

Solicitar acesso ao repositório durante o projeto, mesmo que você não saiba ler código, é uma forma simples de sinalizar ao fornecedor que haverá acompanhamento. Fornecedores que recusam ou dificultam esse acesso estão comunicando algo importante.

IA e qualidade de código: o que isso significa para o orçamento

O uso de assistentes de IA como o GitHub Copilot demonstrou, em pesquisas controladas, aumentar a confiança dos desenvolvedores na qualidade do código em até 85% e tornar revisões de código até 15% mais rápidas. Fornecedores que utilizam essas ferramentas ativamente podem justificar maior eficiência no desenvolvimento sem reduzir qualidade, o que pode influenciar positivamente a relação custo-benefício da proposta.

Isso não significa que um orçamento mais barato justificado por “uso de IA” é automaticamente bom. O que importa é o resultado: código que passa nos critérios de qualidade acima e um processo de entrega transparente.

Performance como critério de aceitação contratual

Um orçamento técnico sério pode e deve incluir critérios mensuráveis de performance como condição formal de aceitação da entrega. Isso transforma a performance de promessa comercial em obrigação contratual.

Core Web Vitals: os parâmetros do Google

Os Core Web Vitals definidos pelo Google são o padrão de mercado para medir a experiência real do usuário. São três métricas principais, com valores de referência claros e objetivos:

Métrica	O que mede	Meta “Bom”	Meta máxima
LCP (Largest Contentful Paint)	Velocidade de carregamento do maior elemento visível	Abaixo de 2,5s	Abaixo de 4s
INP (Interaction to Next Paint)	Resposta a interações do usuário	Abaixo de 200ms	Abaixo de 500ms
CLS (Cumulative Layout Shift)	Estabilidade visual da página	Abaixo de 0,1	Abaixo de 0,25

Segundo a documentação oficial do web.dev, essas métricas devem ser atingidas no percentil 75 dos acessos para serem consideradas satisfatórias, ou seja, 75% dos usuários reais precisam ter essa experiência, não apenas casos ideais de laboratório.

Por que performance importa além da experiência do usuário

Performance afeta diretamente o SEO do site. O Google utiliza os Core Web Vitals como sinal de ranqueamento, o que significa que um site lento entregue por um fornecedor pode custar posições orgânicas. Um site que demora mais de 4 segundos para carregar perde uma parcela significativa dos visitantes antes mesmo de mostrar o conteúdo.

Se o orçamento não menciona metas de performance, inclua você mesmo como critério de aceite: exija que as métricas acima sejam atingidas na entrega, verificáveis por ferramentas públicas como o Google PageSpeed Insights.

Performance e conversão: o impacto financeiro

Sites mais rápidos convertem mais. Essa relação é documentada e consistente: cada segundo a mais de carregamento reduz a taxa de conversão. Para um e-commerce ou site com formulários de captação, a performance não é apenas qualidade técnica; é receita direta. Um site que converte 2% dos visitantes e passa a converter 2,4% após otimização de performance representa 20% a mais de resultado sem aumento de tráfego.

Consulte também o guia sobre otimização de sites para entender quais fatores de performance têm maior impacto em conversão.

Quanto custa um site institucional: por que não existe resposta única

Perguntar quanto custa um site institucional sem contexto é como perguntar quanto custa um carro. A resposta depende inteiramente de variáveis que nenhum número genérico consegue capturar.

Os fatores que determinam o custo real

Volume e complexidade de páginas. Um site de cinco páginas estáticas tem custo muito diferente de um site com dezenas de páginas, blog com categorias, área restrita para clientes ou múltiplos idiomas.

Funcionalidades e integrações. Formulários simples são uma coisa; automação de onboarding de clientes, integração com CRM, sistema de agendamento ou área de membros são outra categoria completamente diferente.

Decisão de tecnologia. Um site em WordPress com um tema existente tem custo diferente de um site em Next.js com headless CMS. Cada escolha tem justificativa técnica e impacto no orçamento. Se o fornecedor não explica por que escolheu determinada tecnologia para o seu projeto, pergunte.

Custo total de propriedade (TCO). O orçamento inicial raramente representa o custo real. Hospedagem, domínio, SSL, CDN, backups automatizados e manutenção contínua também entram no custo de operar o site mês a mês, mesmo que não apareçam na proposta inicial.

Qualquer proposta séria começa com perguntas sobre o que sua empresa realmente precisa, não com um valor fechado antes de entender o escopo.

O que não entra no orçamento mas deveria

O custo de não ter manutenção é frequentemente invisível até se tornar urgente. Um site WordPress sem manutenção regular acumula vulnerabilidades, plugins desatualizados e incompatibilidades que eventualmente resultam em indisponibilidade, invasões ou perda de dados. Entenda o custo sem manutenção neste artigo.

O custo de trocar de fornecedor também costuma ser subestimado. Migrar um site, recuperar acesso a sistemas, transferir domínio e reconfigurar integrações leva tempo e dinheiro que não estavam previstos. Esse é o “custo de troca” (switching cost) que faz empresas tolerarem fornecedores ruins por mais tempo do que deveriam.

Segurança no orçamento: o que um fornecedor sério deve contemplar

Segurança é um dos itens mais frequentemente omitidos em orçamentos de baixo custo. E é exatamente por isso que merece atenção explícita antes de qualquer assinatura.

O que o padrão OWASP define como mínimo

O OWASP Secure Coding Practices Checklist é a referência técnica mais reconhecida para práticas de segurança em desenvolvimento web. Um orçamento que contemple segurança por design deve incluir, no mínimo:

Validação de entrada no lado do servidor: nunca confiar em dados enviados pelo usuário sem validação, independentemente de validação client-side.
Codificação de saída para sistemas de destino: proteger contra injeção de SQL, XSS e outros ataques baseados em dados maliciosos.
Gerenciamento centralizado de autenticação e sessões: usando hashes criptográficos adequados (com salt) para armazenamento de senhas.
TLS em todas as conexões que exijam autenticação: sem exceções.

Se o fornecedor não sabe o que é OWASP ou não consegue explicar como trata esses pontos, o projeto tem um risco de segurança real que não está precificado na proposta.

Segurança e LGPD: o custo da conformidade omitida

A Lei Geral de Proteção de Dados (LGPD) impõe obrigações reais a qualquer sistema que processe dados pessoais de usuários brasileiros. Um site com formulário de contato, área de cadastro ou qualquer forma de coleta de dados está sujeito a essa legislação.

Um orçamento que não menciona conformidade com LGPD está omitindo custos reais: configuração adequada de coleta de consentimento, política de privacidade integrada ao sistema, controles de acesso e gestão de dados. Esses itens podem ser adicionados depois, mas costumam custar mais quando feitos por refatoração do que quando planejados desde o início.

Propriedade intelectual: quem é dono do código entregue

Esse é um ponto que muitos contratos de desenvolvimento ignoram, e que pode gerar disputas sérias no futuro.

Work made for hire: o que significa e por que importa

Todo código produzido sob contrato de desenvolvimento deve ser classificado juridicamente como “work made for hire”, que estabelece que o produto do trabalho pertence integralmente ao contratante. Sem essa cláusula, o desenvolvedor pode legalmente reter direitos sobre o código mesmo após ter sido pago pelo trabalho.

Além disso, o fornecedor deve listar explicitamente qualquer componente de terceiros utilizado no projeto: bibliotecas open source, plugins, templates, APIs de terceiros. Isso é necessário porque cada um desses componentes tem sua própria licença, que pode impor restrições sobre uso comercial ou redistribuição.

Contratos robustos também devem especificar quem tem direito de acesso ao repositório de código durante e após o projeto, e o que acontece com esse acesso em caso de encerramento do contrato.

O risco de ficar dependente do fornecedor

Um fornecedor que não entrega acesso ao código-fonte ao final do projeto, que não documenta adequadamente o sistema ou que utiliza ferramentas proprietárias sem alternativa, cria uma dependência que é difícil e cara de desfazer. Isso é especialmente comum em projetos de desenvolvimento de aplicativos e em integrações complexas.

Antes de assinar, pergunte: “Se eu precisar trocar de fornecedor amanhã, o que acontece com o código, com o acesso aos sistemas e com a documentação?” A resposta define se você estará contratando um parceiro ou criando uma dependência.

Como validar um orçamento antes de fechar

Com os critérios anteriores em mente, há um conjunto de verificações práticas que devem acontecer antes de qualquer assinatura.

Perguntas que você deve fazer ao fornecedor

Sobre o projeto:

Qual é exatamente o escopo? O que está e o que não está incluso?
Qual tecnologia será utilizada e por quê essa escolha para o meu projeto?
Quais são os marcos de entrega e o que acontece se algum não for cumprido?

Sobre suporte e manutenção:

O que acontece depois do lançamento? Existe período de garantia?
Qual é o processo para reportar problemas pós-entrega?
O suporte pós-hora está incluso ou é cobrado à parte?

Sobre segurança e conformidade:

Como a segurança é tratada no desenvolvimento? Qual padrão é seguido?
O projeto contempla conformidade com LGPD?
Quais bibliotecas ou sistemas de terceiros serão utilizados?

Sobre IP e acesso:

O contrato garante que o código produzido pertence ao cliente?
Terei acesso ao repositório durante e após o projeto?
Existe documentação técnica incluída na entrega?

Como comparar dois orçamentos de forma justa

Ao comparar propostas diferentes, utilize esta estrutura:

Normalize o escopo: liste o que cada proposta inclui e o que não inclui. Adicione o custo dos itens ausentes a cada proposta para chegar ao custo comparável.
Avalie o custo total de 12 meses: some desenvolvimento, manutenção, hospedagem e suporte para o período de um ano.
Avalie o risco: fornecedores sem portfólio verificável, sem SLA ou sem clareza sobre IP representam risco financeiro que tem valor.
Consulte referências: projetos anteriores com clientes reais são a evidência mais confiável de qualidade.

Se quiser saber o que perguntar antes de assinar, há um guia específico sobre o que perguntar para um desenvolvedor freelancer e outro sobre como gerenciar a entrega de um desenvolvedor freelancer.

Freelancer vs. agência: quando cada um faz sentido

Para quem está comparando um desenvolvedor freelancer com uma agência, os critérios vão além do preço:

Critério	Freelancer	Agência
Custo	Geralmente menor	Geralmente maior
Especialização técnica	Alta (especialista na área dele)	Variável (depende da equipe)
Redundância	Baixa (férias, doença, indisponibilidade)	Alta (equipe cobre ausências)
Conformidade regulatória	Depende do profissional	Estruturada em processos
Gestão do projeto	Você precisa gerenciar mais ativamente	Geralmente incluída
Flexibilidade	Alta	Menor

Nenhuma opção é universalmente melhor. O critério decisivo é o alinhamento com o que o seu projeto realmente precisa. Para projetos pontuais com escopo claro, um freelancer experiente muitas vezes entrega mais valor. Para contratos longos de manutenção com SLA, uma estrutura de agência ou provedor gerenciado tende a ser mais previsível.

Há também um guia sobre como validar um desenvolvedor sênior freelancer com critérios técnicos específicos.

O que fazer se você já assinou um contrato que parece superfaturado

Se o contrato já foi assinado e você suspeita de cobrança desproporcional ou de entrega aquém do prometido, o caminho prático segue uma ordem lógica.

Primeiro passo: revisar o que foi acordado por escrito

Antes de qualquer outra ação, leia o contrato com atenção. Identifique o que foi formalmente prometido, com quais prazos e com quais critérios de aceite. Isso ajuda a distinguir dois problemas diferentes:

Superfaturamento real: o valor cobrado é desproporcional ao escopo entregue ou acordado.
Descumprimento contratual: o valor pode ser justo, mas o fornecedor não entregou o que prometeu.

São problemas com soluções diferentes. O primeiro é uma discussão de mercado; o segundo é uma questão contratual com implicações legais.

Propriedade intelectual em contratos problemáticos

Se o contrato não define claramente a propriedade do código entregue, a situação pode ser mais complexa do que parece. Em casos de disputa, a ausência de cláusula de “work made for hire” pode dificultar a recuperação do código-fonte, especialmente se o fornecedor ainda tem acesso aos sistemas.

Documente tudo: comunicações por escrito, versões entregues, acesso a sistemas. Essa documentação é o que diferencia uma reclamação informal de uma contestação contratual fundamentada.

Inércia da mudança: o custo real de tolerar um fornecedor ruim

Muitas empresas toleram fornecedores problemáticos por medo do custo de migração. Esse é o “custo de troca” (switching cost), e ele é real: migrar um site, recuperar acessos, transferir domínios, reconfigurar integrações e treinar um novo fornecedor leva tempo e recursos.

Mas tolerar indefinidamente um fornecedor que não entrega gera custos maiores no longo prazo: site sem manutenção que acumula vulnerabilidades, oportunidades de negócio perdidas por performance ruim, e o custo emocional e gerencial de conviver com um problema sem solução.

A decisão de migrar ou manter precisa ser feita com os custos reais de ambas as opções na mesa, não com o viés do custo imediato da mudança.

Se ainda está na fase de avaliação de propostas, vale buscar uma segunda opinião técnica antes de decidir. Há também um guia específico sobre contrato com desenvolvedor freelancer com os pontos que merecem atenção antes de assinar.

Perguntas frequentes sobre orçamento de site

Por que o orçamento mais barato pode ser o mais caro?

Propostas de baixo custo frequentemente excluem serviços que são necessários desde o início: segurança, manutenção, suporte e conformidade. Esses itens não desaparecem porque foram omitidos da proposta: eles reaparecem depois como pedidos de alteração ou cobranças avulsas. O custo total de um projeto com preço inicial baixo mas com múltiplos adicionais ao longo do tempo costuma superar o de uma proposta mais completa desde o início.

O que é um SLA real e como ele me protege?

Um SLA (Service Level Agreement) real é um compromisso contratual com métricas específicas e verificáveis: tempo máximo de resposta a chamados (por exemplo, 4 horas em dias úteis), tempo máximo de resolução por tipo de problema e nível de disponibilidade garantido (por exemplo, 99,5% de uptime). E, fundamentalmente, ele deve incluir penalidades ou compensações caso as métricas não sejam cumpridas. Uma promessa verbal de “estamos sempre disponíveis” não é um SLA.

Como saber se uma funcionalidade realmente é complexa ou se é inflação de escopo?

Peça ao fornecedor uma estimativa de horas por funcionalidade e uma justificativa da complexidade em termos que você consiga entender. Pesquise em fóruns especializados ou consulte um segundo profissional sobre o tempo típico para aquele tipo de implementação. Funcionalidades comuns em projetos similares não deveriam custar como desenvolvimento do zero, a menos que haja uma razão técnica específica e explicada.

Quando faz sentido contratar um desenvolvedor fullstack em vez de uma agência?

Para projetos com escopo técnico claro, prazo definido e necessidade de flexibilidade, um desenvolvedor fullstack tende a oferecer melhor custo-benefício. Para projetos que exigem múltiplas especialidades simultâneas (design, desenvolvimento, marketing digital, suporte), uma estrutura de agência pode ser mais adequada, mesmo que o custo seja maior.

Como incluir performance no contrato?

Especifique as metas de Core Web Vitals como critério formal de aceite da entrega: LCP abaixo de 2,5 segundos, INP abaixo de 200ms e CLS abaixo de 0,1, medidos no percentil 75 dos acessos via Google PageSpeed Insights. Inclua também a obrigação de que o fornecedor corrija, sem custo adicional, qualquer métrica que não atinja os valores acordados no momento da entrega.

Se você tem um orçamento em mãos e não tem certeza se o valor faz sentido para o que está sendo proposto, posso dar uma segunda opinião técnica sem compromisso. Me conta o que está incluso na proposta que você recebeu.