Quanto custa terceirizar desenvolvimento web? 8 variáveis que mudam a estimativa

Terceirizar desenvolvimento web não tem um preço único porque a contratação não compra apenas horas de código. Ela combina escopo, regras de negócio, integrações, conteúdo, qualidade, operação e risco. Duas demandas com o mesmo número de páginas podem exigir esforços muito diferentes quando uma delas envolve CMS, migração, autenticação, dados sensíveis ou uma janela curta de publicação.

A forma mais segura de chegar a uma estimativa útil é transformar a demanda em uma base técnica comparável. A matriz deste guia organiza oito variáveis em três níveis. Ela não calcula preço e não substitui discovery: serve para identificar onde a incerteza está, quais perguntas ainda precisam ser respondidas e qual formato de contratação tende a ser mais coerente.

Resposta direta: classifique as oito variáveis de 1 a 3, some os níveis e use o resultado para decidir se a demanda comporta uma estimativa direta, precisa de discovery ou deve avançar por etapas.

Se você ainda está definindo o modelo de parceria, comece pelo guia sobre outsourcing de desenvolvimento. Aqui, o foco é estritamente a construção da estimativa.

Por que tabelas genéricas de preço costumam falhar

Uma tabela por “site simples”, “site médio” ou “portal complexo” esconde decisões que afetam diretamente o trabalho. O mesmo rótulo pode representar um conjunto pequeno de templates editoriais ou uma operação com múltiplos perfis, integrações, migração e requisitos rigorosos de segurança.

Estimativas confiáveis precisam declarar finalidade, escopo, premissas, decomposição do trabalho, método e riscos. Esse princípio também aparece no guia de estimativas de custo do U.S. Government Accountability Office, que recomenda estabelecer uma base técnica, estruturar o trabalho, documentar premissas, analisar riscos e atualizar a estimativa com dados reais. O guia é voltado a programas de maior porte, mas esses fundamentos são úteis para não transformar uma estimativa web em um número sem contexto.

Por isso, a pergunta produtiva não é apenas “quanto custa?”. É “o que está incluído, o que ainda é incerto e qual nível de responsabilidade será assumido pelo parceiro?”.

A matriz Hit de oito variáveis

Classifique cada variável como 1, 2 ou 3. O resultado não gera valor monetário. Ele indica a maturidade do briefing e o tipo de processo necessário antes de assumir um compromisso de escopo, capacidade ou prazo.

Como usar a matriz

1. Classifique cada variável de 1 a 3 com base nas evidências disponíveis.
2. Some os oito níveis.
3. Use a faixa para decidir entre estimativa direta, discovery ou execução progressiva.

Como interpretar o resultado

• 8 a 12 pontos: a demanda tende a estar madura para uma estimativa mais direta. Ainda é necessário validar premissas e critérios de aceite.
• 13 a 18 pontos: há variáveis que merecem discovery curto, protótipo técnico ou decomposição adicional antes de fechar escopo e prazo.
• 19 a 24 pontos: uma estimativa única tende a esconder risco. Considere fase de diagnóstico, entregas progressivas ou um modelo com governança explícita para evolução do escopo.

Essa escala é um instrumento de triagem, não uma fórmula universal. Uma única variável crítica pode exigir tratamento especial mesmo quando a soma é baixa. Uma integração financeira mal documentada, por exemplo, não deixa de ser crítica porque o restante do projeto é simples.

1. Escopo e requisitos

O primeiro fator é a clareza sobre o que será entregue e aceito. Briefings com objetivo bem descrito, responsáveis, jornadas, conteúdo, restrições e critérios de aceite reduzem o volume de hipóteses que a estimativa precisa incorporar.

Escopo claro não significa detalhar antecipadamente cada decisão visual. Significa tornar explícito o que orienta a entrega: público, resultado esperado, funcionalidades, integrações, limites, responsabilidades e forma de validação.

Quando isso ainda não existe, o orçamento precisa separar descoberta e execução. Tentar compensar falta de informação com uma margem arbitrária produz uma proposta difícil de comparar e ainda mais difícil de governar.

