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 havia assinado. Seis meses depois a fatura final chegou em £61.000. Ninguém havia mentido para ele, tecnicamente. Mas ninguém havia lhe contado a verdade tampoco -- porque ninguém havia realmente feito o trabalho de estimar direito antes de levar 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.Custom software quotes go wrong at scoping, not building; estimate from data model complexity, integrations, and review cycles, and price the discovery phase separately.
Estou construindo software há mais de doze anos. Seahawk sozinha entregou mais de 12.000 sites e aplicações. E o ponto de falha mais consistente que vejo -- com fundadores, com freelancers, com agências orçando projetos -- é que ninguém tem um jeito rigoroso de estimar custo antes de uma linha de código ser escrita. As pessoas adivinham. Elas se ancoram em vibes. Elas usam o projeto anterior como ponto de referência sem checar 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 buscam atalhos que parecem rigor mas não são.how hard -- so they reach for shortcuts that feel like rigour but aren't.
Um developer te dá um número por intuição. Uma agência multiplica seu day rate por alguma contagem de sprints estimada. Um freelancer olha um gig similar no Upwork e trabalha de trás para frente. Nenhum desses está exatamente errado, mas nenhum deles considera 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 testes, e o assassino silencioso -- setup de ambiente e DevOps que ninguém precifica.
Lá em 2021 eu estava rodando um projeto para um cliente property-tech em Manchester. Simples o suficiente no papel: um tenant portal com uploads de documentos, rastreamento de aluguel e um workflow de solicitação de manutenção. Estimativa inicial foi £28.000. Nós tínhamos feito builds similares. Mas este cliente estava usando um legacy property management system que tinha uma proprietary API que ninguém havia tocado em quatro anos. Integração sozinha explodiu por três semanas. Custo final: £47.500. O cliente estava ok com isso porque nós tínhamos sinalizado no momento que encontramos os API docs -- mas a estimativa inicial ainda era ficção, e isso era minha responsabilidade.
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.
A implicação prática: qualquer orçamento que você receba antes de specs detalhadas serem escritas deve ser tratado como um intervalo, não um número. Se uma agência te dá uma figura única antes de terem visto seu modelo de dados, user flows e dependências third-party -- 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 de qualquer estimador poder funcionar, você precisa dividir o projeto nas categorias certas. Não "frontend, backend, QA" -- essas são roles, não cost drivers. Os buckets reais:
1. Trabalho Greenfield vs. Integração
Greenfield -- construindo algo do zero contra seu próprio database 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, legacy system, payment processor ou third-party auth provider 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)
Muitos fundadores tratam design como opcional ou tentam encaixá-lo na estimativa de desenvolvimento. Erro. Design feito corretamente -- wireframes, protótipos interativos em Figma, uma biblioteca de componentes testada -- normalmente consome 15-25% do custo total do projeto. Pule essa etapa e você pagará em dobro: uma vez em refatoração do desenvolvedor quando os requisitos se mostrarem ambíguos, e novamente em pesquisa de usuários 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 orça isso corretamente. 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 -- esses são custos reais que não desaparecem porque ninguém os discriminou. Para uma SaaS de complexidade média, orçar um mínimo de £3.000-£6.000 para a configuração inicial da infraestrutura, mais custos mensais contínuos que normalmente ficam em £200-£800 dependendo do uso.
4. Testes, QA e Overhead de Lançamento
Suítes de testes automatizados, passes de QA manual, testes de performance, revisão de segurança para qualquer coisa que manipule pagamentos ou dados pessoais -- isso é tipicamente 20% do tempo total de desenvolvimento se feito corretamente. A maioria das cotações de agência inclui "testing" como um item de linha e significa "um dev clicou 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 funcionalidade como uma user story. Não "gerenciamento de usuários" -- isso é muito vago. "Um usuário pode se registrar com email e senha, verificar seu email, redefinir 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 por complexidade. Eu uso três níveis:I use three tiers:
- 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.(S): Pure CRUD, no external dependencies, standard UI patterns. Think: a settings page, a profile update form, a data table with sorting.
- 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.(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.
- 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.(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édia: 12-24 horas
- Story complexa: 30-80 horas (sim, essa amplitude é grande -- 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 excelente trabalho aqui, mas a sobrecarga de comunicação é real e precisa ser precificada
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
Deixe-me 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 um banco de dados customizado de eventos, 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ções):2 histórias Medium = 48 hrs2 Medium stories = 48 hrs
- Integração GA4 + pipeline de dados: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
- Exportação de relatórios para PDF/CSV:1 história Medium = 18 hrs1 Medium story = 18 hrs
- Gerenciamento de equipe (convite, remoção, atribuição de função):2 histórias Simple + 1 história Medium = 28 hrs2 Simple + 1 Medium stories = 28 hrs
- Faturamento via Stripe (assinaturas, upgrade/downgrade):1 história Complex = 45 hrs1 Complex story = 45 hrs
Total de desenvolvimento bruto: ~299 horas
Aplicar uma taxa de agência UK mesclada 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 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.PCI DSS compliance adds 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 deployment, guias de onboarding para devs futuros -- custa tempo real. Orçamento 5-8% das horas totais de projeto para documentação se você alguma vez 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 isto: tempo fixo, escopo variável. Vale a pena ler antes de entrar em qualquer negociação com 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 bruta: desenvolvedores fortes assistidos por AI estão trabalhando cerca de 20-30% mais rápido em trabalho CRUD greenfield. Aquele pedaço do meio de features padrão -- formulários, tabelas, fluxos de auth básicos -- sai mais rápido mesmo. Mas trabalho complexo de integração, decisões arquiteturais, debugging de race conditions sutis, e qualquer coisa que exija pensamento profundo de produto? AI não ajuda ali, e em alguns casos gera código que parece plausível e 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 uma variação de ±40-60% na fase de ideação. Quando você tiver 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 adequado antes de se comprometer com o orçamento completo da build -- tipicamente 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 a estimativa e se proteger com cláusulas de mudança de escopo. Time-and-materials é honesto mas exige que você gerencie ativamente o escopo. 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 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, rework ocasional por expectativas desalinhadas. Para um projeto bem-scoped com specs fortes, nearshore (Europa Oriental particularmente) oferece valor genuíno. Já rodei projetos bem-sucedidos a £40/hr com blended com times poloneses e ucranianos. Para algo ambíguo e que se move rápido, eu manteria mais perto de casa.
Qual é uma bandeira vermelha em uma proposta de software?
Uma cotação em uma única linha sem breakdown. Um timeline que não inclui QA ou deployment. Nenhuma menção de como mudanças são tratadas. E honestamente -- qualquer agência que não faz perguntas difíceis sobre sua infraestrutura existente antes de cotar. Se não são curiosos sobre suas restrições, 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á.