--- title: "Passamos sete meses construindo nosso próprio Intercom. Mãos ao alto, quem já fez isso" url: "https://www.mikefluff.com/pt/blog/build-vs-saas-7-questions" locale: "pt" author: "Mike Fluff" updated: "2026-02-09" description: "Uma equipe de produto passou sete meses construindo o próprio Intercom. As sete perguntas que faço agora antes de alguém escrever o que poderia comprar." tags: - "strategy" - "tech" - "ops" alternates: - locale: "en" url: "https://www.mikefluff.com/en/blog/build-vs-saas-7-questions" markdown: "https://www.mikefluff.com/en/blog/build-vs-saas-7-questions.md" - locale: "ru" url: "https://www.mikefluff.com/ru/blog/build-vs-saas-7-questions" markdown: "https://www.mikefluff.com/ru/blog/build-vs-saas-7-questions.md" - locale: "pt" url: "https://www.mikefluff.com/pt/blog/build-vs-saas-7-questions" markdown: "https://www.mikefluff.com/pt/blog/build-vs-saas-7-questions.md" - locale: "es" url: "https://www.mikefluff.com/es/blog/build-vs-saas-7-questions" markdown: "https://www.mikefluff.com/es/blog/build-vs-saas-7-questions.md" --- # Passamos sete meses construindo nosso próprio Intercom. Mãos ao alto, quem já fez isso > **Em resumo:** Construir faz sentido só para o core, aquilo pelo que o cliente paga. O resto se compra. Um time gastou sete meses e uns 4,5 milhões de rublos num chat próprio e acabou comprando o Intercom. Depois vêm mais seis perguntas sobre custo, API, sobrevivência do vendor, dados, grau de customização e a opção de montar com blocos prontos. 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*. > **Estimativa rápida** > > SaaS a $500/mês = $6k/ano. Dev mid-sênior no Brasil/Portugal — $40–60k/ano. > Para o build pagar, a task não pode ocupar mais de **10% do tempo do dev > por 5 anos**. Raro. **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.** --- > **Como eu decido em 15 minutos** > > 1. **É core?** Sim → build (ou blocos). Não → próximo. > 2. **Existe SaaS que cobre 80%?** Sim → próximo. Não → build. > 3. **Tem API? Vendor está vivo? Dados na jurisdição certa?** Três sim → SaaS. > Qualquer não → build. > 4. **Processo muito custom?** Sim → build ou blocos. Não → SaaS. --- 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. **[Falar sobre decisão arquitetural](https://www.mikefluff.com/pt#contact)** — Se build vs SaaS já dura três meses no seu time — venha, resolvemos com argumentos. Já vi os dois cenários, inclusive o fechamento de um build falhado em fase avançada.