MÓDULO 5 - AULA 18

Construir vs Comprar

Framework microeconômico para decisões "make or buy" no SaaS

Isocost analysis

Opportunity costs

35 min

🎯 Por que isso é importante

Decisões de build vs buy são as mais estratégicas que uma empresa SaaS toma. Construir tudo internamente consome tempo e capital. Comprar tudo externo limita diferenciação. A teoria microeconômica de isocost e opportunity costs fornece um framework racional para otimizar essas decisões, maximizando vantagem competitiva enquanto minimiza custos totais de ownership.

Fundamentos MIT: Curvas de Custo

🎓 Aula MIT: Cost Curves and Firm Production

Por que isso é importante: A teoria de custos do MIT explica como empresas decidem entre investir em recursos internos (labor) vs comprar soluções externas (capital). No SaaS, isso se traduz diretamente em decisões de build vs buy para cada componente do produto.

Taxonomia de Custos: Sunk, Fixed e Variable

Três Tipos de Custos em Decisões Build vs Buy

💸 Sunk Costs

Definição: Custos que nunca podem ser recuperados

Exemplos SaaS:

• Tempo gasto desenvolvendo
• Conhecimento técnico adquirido
• Código já escrito

❌ Irrelevantes para decisões futuras!

🏭 Fixed Costs

Definição: Custos fixos no curto prazo, mas recuperáveis

Exemplos SaaS:

• Servidores (podem vender)
• Licenças anuais
• Infraestrutura AWS

⚠️ Recuperáveis se mudar de estratégia

📊 Variable Costs

Definição: Custos que variam com produção

Exemplos SaaS:

• API calls (Stripe, Twilio)
• Compute por request
• Storage por GB

✅ Escaláveis com uso

💡 Exemplo MIT: Journey Concert Tickets

Cenário: Você pagou $250 por tickets para show da banda Journey. Depois descobriu que só gosta de 3 músicas. Quanto deveria cobrar para vender os tickets no StubHub?

❌ Raciocínio Incorreto (Humano)

"Paguei $250, preciso vender por pelo menos $250 para não ter prejuízo"

Erro: Considerando sunk cost

✅ Raciocínio Correto (Econômico)

"Quanto EU pagaria para ir a esse show AGORA? Se $0, vendo por qualquer valor acima disso"

Correto: Opportunity cost

Lição para SaaS: Tempo e dinheiro já gastos construindo algo internamente são sunk costs. A decisão de continuar ou migrar para solução comprada deve considerar apenas custos futuros e opportunity cost.

Opportunity Costs: O Custo Invisível de Construir

Por que "Grátis" Nunca é Grátis no Build vs Buy

📚 Exemplo MIT: Website Design Business

Cenário: Recém-formado no MIT inicia empresa de web design. Trabalha full-time + contrata programador por $40k/ano. Usa computador extra que tinha. Fatura $60k no ano.

📊 Análise Contábil (Errada)

Receita: $60k

Custos: $40k (programador)

Lucro: $20k ✅

🎯 Análise Econômica (Correta)

Receita: $60k

Custos explícitos: $40k (programador)

Opportunity costs: $100k (salário MIT)

Opportunity costs: $1k (venda do PC)

Prejuízo: -$81k ❌

Conclusão: Seu tempo trabalhando nessa empresa tem um custo de oportunidade. Você abriu mão de ganhar $100k em Big Tech. Isso é um custo real, mesmo que não saia dinheiro do bolso.

🏗️ Aplicação ao Build vs Buy no SaaS

Cenário: Construir Sistema de Autenticação Próprio

💸 Custos Explícitos (Visíveis):

• 2 devs sênior × 3 meses = $60k
• Infraestrutura/tools = $5k
• Security audit = $15k
Total explícito: $80k

👻 Opportunity Costs (Invisíveis):

• Features core não construídas
• Time-to-market atrasado 3 meses
• Revenue perdida: estimado $150k
Total opportunity: $150k

Custo Total Econômico: $80k + $150k = $230k

Comprar Auth0: $20k/ano (economiza $210k no primeiro ano!)

opportunity-cost-analyzer.js

Isocost Analysis: Otimizando Build vs Buy

Linhas de Isocost: Combinações Build-Buy com Mesmo Custo Total

📐 Conceito de Isocost no SaaS

Isocost Line: Combinações de "labor" (tempo de dev construindo) e "capital" (ferramentas/serviços comprados) que resultam no mesmo custo total.

Variáveis:

• L (Labor): Horas de dev building internamente
• K (Capital): Budget em ferramentas/APIs externas
• W (Wage): Custo por hora de dev ($100/hr)
• R (Rate): Custo de capital/ferramentas ($50/mo)

Equação Isocost:

C = W × L + R × K

Onde:

C = Custo total fixo desejado

Slope = -W/R (trade-off rate)

🎯 Tangency Optimization: Ponto Ótimo Build-Buy

Regra de Ouro: A combinação ótima de build vs buy ocorre onde a linha de isocost é tangente à "isoquanta de produção" (nível de features desejado).

Condição de Tangência:

MPL / MPK = W / R

Ou seja:

Produtividade marginal do dev building ÷ Produtividade marginal de ferramenta comprada

= Custo por hora dev ÷ Custo por mês da ferramenta

Interpretação Prática:

Se W/R = 2 (dev custa 2x mais que ferramenta), então no ótimo você quer que o dev seja 2x mais produtivo que a ferramenta comprada. Se não for, compre mais ferramentas e reduza tempo de dev.

