Um founder ligou para mim em novembro de 2024, duas semanas antes do Natal, absolutamente furioso. Uma agência web havia cotado £14.000 para um dashboard de logística sob medida. Ele assinou. Seis meses depois a nota final chegou em £61.000. Ninguém havia mentido para ele, tecnicamente. Mas ninguém havia dito a verdade também — porque ninguém havia realmente feito o trabalho de estimar adequadamente antes de receber seu dinheiro.
Estou construindo software há mais de doze anos. A Seahawk sozinha entregou mais de 5.000 sites e aplicações. E o único ponto de falha mais consistente que vejo — com founders, com freelancers, com agências cotando projetos — é que ninguém tem uma forma rigorosa de estimar custo antes de uma linha de código ser escrita. As pessoas adivinham. Ancoras em vibes. 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 (geralmente). É que estimativa de software é genuinamente difícil, e a maioria das pessoas subestima o quão difícil — então recorrem a atalhos que parecem rigor mas não são.howhard — so they reach for shortcuts that feel like rigour but aren't.
Um desenvolvedor te dá um número baseado em intuição. Uma agência multiplica sua taxa diária por alguma contagem de sprints estimada. Um freelancer olha um trabalho similar no Upwork e trabalha de trás para frente. Nenhum desses está exatamente errado, mas nenhum deles leva em conta os reais drivers de custo: complexidade de integração, latência de decisão do lado do cliente, scope creep em funcionalidades que pareciam menores, overhead de testes, e o assassino silencioso — setup de ambiente e DevOps que ninguém coloca no preço.
Lá em 2021 eu estava rodando um projeto para um cliente de property-tech em Manchester. Simples o suficiente no papel: um portal de inquilino com uploads de documentos, rastreamento de aluguel e um workflow de requisição de manutenção. A estimativa inicial era £28.000. Já tínhamos feito builds similares. Mas esse cliente estava usando um legacy property management system que tinha uma proprietary API que ninguém tinha tocado em quatro anos. A integração sozinha esticou por três semanas. Custo final: £47.500. O cliente ficou bem com isso porque a gente sinalizou no momento em que encontramos os docs da API — mas a estimativa 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., popularised by Steve McConnell, describes how project estimates get more accurate as you get closer to delivery. At ideation, you might be off by 4x in either direction. After detailed design, maybe 1.25x. Most founders are getting quotes at the ideation stage and treating them like signed contracts.
O resultado prático: qualquer orçamento que você receba antes de specs detalhadas serem escritas deve ser tratado como uma faixa, 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 dependências de terceiros — esse número é decorativo.range, not a number. If an agency gives you a single figure before they've seen your data model, user flows, and third-party dependencies — that number is decorative.
---
Os Quatro Reais Buckets de Custo
Antes que qualquer estimador possa trabalhar, você precisa dividir o projeto nas categorias certas. Não "frontend, backend, QA" — esses são papéis, não drivers de custo. 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 e 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 autenticação terceirizada adiciona complexidade não-linear. Tipicamente adiciono uma contingência de 30–40% em qualquer linha de escopo que envolva sistemas externos.
2. Design de UI/UX (Não Pule Esta Linha)
Muitos fundadores tratam design como opcional ou tentam incorporá-lo à estimativa de desenvolvimento. Erro. Design feito corretamente — wireframes, protótipos interativos em Figma, uma biblioteca de componentes testada — tipicamente corre 15–25% do custo total do projeto. Pule e você pagará em dobro: uma vez no retrabalho do desenvolvedor quando os requisitos se mostrarem ambíguos, e novamente na pesquisa de usuário depois quando o produto não converter.Figma, a tested component library — typically runs 15–25% of total project cost. Skip it and you'll pay twice: once in developer rework when requirements turn out to be ambiguous, and again in user research later when the product doesn't convert.
3. Infraestrutura e DevOps
Ninguém cota isso direito. Ambientes de staging, pipelines de CI/CD (usamos GitHub Actions em quase tudo agora), containerização com Docker, hospedagem em nuvem em AWS ou GCP — estes são custos reais que não desaparecem porque ninguém os discriminou. Para um SaaS de complexidade média, faça orçamento de um mínimo de £3.000–£6.000 para setup inicial de infraestrutura, mais custos mensais contínuos que tipicamente correm £200–£800 dependendo do uso.
4. Testes, QA e Overhead de Lançamento
Suites de testes automatizados, passes de QA manual, testes de performance, revisão de segurança para qualquer coisa lidando com pagamentos ou dados pessoais — isto é tipicamente 20% do tempo total de desenvolvimento se feito corretamente. A maioria das cotações de agência incluem "testes" como item de linha e significam "um dev clicou por uma tarde antes da chamada de handover."
---
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 user story. Não "gerenciamento de usuários" — é 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 stories. Cada uma tem um custo.Not "user management" — that's too vague. "A user can register with email and password, verify their email, reset their password, and update their profile photo." Four stories. Each one has a cost.
Passo 2: Classifique cada story pela complexidade. Eu uso três níveis:I use three tiers:
- Simples (S): CRUD puro, sem dependências externas, padrões de UI padrão. Pense: uma página de configurações, um formulário de atualização de perfil, uma tabela de dados com ordenação.(S): Pure CRUD, no external dependencies, standard UI patterns. Think: a settings page, a profile update form, a data table with sorting.
- Médio (M): Alguma lógica de negócio, uma integração externa, ou UI não-padrão. Pense: uma busca filtrada com queries salvas, um webhook handler, um fluxo de assinatura Stripe.(M): Some business logic, one external integration, or non-standard UI. Think: a filtered search with saved queries, a webhook handler, a Stripe subscription flow.
- Complexo (C): Múltiplas integrações, features em tempo real, lógica algorítmica, ou infraestrutura pesada. Pense: um sistema de chat ao vivo, um motor de recomendação, um modelo de permissões multi-tenant.(C): Multiple integrations, real-time features, algorithmic logic, or heavy infrastructure. Think: a live chat system, a recommendation engine, a multi-tenant permission model.
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édio: 12–24 horas
- Story complexo: 30–80 horas (sim, essa amplitude — 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, gerenciamento de projeto): £80–£120/hr blended
- Nearshore forte (Europa Oriental, América Latina): £35–£65/hr
- Offshore (Sul Asiático, Filipinas): £15–£35/hr — e sim, você consegue trabalho excelente aqui, mas o overhead de comunicação é real e precisa ser precificado
Etapa 5: Adicione overheads explicitamente.
Não absorva esses custos. Detalhe-os:
- Gerenciamento de projeto: 10–15% das horas de desenvolvimento
- Design (se ainda não foi delimitado): 15–25% do total
- Configuração de DevOps/Infraestrutura: £3.000–£8.000 fixos 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 te passar por algo concreto. Um founder vem até mim querendo um dashboard de análise B2B — um produto SaaS onde os clientes deles fazem login, veem os dados de performance puxados do Google Analytics 4 e de um banco de dados de eventos customizado, conseguem 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ção): 2 histórias Medium = 48 hrs2 Medium stories = 48 hrs
- Integração GA4 + data pipeline: 1 história Complex = 55 hrs1 Complex story = 55 hrs
- Schema de banco de dados de eventos customizado + API: 2 histórias Medium = 40 hrs2 Medium stories = 40 hrs
- Dashboard UI (gráficos via Chart.js ou Recharts, responsivo): 3 histórias Medium = 65 hrs3 Medium stories = 65 hrs
- Exportar relatório para PDF/CSV: 1 história Medium = 18 hrs1 Medium story = 18 hrs
- Gerenciamento de equipe (convidar, remover, atribuição de funções): 2 histórias Simple + 1 história Medium = 28 hrs2 Simple + 1 Medium stories = 28 hrs
- Billing via Stripe (assinaturas, upgrade/downgrade): 1 história Complex = 45 hrs1 Complex story = 45 hrs
Total de desenvolvimento bruto: ~299 horas
Aplicar taxa de agência UK blended de £95/hr: £28,405£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 funcionalidades de mapeamento. Twilio para SMS. SendGrid para email transacional. Algolia se você precisa de busca adequada. Esses são custos recorrentes que fundadores rotineiramente omitem completamente do orçamento de software porque pensam neles como "apenas 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 de terceiros antes de uma única conta de servidor chegar.
Segurança e Conformidade
Se você está tratando dados pessoais no Reino Unido, GDPR não é opcional. Se você está lidando com pagamentos, conformidade com PCI DSS adiciona overhead. Se você está em saúde ou finanças, está olhando para custos adicionais de auditoria que podem chegar a £5.000–£20.000 apenas para trabalho de certificação inicial. Já vi fundadores ficarem genuinamente de surpresa com isso. Um cliente fintech nosso em 2023 havia orçado zero libras para trabalho de conformidade e depois precisou de £14.000 disso antes de lançar.PCI DSS complianceadds overhead. If you're in health or finance, you're looking at additional audit costs that can run £5,000–£20,000 just for initial certification work. I've seen founders get genuinely blindsided by this. One fintech client of ours in 2023 had budgeted zero pounds for compliance work and then needed £14,000 of it before they could launch.
Handover e Documentação
Boa documentação — docs de API, runbooks de deploy, guias de onboarding para devs futuros — custa tempo de verdade. Reserve 5–8% do total de horas do projeto para documentação se você quiser conseguir 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 isso: tempo fixo, escopo variável. Vale a pena ler antes de entrar em qualquer negociação de agência.has a genuinely useful framing for this: fixed time, variable scope. It's worth reading before you enter any agency negotiation.
---
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 com assistência de IA estão trabalhando cerca de 20–30% mais rápido em trabalho CRUD greenfield. Aquele meio-termo de funcionalidades padrão — formulários, tabelas, fluxos de autenticação básica — sai mais rápido mesmo. Mas trabalho de integração complexa, decisões arquiteturais, debugging de race conditions sutis, e qualquer coisa que exija pensamento profundo sobre o produto? IA não ajuda aí, e em alguns casos gera código que parece plausível mas introduz novos problemas.
Eu aplicaria um desconto de eficiência de 10–15% para histórias simples e médias em 2026 se o time estiver confirmadamente usando ferramentas de IA a sério. Não mais do que isso. Qualquer um te cotando 50% mais barato "porque usamos IA" está rodando um tipo de projeto muito diferente do que você pensa, ou está te falando 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% na fase de ideia. Assim que você tiver user flows detalhados, um data model, e uma lista de todas as dependências de terceiros, você consegue chegar a ±20%. Depois de um discovery sprint com wireframes e arquitetura técnica: ±10–15%. Pague por um engagement de discovery apropriado antes de você se comprometer com um orçamento de build completo — típicamente 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 orçamentária mas transfere o risco para a agência — o que significa que eles vão inflar o orçamento e se proteger com cláusulas de mudança. Tempo e materiais é honesto mas exige que você gerencie escopo ativamente. Minha preferência para a maioria dos fundadores: preço fixo por sprint (tipicamente 2 semanas), com escopo definido no início de cada sprint. Você tem previsibilidade sem o jogo de inflação.
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, eventual retrabalhão por expectativas desalinhadas. Para um projeto bem escopo com especificações sólidas, nearshore (Europa Oriental particularmente) oferece valor genuíno. Rodei 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 cotação de uma única linha sem breakdown. Um timeline que não inclui QA ou deployment. Nenhuma menção de como mudanças de requisitos são tratadas. E honestamente — qualquer agência que não te faz perguntas difíceis sobre sua infraestrutura existente antes de cotar. Se eles não têm curiosidade sobre suas limitações, eles não pensaram seriamente no seu projeto.
Como eu budgeto para manutenção pós-launch?
Regra padrão: 15–20% do custo inicial de build por ano para manutenção contínua, correção de bugs, e work de feature menor. Um build de £50,000 precisa de um budget de manutenção anual de £7,500–£10,000. Se alguém te disser que software está "pronto" 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á.