2. Templates e componentes

Contar páginas raramente descreve o esforço real. Um portal com cem páginas baseadas em quatro templates pode ser mais previsível do que um site com vinte páginas em que cada uma introduz uma estrutura exclusiva.

A estimativa deve separar:

• templates de página;
• componentes reutilizáveis;
• variações e estados;
• comportamento responsivo;
• regras de composição no CMS;
• exceções aprovadas.

Essa decomposição permite discutir design, front-end, configuração editorial e QA como partes relacionadas, mas distintas.

3. Regras e funcionalidades

Uma página institucional predominantemente editorial tem um perfil diferente de uma área com autenticação, permissões, busca avançada, formulários condicionais ou transações.

Para cada funcionalidade, pergunte:

• quais entradas recebe;
• quais regras aplica;
• quais estados e erros precisa tratar;
• quem pode acessar ou alterar dados;
• como o resultado será validado;
• o que acontece quando uma dependência falha.

Funcionalidades que parecem pequenas na interface podem concentrar regras importantes no back-end. A estimativa deve refletir o comportamento completo, não apenas o elemento visual.

4. Integrações e dados

Integrações afetam desenvolvimento, testes, coordenação e suporte. Uma API documentada, estável e disponível em homologação é diferente de um sistema legado com regras conhecidas apenas durante a execução.

Antes de estimar, confirme contratos de API, autenticação, limites, responsáveis, massa de testes, tratamento de erros, observabilidade e disponibilidade dos ambientes. Em migrações, acrescente qualidade dos dados, transformação, deduplicação, validação e estratégia de retorno.

Sinal de alerta: se os contratos de API, a massa de testes ou o responsável técnico ainda não estão definidos, trate a integração como uma hipótese a validar, não como uma premissa fechada.

Quando a documentação não existe, uma prova técnica pequena pode valer mais do que detalhar uma proposta baseada em suposições.

5. Conteúdo e operação editorial

Conteúdo não entra automaticamente no projeto. É preciso decidir quem escreve, revisa, aprova, cadastra, migra e mantém cada tipo de informação.

Um CMS pode exigir modelagem de campos, taxonomias, permissões, preview, componentes, fluxos de aprovação, treinamento e migração. Esses itens devem aparecer na decomposição. A página de CMS e plataformas apresenta os contextos técnicos em que essa operação costuma existir.

Também é importante verificar se o conteúdo estará pronto no momento esperado. Atrasos editoriais podem bloquear QA, tradução e publicação mesmo quando o desenvolvimento terminou.

6. Qualidade, acessibilidade, segurança e performance

Requisitos não funcionais não devem aparecer apenas no fim. Eles alteram arquitetura, critérios de aceite, testes e especialistas envolvidos.

A WCAG 2.2 define critérios testáveis e independentes de tecnologia para acessibilidade de conteúdo web. O OWASP ASVS oferece uma base para testar controles técnicos e especificar requisitos de desenvolvimento seguro. Usar referências como essas não significa prometer conformidade por padrão: significa transformar expectativas vagas em critérios verificáveis.

Defina o que será testado, em quais dispositivos, navegadores, níveis de acesso e condições de carga. A área de QA e validação ajuda a visualizar o papel desse trabalho na entrega.

7. Ambientes e publicação

Ambientes, acessos e processo de publicação podem mudar significativamente a estimativa. O parceiro terá autonomia para configurar o projeto? Dependerá de outra equipe para cada deploy? Existe homologação comparável à produção? Há backup e rollback testados?

Inclua provisionamento, variáveis, domínios, certificados, cache, observabilidade, janela de publicação, validação pós-go-live e suporte inicial. Quando vários fornecedores participam, registre quem executa e quem aprova cada etapa.

Pergunta de validação: quem executa, quem aprova e quem confirma o rollback se a publicação precisar ser revertida?

Publicação não é um detalhe administrativo: é parte da entrega técnica.

8. Governança, composição da equipe e prazo

A mesma demanda muda quando precisa ser realizada por uma pessoa, por um squad completo ou por especialistas acionados em etapas. Gestão, QA, arquitetura e coordenação não são sobreposição improdutiva quando o projeto exige decisões e validação distribuídas.

