Um founder me ligou em novembro de 2024, duas semanas antes do Natal, absolutamente furioso. Ele havia recebido um orçamento de uma agência web de £14.000 para um dashboard de logística sob medida. Ele tinha assinado. Seis meses depois a fatura final chegou em £61.000. Ninguém tinha mentido para ele, tecnicamente. Mas ninguém tinha dito a verdade também, porque ninguém tinha realmente feito o trabalho de estimar adequadamente antes de pegar o dinheiro dele.
Takeaway fundamental: Orçamentos de software customizado dão errado na definição de escopo, não na construção; estime a partir da complexidade do modelo de dados, integrações e ciclos de revisão, e precifique a fase de descoberta separadamente.
Estou construindo software há mais de doze anos. Seahawk sozinha já entregou mais de 12.000 sites e aplicações. E o único ponto de falha mais consistente que vejo, com founders, com freelancers, com agências orçando projetos, é que ninguém tem uma forma rigorosa de estimar custo antes que uma linha de código seja escrita. As pessoas adivinham. Elas se ancoram em vibes. Elas usam o último projeto como ponto de referência sem verificar se era remotamente comparável.
Então. Aqui está o framework que eu realmente uso. Não uma planilha com células de placeholder. Um modelo mental real, com números atuais de 2026, ferramentas específicas, e as ressalvas que importam.
---
Por Que a Maioria das Cotações de Software São Ficção
O problema não é desonestidade (usualmente). É que estimativa de software é genuinamente difícil, e a maioria das pessoas subestima o quão difícil é, então elas recorrem a atalhos que parecem rigor mas não são.
Um desenvolvedor te dá um número de gut-feel. Uma agência multiplica sua daily rate por alguma contagem estimada de sprints. Um freelancer olha um gig similar no Upwork e trabalha de trás para frente. Nenhum desses está exatamente errado, mas nenhum deles leva em conta os reais cost drivers: complexidade de integração, latência de decisão do lado do cliente, scope creep em features que pareciam menores, overhead de testing, e o assassino silencioso, setup de ambiente e DevOps que ninguém precifica.
Lá em 2021 eu estava rodando um projeto para um cliente de property-tech em Manchester. Simples o bastante no papel: um portal de inquilino com uploads de documentos, rastreamento de aluguel, e um workflow de requisição de manutenção. Orçamento inicial era £28.000. Nós tínhamos feito builds similares. Mas esse cliente estava usando um legacy property management system que tinha uma API proprietária que ninguém tinha tocado em quatro anos. A integração sozinha explodiu por três semanas. Custo final: £47.500. O cliente estava certo sobre isso porque nós tínhamos sinalizado no momento em que encontramos os API docs, mas o orçamento inicial ainda era ficção, e eu assumi isso.
O Cone da Incerteza É Real
O cone da incerteza, popularizado por Steve McConnell, descreve como estimativas de projeto ficam mais acuradas conforme você se aproxima da entrega. Na ideação, você pode estar errado por 4x em qualquer direção. Após design detalhado, talvez 1.25x. A maioria dos founders está recebendo orçamentos no estágio de ideação e os tratando como contratos assinados.
O resultado prático: qualquer orçamento que você receba antes que specs detalhadas sejam escritas deve ser tratado como um range, não um número. Se uma agência te dá um número único antes de terem visto seu data model, user flows, e third-party dependencies, esse número é decorativo.
---
Os Quatro Reais Buckets de Custo
Antes que qualquer estimador possa funcionar, você precisa dividir o projeto nas categorias certas. Não "frontend, backend, QA", esses são papéis, não cost drivers. Os buckets reais:
1. Trabalho Greenfield vs. Integração
Greenfield, construir algo do zero contra seu próprio banco de dados e lógica de negócio, é a metade mais barata, mais previsível de quase todo projeto. É o trabalho de integração que te pega. Cada API externa, sistema legado, processador de pagamento, ou provedor de auth de terceiros adiciona complexidade não-linear. Eu tipicamente adiciono uma contingência de 30-40% em qualquer linha de escopo que toque sistemas externos.
2. Design de UI/UX (Não Pule Esta Linha)
Muito founders tratam design como opcional ou tentam rolá-lo para dentro do orçamento de desenvolvimento. Engano. Design feito adequadamente, wireframes, protótipos interativos em Figma, uma component library testada, tipicamente roda 15-25% do custo total do projeto. Pule isso e você pagará duas vezes: uma vez em rework de desenvolvedor quando requisitos virarem ser ambíguos, e novamente em user research depois quando o produto não converter.
3. Infraestrutura e DevOps
Ninguém cita isso direito. Ambientes de staging, pipelines de CI/CD (usamos GitHub Actions em quase tudo agora), containerização com Docker, hospedagem em nuvem na AWS ou GCP, são custos reais que não desaparecem porque ninguém os colocou no orçamento. Para uma SaaS de complexidade média, orce um mínimo de £3.000-£6.000 para setup inicial de infraestrutura, mais custos mensais contínuos que tipicamente rodam £200-£800 dependendo do uso.
4. Testes, QA e Overhead de Lançamento
Suítes de testes automatizados, passos de QA manual, testes de performance, revisão de segurança para qualquer coisa que lide com pagamentos ou dados pessoais, isso é tipicamente 20% do tempo total de desenvolvimento se feito direito. A maioria das propostas de agência inclui "testes" como um item de linha e significa "um dev clicou pela interface por uma tarde antes da chamada de entrega."
---
Um Estimador Funcional: O Método de Módulos
Aqui está o framework atual. Eu chamo de Método de Módulos porque força você a quebrar um projeto em pedaços discretos, independentemente estimáveis, em vez de tratá-lo como um monólito.
Passo 1: Liste cada feature como uma história de usuário. Não "gerenciamento de usuários", isso é muito vago. "Um usuário pode se registrar com email e senha, verificar seu email, resetar sua senha e atualizar sua foto de perfil." Quatro histórias. Cada uma tem um custo.
Passo 2: Classifique cada story por complexidade. Eu uso três níveis:
- Simple (S): CRUD puro, sem dependências externas, padrões de UI padrão. Pense em: uma página de configurações, um formulário de atualização de perfil, uma tabela de dados com ordenação.
- Medium (M): Alguma lógica de negócio, uma integração externa, ou UI não-padrão. Pense em: uma busca filtrada com queries salvas, um handler de webhook, um fluxo de inscrição Stripe.
- Complex (C): Múltiplas integrações, features em tempo real, lógica algorítmica, ou infraestrutura pesada. Pense em: um sistema de live chat, um motor de recomendações, um modelo de permissões multi-tenant.
Passo 3: Atribua faixas de horas, não estimativas em pontos.
Em 2026, trabalhando com uma agência mid-tier do Reino Unido ou um forte time nearshore, aqui está o que eu orçaria:
- Story simples: 4-8 horas
- Story média: 12-24 horas
- História complexa: 30-80 horas (sim, essa amplitude é real, complexo é genuinamente imprevisível)
Etapa 4: Aplique sua taxa.
Taxas de mercado atuais que você precisa conhecer:
- Desenvolvedor sênior baseado em Londres (freelancer): £90-£140/hr
- Agência do Reino Unido (equipe completa, gerenciada por projeto): £80-£120/hr blended
- Nearshore forte (Europa Oriental, América Latina): £35-£65/hr
- Offshore (Ásia do Sul, Filipinas): £15-£35/hr, e sim, você consegue trabalho excelente aqui, mas overhead de comunicação é real e precisa ser precificado
Etapa 5: Adicione overheads explicitamente.
Não absorva esses custos. Detalhe-os:
- Gestão de projeto: 10-15% das horas de desenvolvimento
- Design (se não estiver já escopo definido): 15-25% do total
- DevOps/Configuração de infraestrutura: £3.000-£8.000 fixo dependendo da complexidade
- QA: 20% das horas de desenvolvimento no mínimo
- Contingência: 20% em projetos greenfield, 35% em qualquer coisa com integração significativa
---
Um Exemplo Real: Dashboard SaaS, Precificação 2026
Deixa eu passar por algo concreto. Um founder vem até mim querendo um dashboard de analytics B2B, um produto SaaS onde seus clientes fazem login, veem seus dados de performance puxados do Google Analytics 4 e de um banco de dados de eventos customizado, podem exportar relatórios e gerenciar o acesso da própria equipe.
É assim que eu dividiria:
- Sistema de autenticação (email + Google SSO, acesso baseado em funções):2 histórias Medium = 48 hrs
- Integração GA4 + pipeline de dados:1 história Complex = 55 hrs
- Schema de banco de dados de eventos customizado + API:2 histórias Medium = 40 hrs
- Dashboard UI (gráficos via Chart.js ou Recharts, responsivo):3 histórias Medium = 65 hrs
- Exportação de relatórios para PDF/CSV:1 história Medium = 18 hrs
- Gerenciamento de equipe (convite, remoção, atribuição de função):2 histórias Simple + 1 história Medium = 28 hrs
- Faturamento via Stripe (assinaturas, upgrade/downgrade):1 história Complex = 45 hrs
Total de desenvolvimento bruto: ~299 horas
Aplicar uma taxa de agência UK mesclada de £95/hr:£28,405
Adicionar:
- Design (20%): £5,681
- DevOps setup: £4,500
- QA (20% das horas de dev, mesma taxa): £5,681
- PM (12%): £3.409
- Contingência de integração (30% no trabalho com GA4 e Stripe): £3.000
Orçamento total: ~£50.676
É um número real para um produto real. Não choca se você entender o que tem nele. Absolutamente chocante se você entrou esperando £18.000 porque foi isso que alguém disse a um fundador da sua rede no ano passado por "algo parecido."
---
Os Custos Ocultos Que Ninguém Menciona
Licenças e Serviços de Terceiros
Mapbox para recursos de mapeamento. Twilio para SMS. SendGrid para email transacional. Algolia se você precisa de busca adequada. Esses são custos contínuos que founders rotineiramente omitem do orçamento de software inteiro porque pensam neles como "só APIs". Um SaaS de escala média com 10.000 usuários ativos pode estar pagando £800-£2.000/mês em taxas de serviços terceirizados antes de uma única conta de servidor chegar.
Segurança e Conformidade
Se você está lidando com dados pessoais no Reino Unido, GDPR não é opcional. Se você está mexendo com pagamentos, conformidade PCI DSS adiciona sobrecarga. Se você está em saúde ou finanças, você está olhando para custos de auditoria adicionais que podem rodar £5.000-£20.000 só para trabalho de certificação inicial. Vi founders serem genuinamente pegos de surpresa por isso. Um cliente fintech nosso em 2023 tinha orçado zero libras para trabalho de conformidade e aí precisou de £14.000 nisso antes de conseguir fazer o lançamento.
Handover e Documentação
Boa documentação, docs de API, runbooks de deployment, guias de onboarding para devs futuros, custam tempo real. Orce 5-8% do total de horas do projeto para documentação se você quer ser capaz de manter, estender ou vender a coisa.
---
Como Fazer Teste de Pressão em um Orçamento que Você Recebeu
Você tem uma proposta na sua frente. Aqui está como auditar antes de assinar:
- Peça o detalhamento de features por trás do número. Se eles não conseguem te dar um detalhamento no nível de story, o orçamento é um palpite.
- Verifique se DevOps, QA e PM são itens de linha ou estão escondidos em uma taxa blended. Escondido normalmente significa mal cozinhado.
- Pergunte qual é a política de contingência deles. Eles limitam custos adicionais? Time-and-materials ou preço fixo? Cada um tem implicações reais.
- Descubra que suposições eles fizeram sobre integrações de terceiros. Pergunte diretamente: "Vocês leram a documentação de API para [serviço específico] antes de orçar?"
- Pergunte o que acontece se os requisitos mudarem depois da sprint 2. A resposta te diz quase tudo sobre como a agência funciona.
A metodologia Shape Up do Basecamp tem um framing genuinamente útil para isto: tempo fixo, escopo variável. Vale a pena ler antes de entrar em qualquer negociação com agência.
---
Ferramentas de IA em 2026: O Que Mudam (e O Que Não Mudam)
Todos querem saber se GitHub Copilot, Cursor, ou a nova onda de ferramentas de codificação baseadas em agentes (Devin, Replit Agent) reduziram materialmente os custos de software. Sinceramente? Sim, um pouco. Mas menos do que o hype sugere.
Minha experiência aproximada: desenvolvedores fortes assistidos por IA estão trabalhando umas 20-30% mais rápido em trabalho CRUD greenfield. Aquele meio do caminho de features padrão, forms, tabelas, fluxos de auth básicos, vem mais rápido mesmo. Mas trabalho de integração complexa, decisões arquiteturais, debugar race conditions sutis, e qualquer coisa que exija pensamento profundo de produto? IA não ajuda ali, e em alguns casos gera código que parece correto mas introduz novos problemas.
Eu aplicaria um desconto de eficiência de 10-15% para stories simples e médias em 2026 se a equipe está confirmada estar usando tooling de AI a sério. Não mais do que isso. Qualquer um te dando orçamento 50% mais baixo "porque usamos AI" está ou rodando um tipo bem diferente de projeto do que você pensa, ou te contando algo bom demais para ser verdade.
---
FAQ
Quão precisa uma estimativa de software pode ser realmente antes de specs serem escritas?
Não muito. Espere variância de ±40-60% no estágio de ideia. Depois que você tem fluxos de usuário detalhados, um modelo de dados e uma lista de todas as dependências de terceiros, consegue chegar a ±20%. Depois de um sprint de descoberta com wireframes e arquitetura técnica: ±10-15%. Pague por um engagement de descoberta apropriado antes de se comprometer com um orçamento de build completo, normalmente custa £2.000-£6.000 e é o melhor dinheiro que você vai gastar no projeto.
Devo optar por preço fixo ou tempo e materiais?
Preço fixo te dá certeza de orçamento mas passa o risco para a agência, o que significa que eles vão inflar a estimativa e se proteger com cláusulas de change-order. Time-and-materials é honesto mas exige que você gerencie escopo ativamente. Minha preferência para a maioria dos founders: preço fixo por sprint (tipicamente 2 semanas), com escopo definido no início de cada sprint. Você consegue previsibilidade sem o jogo de padding.
Desenvolvimento nearshore ou offshore é realmente mais barato uma vez que você considera o overhead de gestão?
Frequentemente, mas nem sempre. O overhead é real, mais tempo de PM, mais comunicação assíncrona, rework ocasional por expectativas desalinhadas. Para um projeto bem escopo com specs fortes, nearshore (Europa Oriental particularmente) oferece valor genuíno. Executei projetos bem-sucedidos a £40/hr blended com times poloneses e ucranianos. Para algo ambíguo e em movimento rápido, eu manteria mais perto de casa.
Qual é uma bandeira vermelha em uma proposta de software?
Uma citação em linha única sem detalhamento. Uma timeline que não inclui QA ou deployment. Nenhuma menção de como change requests são tratados. E honestamente, qualquer agência que não te faz perguntas duras sobre sua infraestrutura existente antes de citar. Se não estão curiosos sobre suas constraints, não pensaram seriamente no seu projeto.
Como eu budgeto para manutenção pós-launch?
Regra padrão: 15-20% do custo de build inicial por ano para manutenção contínua, correções de bugs e trabalho de pequenas features. Uma build de £50.000 precisa de um orçamento de manutenção anual de £7.500-£10.000. Se alguém disser que software é "done" no launch, arrume outras pessoas de software.
---
O fundador de logística de novembro? Ele voltou para a agência dele, eles refatoraram o processo de trabalho deles, e o produto saiu em março. Está rodando bem. Mas ele me disse que desejava que alguém tivesse passado um framework como este para ele antes de assinar qualquer coisa. Então. Aqui está.
Leitura relacionada: Building a Real-Time Auction Site with Next.js & Supabase, desenvolvimento web personalizado e software sob medida.