Índice do artigofaltam 6 min de leitura
O orçamento de uma integração é montado sobre o trabalho que se vê: escrever o código que liga os dois lados. O custo real mora no que não se vê, e o que não se vê quase sempre pertence a outra empresa.
A cena é conhecida de qualquer diretoria. A integração foi orçada em algumas semanas, todo mundo concordou que era simples, e três meses depois ela continua em homologação, com uma conversa desconfortável sobre escopo acontecendo em paralelo.
A explicação usual é que o fornecedor subestimou ou que o cliente mudou o pedido. Nos dois casos a conclusão é que alguém errou. Quase nunca é isso. O padrão é estrutural e previsível, e por ser previsível pode ser orçado de outro jeito.
Resumo do artigo
- A estimativa mede o trabalho de quem constrói, e o cronograma real é dominado por dependências de terceiros que ninguém colocou na planilha.
- Os custos invisíveis se repetem projeto após projeto, e todos podem ser verificados antes de o preço ser fechado.
- A proposta mais barata costuma ser a que assumiu as premissas mais otimistas, e nenhuma delas foi conferida.
- O formato que não estoura separa uma descoberta curta e paga do preço fechado da construção.
O orçamento cobre o trabalho visível
Quando uma equipe estima uma integração, ela estima aquilo que sabe fazer: autenticar, chamar, tratar a resposta, exibir na tela, testar. Esse trabalho é real e costuma ser bem dimensionado. O problema não está nele.
Está em tudo que precisa acontecer para que esse trabalho possa começar e terminar, e que depende de pessoas fora do projeto. Quando o cronograma é apresentado como uma soma de tarefas técnicas, ele descreve corretamente o esforço e descreve mal o tempo.
A frase que traduz isso para a diretoria: o orçamento diz quanto trabalho existe; o cronograma depende de quantas portas precisam ser abertas por outras empresas.
Os cinco custos que ninguém coloca na planilha
- Espera por acessoO ambiente de homologação depende de chamado, fila e aprovação de terceiros.
- Campo que faltaExiste no sistema, não vem na resposta. Quem publica é o fornecedor do outro lado.
- Casos de borda do seu negócioFormato novo de documento, cadastro antigo, registro incompleto, acentuação.
- Liberação comercialAmbiente de teste que recusa a chamada até o contrato do outro lado estar ativo.
- Vida depois do lançamentoMonitoramento, registro das chamadas e reação quando o outro lado muda.
Nenhum desses cinco é surpresa. Todos podem ser verificados antes de o preço ser fechado, e é isso que separa uma estimativa honesta de um chute bem apresentado.
Espera não é atraso, é insumo do projeto
O primeiro custo invisível é o mais banal e o mais caro: tempo parado esperando alguém liberar alguma coisa.
Um ambiente de testes do ERP hospedado na nuvem do fornecedor exige chamado, fila e aprovação. Uma organização de CRM com política de segurança rígida exige aprovação interna do cliente para criar a aplicação de integração. Um provedor de pagamento pode devolver erro de permissão no ambiente de testes até que o estabelecimento seja habilitado comercialmente do outro lado, o que não é um problema técnico e não se resolve com código.
O tratamento correto é o mesmo que se dá a qualquer insumo de obra: com data prevista, responsável nomeado e um plano para quando não chegar no prazo. Equipe trabalhando contra uma base de exemplo enquanto a liberação não sai é melhor do que equipe parada, e essa decisão precisa estar combinada antes.
O campo que falta é trabalho de outra empresa
O segundo custo é o mais frequente. O dado existe no sistema, a operação o vê na tela todos os dias, e ele não vem na resposta da integração, porque não faz parte do recurso publicado.
A conta que estoura não é o esforço de incluir o campo. É que esse esforço pertence a quem mantém o outro sistema. Em uma integração com ERP, quando o produto precisou também de DDD e data de nascimento, quem alterou a API foi o fornecedor do ERP. O projeto ficou dependente de um calendário sobre o qual não tinha influência nenhuma.
Os casos de borda são do seu negócio, não da tecnologia
O terceiro custo é o mais subestimado porque parece detalhe. Uma consulta que funciona para o registro novo e falha para o antigo. Um documento em formato que mudou e convive com o formato anterior na mesma base. Um cadastro incompleto que o sistema de origem aceita e o novo produto não.
Num aplicativo de atendimento automotivo, veículos com placa no padrão Mercosul não eram localizados, enquanto os de padrão antigo funcionavam. Isso não é falha de integração: é a realidade de uma base com anos de operação encontrando um produto novo que assumiu um formato só.
O que isso destrava: quando os casos de borda entram na fase de descoberta, eles viram escopo conhecido. Quando aparecem depois, viram renegociação, e renegociação custa muito mais do que o trabalho em si.
Integração pronta continua custando
O quarto e o quinto custos vivem depois do lançamento e raramente entram na proposta. Uma integração é um sistema em produção que depende de outro sistema em produção, e o outro sistema vai mudar, vai sair do ar e vai alterar comportamento sem avisar.
Três itens resolvem quase tudo, e precisam estar orçados: registro de cada chamada com o que foi enviado e o que voltou, porque sem isso a conversa entre dois fornecedores vira palavra contra palavra; comportamento definido do produto quando o outro lado não responde; e alguém acionável quando o alerta disparar.
Vale a honestidade: um bom desenho reduz o número de falhas, torna cada uma diagnosticável e barateia a correção. Ele não impede que o sistema do outro lado fique indisponível.
O formato de orçamento que não estoura
A saída não é orçar com mais gordura. É reconhecer que existem duas naturezas de trabalho e cobrá-las separadamente.
Orçamento em bloco único
Preço fechado antes de ver o ambiente- As premissas são assumidas, não verificadas
- Quem promete mais barato assume mais otimismo
- Toda descoberta vira negociação de escopo
- A relação começa a azedar no segundo mês
Descoberta, depois construção
Preço fechado sobre fato verificado- Acesso real, chamadas reais, campos conferidos
- Dependências externas com nome e responsável
- O escopo da construção sai da descoberta
- Surpresa vira exceção, não rotina
A fase de descoberta é curta, é paga e entrega um documento: os campos conferidos contra a resposta real, o contrato de dados, a lista de dependências externas com responsável nomeado e o desenho da conexão. A partir dela, preço fechado é possível de verdade, porque está apoiado em algo que alguém olhou.
O desenho acima mostra a sequência, não um prazo. Quanto tempo cada faixa ocupa depende das dependências que a descoberta encontrar, e é exatamente por isso que ela vem primeiro.
O que pedir antes de comparar propostas
Comparar propostas de integração pelo preço final é o caminho mais rápido para escolher a que assumiu mais risco escondido. O que torna a comparação justa é exigir que todas declarem as mesmas premissas.
- Quais campos foram verificados contra uma resposta real, e quais foram assumidos
- Quem publica campo novo no outro sistema, e qual foi o prazo da última vez
- Qual o prazo previsto de liberação do ambiente de homologação, e quem o abre
- O que acontece com prazo e preço se alguma premissa não se confirmar
- O que está incluído de monitoramento e suporte depois da virada
Uma proposta que responde as cinco pode custar mais e é a mais barata das duas, porque o preço dela já contém o que a outra vai cobrar depois, em condição pior de negociação.
Vai integrar dois sistemas e precisa de um número em que dá para confiar?
Solicite um orçamento e comece por uma descoberta curta, com acesso real ao ambiente.
Perguntas frequentes
Porque a estimativa mede o trabalho de quem constrói e o cronograma real depende de terceiros: liberação de ambiente, publicação de campo pelo fornecedor do outro sistema e habilitação comercial. Esse tempo de espera raramente entra na planilha.
Dá, depois de uma fase curta de descoberta com acesso real ao ambiente. Preço fechado antes de alguém ter visto uma resposta de verdade da API é apostar em premissas que ainda não foram verificadas.
Um trabalho curto e pago em que a equipe obtém acesso, faz chamadas reais, confere os campos contra o que o produto precisa e mapeia as dependências externas. Ela termina com um escopo e um preço que se sustentam.
Porque a proposta mais barata em geral é a que assumiu as premissas mais otimistas: que os campos existem, que o acesso sai rápido e que não haverá caso de borda. Nenhuma dessas premissas foi verificada quando o preço foi dado.
Sim. Ela é um sistema em produção que depende de outro sistema em produção. Precisa de monitoramento, registro das chamadas e alguém disponível quando o outro lado muda ou sai do ar.
Peça que todas declarem as mesmas premissas: quais campos foram verificados, quem publica campo novo, qual o prazo de liberação do ambiente e o que acontece se essas premissas não se confirmarem.
Fontes e método
Este artigo é baseado em integrações executadas pelo time da X-Apps entre 2023 e 2026, envolvendo sistemas de gestão, CRM, plataformas de e-commerce e provedores de pagamento e consulta. Os casos citados foram despersonalizados, já que a relação entre esses clientes e os sistemas não é pública.
O texto descreve padrões de custo e sequência de fases. Ele não apresenta prazos médios, percentuais de estouro nem faixas de preço, porque a X-Apps não mantém uma medição consolidada desses números, e publicá-los sem lastro seria dar aparência de precisão a uma estimativa.