Prazos também alteram o desenho. Paralelizar atividades pode exigir mais coordenação, antecipar decisões e reduzir a capacidade de absorver mudanças. Antes de encurtar o calendário, confirme dependências e disponibilidade dos aprovadores.

Se a dúvida principal for o formato de contratação, compare squad dedicado, alocação e projeto fechado.

Três cenários para aplicar a matriz

Cenário A: site institucional com base definida

O layout utiliza poucos templates, o conteúdo está aprovado, não há integrações críticas e os responsáveis estão disponíveis. A matriz tende a concentrar níveis 1. O trabalho pode seguir para decomposição e estimativa com poucas premissas abertas.

Cenário B: portal com CMS e integrações conhecidas

Há vários tipos de conteúdo, perfis editoriais, busca, integração documentada e requisitos específicos de QA. A maior parte das variáveis fica no nível 2. Um discovery curto e uma arquitetura de conteúdo reduzem o risco antes de comprometer escopo e prazo.

Cenário C: plataforma com dependências ainda incertas

O projeto envolve sistemas legados, regras em descoberta, dados sensíveis, prazo rígido e múltiplos responsáveis. Algumas variáveis chegam ao nível 3. O caminho mais responsável é separar diagnóstico, validações técnicas e execução progressiva, em vez de converter incerteza em um preço fechado sem base.

O que enviar para receber uma estimativa mais útil

Antes de solicitar propostas, reúna:

1. objetivo e público da solução;
2. escopo conhecido e itens fora do escopo;
3. mapa de páginas, templates ou jornadas;
4. funcionalidades e regras principais;
5. integrações, acessos e documentação disponível;
6. volume e estado do conteúdo;
7. requisitos de QA, segurança, acessibilidade e performance;
8. ambientes, publicação e responsáveis;
9. prazo, marcos e dependências;
10. critérios de aceite e premissas ainda abertas.

Se parte dessas informações não existe, isso não impede a conversa. Apenas indica que a primeira estimativa deve incluir uma etapa de descoberta ou trabalhar com cenários explícitos.

Como comparar propostas sem olhar apenas o total

Uma proposta responsável deve permitir identificar:

• o que foi considerado;
• quais premissas sustentam a estimativa;
• o que está excluído;
• como mudanças serão tratadas;
• quem responde por gestão, QA e publicação;
• quais riscos permanecem com o contratante;
• como o progresso e o aceite serão demonstrados.

Dois totais só são comparáveis quando cobrem responsabilidades semelhantes. Uma proposta aparentemente menor pode apenas deslocar atividades para a equipe interna ou deixá-las fora do documento. Para transformar essa comparação em uma decisão operacional, conheça também os formatos de parceria que podem organizar a execução.

Limitações da matriz

A matriz não substitui análise técnica, discovery, proposta comercial ou planejamento detalhado. Ela também não determina qual fornecedor contratar e não representa preços, produtividade ou compromissos da Hit.

Seu valor está em tornar a conversa verificável. Quanto mais claro estiver o motivo de cada nível, mais fácil será decidir se a demanda pode ser estimada agora, se precisa de descoberta ou se deve evoluir por etapas.

Próximo passo

Se você precisa estruturar uma demanda antes de comparar propostas, use a matriz para registrar os oito níveis e as evidências disponíveis. A Hit pode apoiar a avaliação técnica e a estimativa inicial com o contexto já organizado, sem transformar incertezas em promessas genéricas.

Fontes consultadas

• U.S. Government Accountability Office. Cost Estimating and Assessment Guide: Best Practices for Developing and Managing Program Costs. Consultado em 13 ago. 2026. https://www.gao.gov/products/gao-20-195g
• W3C. Web Content Accessibility Guidelines (WCAG) 2.2. Consultado em 13 ago. 2026. https://www.w3.org/TR/WCAG22/
• OWASP Foundation. Application Security Verification Standard (ASVS). Consultado em 13 ago. 2026. https://owasp.org/www-project-application-security-verification-standard/