Passamos sete meses construindo nosso próprio Intercom. Mãos ao alto, quem já fez isso
Sobre uma dessas histórias — e sobre como eu converso agora com clientes quando começam a me explicar por que no caso deles 'escrever é melhor do que comprar'.
Em 2022 eu tinha um cliente — um time de produto, uns quinze, fazendo SaaS para RH. Negócio normal, receita normal, time normal. E tinham um projeto: escrever o próprio chat de suporte.
Descobri na segunda semana do contrato. O CTO mostrou com orgulho um Kanban em que, entre outras tarefas, pendurava um épico. O épico chamava "Customer Chat Platform". Tinha vinte e três tickets, quatro fechados, dezenove em execução em vários graus de "começado".
— Então, — eu disse. — Por quê?
— Bem, — disse o CTO. — A gente não quer depender do Intercom. É caro, tem limite de customização, tem vendor lock-in.
— Quanto tempo isso leva?
— Uns dois meses. Depois a gente vai iterando.
O projeto rolou sete meses. Nesse tempo se escreveu uns 60% das funcionalidades do Intercom de 2019. Por subestimação (sempre) e outras prioridades (sempre), o projeto ia e vinha. Em dado momento apareceu um bug em que as mensagens se perdiam — só no Safari mobile do iOS 15.3.1 e só se a mensagem passasse de 400 caracteres. Esse bug levou duas semanas pra ser corrigido.
No mês sete — compraram o Intercom. O CFO sentou com o CTO, fizeram a conta: no tempo de desenvolvimento, o time tinha gastado cerca de 4,5 milhões de rublos em salário (sem contar café). O Intercom custaria em torno de 700 000 rublos por ano. Em sete meses — 410 000.
Diferença — 4,1 milhões. Dá para contratar dois sêniores. Que, aliás, eles não contrataram, "porque não tem orçamento agora".
Não conto isso pra xingar o CTO. O CTO era normal. Queria fazer o certo. Só caiu na armadilha clássica — confusão entre core e não-core.
Core é pelo que seu cliente paga. Aquilo em que você é diferente dos concorrentes. Para esse cliente — core era análise de RH. Não chat. Chat era não-core.
Core nunca é SaaS. Se você compra uma "plataforma LMS" e constrói uma escola online em cima — você não é usuário da plataforma, é concorrente dela. Em um ano bate no teto dela.
Não-core sempre é SaaS. Se você escreve seu próprio Stripe, seu próprio Slack, seu próprio Intercom — está indo para a dívida. Porque a Stripe gasta em um ano, em engenharia, mais do que todo o seu orçamento anual. E ainda assim eles encontram bugs que você não terá tempo de encontrar.
Essa é a única pergunta obrigatória antes de qualquer discussão "escrever ou comprar". Se "core" — para de ler, vai construir (ou montar com blocos). Se "não-core" — continua lendo, mas com preferência por SaaS.
Depois eu aplico mais seis perguntas, porque nem todo não-core vale a pena comprar, e nem todo core vale a pena escrever do zero.
Pergunta dois — custo de uma "hora de dúvida do usuário".
SaaS funciona hoje. Menos a assinatura. Build funciona em N semanas, menos o salário do time por N semanas.
Fórmula simples: se SaaS_anual < 2 × salário_anual_do_dev e a funcionalidade cobre 80% — SaaS ganha.
Pergunta três — o SaaS tem a API que você precisa.
Comprar Shopify — ok. Mas se o estoque está num sistema, o caixa em outro SaaS, o entregador em um stack próprio — seu trabalho é costurar tudo via API. Verifique a API antes de comprar. Se o endpoint de que precisa não existe, você paga o SaaS e o build de um proxy entre ele e o resto. O pior dos mundos.
Pergunta quatro — o vendor sobrevive mais que você.
SaaS startup de dez pessoas prometendo resolver tudo — risco. Se morrem em dois anos, você perde dados, lógica, processo.
Checagem: empresa com mais de 5 anos? Series B+? Documentação de migração pra concorrente? Se não — é SaaS de vida curta, e a migração vai doer.
Pergunta cinco — dados.
Em setores regulados (fintech, saúde, governo) essa costuma ser a única pergunta decisiva. Se o SaaS não está na jurisdição certa — build. Fim.
Em não regulados — também pense. Se análise crítica depende do SaaS e não há export, você é refém do vendor. Aumento de 40% no preço não tem negociação.
Pergunta seis — quão custom é seu processo.
SaaS é bom quando seu processo cai em 80% do que o produto suporta. Quanto mais longe da média, mais customização, plugin, workaround. Em dado momento você gasta em customização mais do que o build teria custado.
Regra: três customizações — normal, cinco — bandeira vermelha, dez — hora de migrar.
Pergunta sete — talvez não escolher.
2026 muda as regras. Antes era "escrever do zero ou comprar pronto". Agora tem uma terceira opção: montar com blocos de baixo nível.
— Backend API — Hono / FastAPI em 30 linhas.
— Banco — PostgreSQL em qualquer provedor.
— Auth — Clerk / Supabase em uma hora.
— Queue — Temporal / Inngest.
— LLM — OpenAI / Anthropic API.
O que há três anos era seis meses de dev hoje sai em três semanas. Seu build deixa de se opor ao SaaS — é feito de pedaços de SaaS. 20% custom + 80% emprestado. Default agora.
Voltando àquele CTO. Um ano depois da história do chat a gente se encontrou numa conferência. Perguntei o que estavam fazendo. Ele respondeu que tinham devolvido todo o trabalho não-core pro SaaS (Intercom, HubSpot, ClickUp), e focado o time em uma coisa — análise de RH. Receita subiu 60% no ano.
"Eu," ele disse, "passei aquele ano aprendendo uma lição: trabalho de engenharia nem sempre é escrever código. Às vezes é decidir não escrever."
Não há resposta universal. Há sete perguntas que em quinze minutos transformam discussão filosófica em decisão com argumentos.
Da próxima vez que ouvir "vamos escrever nós mesmos / vamos comprar" — abra esse checklist. Vai economizar semanas e dezenas de milhares.