isocost-build-vs-buy.js

Framework de Decisão: Build vs Buy

✅ Quando COMPRAR (Buy)

🎯 Critérios para Buy:

• Não é diferencial competitivo core
• Solução commodity (auth, payments, email)
• Time-to-market crítico
• Alto custo de manutenção se construir
• Requer compliance/certificações
• Economia de escala do vendor

📊 Exemplos Clássicos:

• Auth: Auth0, Clerk ($2k-5k/mês)
• Payments: Stripe ($0 + 2.9% + $0.30)
• Email: SendGrid, Postmark ($0.80/1k)
• SMS: Twilio ($0.0075/SMS)
• Monitoring: Datadog ($15/host/mo)

🛠️ Quando CONSTRUIR (Build)

🎯 Critérios para Build:

• Core business differentiator
• Nenhuma solução existente adequada
• Requisitos muito específicos
• Custo de APIs externas proibitivo
• Necessidade de controle total
• Vantagem competitiva significativa

📊 Exemplos Clássicos:

• Figma: Real-time collaboration engine
• Stripe: Payment processing core
• Notion: Block-based editor
• Linear: Issue tracking UX
• Vercel: Edge deployment system

Decisão Tree: Build vs Buy

🌳 Framework de Decisão Estruturado

Pergunta 1: É core differentiator?

• SIM: Considerar BUILD (70% peso)
• NÃO: Considerar BUY (70% peso)

Pergunta 2: Existe solução adequada no mercado?

• SIM, perfeita: BUY (90% peso)
• SIM, com gaps: Avaliar customização vs build
• NÃO: BUILD (necessidade)

Pergunta 3: Time-to-market é crítico?

• SIM, urgente: BUY (80% peso)
• NÃO, temos tempo: Avaliar custo total

Pergunta 4: Custo de oportunidade é alto?

• SIM: BUY e focar em core
• NÃO: Avaliar TCO total

Pergunta 5: TCO de comprar > 3x TCO de construir?

• SIM: BUILD (exceto se time crítico)
• NÃO: BUY

Cases Reais: Build vs Buy em Produção

Case Stripe: De Build para Buy (Payment Gateway)

📖 História da Decisão

Nos primeiros anos (2010-2012), Stripe construiu seu próprio payment gateway do zero. Em 2013, migraram para usar gateways existentes (Adyen, Cybersource) como camada inferior, focando em API superior.

❌ Problemas de BUILD:

• Compliance PCI DSS Level 1 custava $5M/ano
• Manter integração com 200+ bancos
• 15+ devs sênior dedicados a gateway
• Fraude detection reinventar a roda

✅ Benefícios de BUY:

• Terceirizar compliance para Adyen
• 15 devs focaram em API/UX superior
• Fraud tools best-in-class prontos
• ROI: economizaram ~$3M/ano

Resultado: Stripe cresceu de $100M para $7B ARR focando no diferencial (API), não na commodity (gateway).

Case Shopify: Build Próprio (Checkout Flow)

📖 Decisão de BUILD

Shopify construiu seu próprio checkout flow otimizado, em vez de usar third-party (WooCommerce, BigCommerce). Decisão custou $20M initial investment (2014-2016).

💸 Custos de BUILD:

• 25 devs × 2 anos = $10M labor
• A/B testing infrastructure = $3M
• Payment compliance = $5M
• Maintenance team ongoing = $2M/yr

✅ Retorno de BUILD:

• Conversion rate 15% maior (custom)
• $450M adicional em GMV/ano
• Diferencial vs competidores
• ROI: 22.5x em 3 anos

Resultado: Checkout próprio gerou $1.35B adicional em 3 anos vs investimento de $20M. Build foi a decisão correta (core differentiator).

Case Figma: Hybrid Approach (Build Core, Buy Support)

📖 Estratégia Híbrida

Figma construiu real-time collaboration engine (diferencial), mas comprou Auth, Payments, Email, Monitoring de vendors externos.

🛠️ BUILT (Core):

• Multiplayer engine: WebRTC + CRDT
• Vector editor: Canvas rendering
• Plugins system: Sandbox runtime
• Investment: ~$50M (3 anos)

🛒 BOUGHT (Support):

• Auth: Auth0 ($50k/ano)
• Payments: Stripe ($120k/ano)
• Email: SendGrid ($30k/ano)
• Total Buy: ~$200k/ano

Resultado: $50M em core diferenciado + $200k/ano em commodity = Valuation de $20B. Hybrid approach otimizou investment vs return.

🎯 Checkpoint de Aprendizado

Entendeu sunk costs vs fixed costs vs variable

Aplicou opportunity costs em decisões build vs buy

Otimizou com isocost e tangency condition

Usou framework de decisão estruturado

Analisou cases reais (Stripe, Shopify, Figma)

Calculou TCO total incluindo opportunity costs

💡 Principais Insights desta Aula

1. Sunk costs são irrelevantes: Tempo/dinheiro já gasto não deve influenciar decisões futuras
2. Opportunity costs são reais: Tempo construindo = não construindo features core
3. Isocost optimization: Tangência entre isocost e isoquanta minimiza custos totais
4. TCO > custo explícito: Incluir manutenção, opportunity e technical debt
5. Core vs commodity: Build diferencial competitivo, buy commodity
6. Hybrid é válido: Combinar build (core) + buy (support) otimiza ROI

Próxima aula

Cases Práticos