Dívida técnica em SaaS: quando aceitar, quando pagar e quando ela te mata

Todo founder técnico já ouviu "isso é dívida técnica, vamos refatorar depois." E todo founder já viu "depois" nunca chegar.

Dívida técnica em SaaS é inevitável. A questão não é evitar — é gerenciar conscientemente.

Quando é intencional e estratégica, dívida técnica é ferramenta de velocidade. Quando é acidental e ignorada, é bomba-relógio.

O que é dívida técnica (de verdade)

O conceito original de Ward Cunningham é diferente do que a maioria usa:

Dívida técnica original: você sabe como fazer certo, mas escolhe fazer rápido agora com intenção de refatorar depois. É decisão consciente com prazo mental.

Dívida técnica na prática: código ruim escrito por falta de tempo, conhecimento, ou descuido. Sem intenção de melhorar. Sem prazo. Só acúmulo.

O primeiro é estratégia. O segundo é problema.

Dívida técnica tem juros — quanto mais tempo passa sem pagar, mais caro fica. Feature simples que levaria 2 horas em código limpo leva 2 dias em código acumulado de dívida. Isso é juro composto negativo.

Quando acumular dívida intencionalmente faz sentido

1. Fase de validação (pré-PMF)

Você está testando se o mercado quer o produto. Não sabe ainda quais features vão sobrar, quais serão jogadas fora.

Fazer "certo" antes de saber o que é o produto é desperdício. Você vai refatorar de qualquer jeito quando descobrir o que é real.

Nessa fase, código que funciona e é rápido de modificar tem mais valor que código elegante e rígido.

O que aceitar: nomes de variável medíocres, sem testes automatizados, arquitetura flat sem abstrações, queries sem otimização.

O que nunca aceitar mesmo em validação: segurança (autenticação, SQL injection, dados de usuário), multi-tenancy quebrado (vazamento de dados entre clientes), sem backup de banco de dados.

2. Deadline hard externo

Cliente enterprise que assina se entregar feature X na semana que vem. Oportunidade real, prazo curto.

Você implementa da forma mais rápida possível, marca como // TODO: refactor, e entrega.

Condição: o TODO vira card no backlog no mesmo dia. Com estimativa de quando vai ser pago.

3. Experimento que vai ser deletado

Feature detrás de feature flag para teste A/B. Se não funcionar, deleta. Se funcionar, refatora antes de tornar permanente.

Código de experimento pode ser sujo porque tem prazo de vida curto.

Quando a dívida técnica vira problema real

Sinal 1: Velocity caindo mês a mês

Times que não gerenciam dívida entregam cada vez menos. O que antes levava 1 semana leva 3. Não é porque o time piorou — é porque o código ficou mais difícil de mudar sem quebrar outras coisas.

Se você está levando 2x mais tempo em features comparado a 6 meses atrás, dívida técnica é provavelmente causa.

Sinal 2: Bugs que você corrige voltam

Corrigiu o bug em um lugar, apareceu em outro. E em outro. Isso é sinal de acoplamento excessivo — mudança em uma parte do sistema quebra outras partes não relacionadas.

Sinal 3: Ninguém quer tocar determinada parte do código

"Esse módulo, não mexa." Todo time tem partes do código que ninguém quer pegar. Isso é dívida técnica coletiva. Quando features precisam passar por esse módulo, ficam travadas.

Sinal 4: Onboarding de dev novo leva semanas

Novo dev entra e leva 3-4 semanas para fazer a primeira mudança significativa. Em código saudável, dev competente está contribuindo na primeira semana.

Se onboarding é lento por causa de "tem que entender como funciona essa parte" — é dívida de compreensibilidade.

Sinal 5: Você tem medo de fazer deploy na sexta

Se o time evita deploy perto do fim de semana por medo de breaking change, é sinal de código frágil sem teste suficiente. Isso é dívida de confiança.

O framework para gerenciar

Categorize a dívida existente

Não tente resolver tudo de uma vez. Primeiro inventaria.

Categorias úteis:

Categoria	Exemplo	Urgência
Segurança	Autenticação fraca, SQL raw sem sanitização	Alta — resolve agora
Performance	Query sem index em tabela de 1M rows	Alta se afeta usuário
Arquitetura	God class com 3.000 linhas	Média — planeja
Testes	Zero coverage em módulo crítico	Média — planeja
Legibilidade	Nomes confusos, sem documentação de decisão	Baixa — no backlog

Foca no que está causando problema real hoje. Não no que ofende esteticamente.

O 20% rule

Reserva 20% da capacidade de engineering para dívida técnica todo sprint. Não negocia com produto.

Sem reserva, dívida nunca é paga — sempre tem feature urgente. Com reserva, o juro não acumula.

Times que fazem isso consistentemente reportam velocity estável ou crescente. Times que não fazem veem velocity cair mês a mês.

Refactor como parte de feature, não separado

Em vez de sprint dedicado de "refactor" (que raramente acontece), incorpora refactor na feature que precisa passar por aquela área.

"Precisa implementar feature X no módulo Y? Aproveita pra limpar os 200 linhas de função que não tem sentido."

Isso é o chamado "leave the campsite cleaner than you found it". Você não refatora o módulo inteiro — melhora um pouco cada vez que passa por ele.

Quando fazer o refactor big-bang

Às vezes a dívida é grande demais para incremento. Você precisa de rewrite ou refactor estrutural.

Critérios para justificar:

1. Impacto em velocity: a dívida está causando >30% de lentidão estimada no time
2. Risco de segurança: a arquitetura atual tem vulnerabilidade que não dá pra corrigir incrementalmente
3. Escala: a arquitetura atual não aguenta o volume projetado em 12 meses

Como fazer sem parar o produto:

Strangler Fig Pattern: substitui o módulo ruim por um novo progressivamente, sem parar de funcionar. A nova implementação vai "estrangulando" a antiga até substituir completamente.

// Antes: legado
async function processPayment(data: any) {
  // 300 linhas de código legado com dívida
}

// Durante: novo módulo ao lado do legado
async function processPaymentV2(data: PaymentRequest): Promise<PaymentResult> {
  // implementação limpa
}

// Feature flag: novos clientes usam V2, legado ainda ativo para antigos
async function processPayment(data: any) {
  if (featureFlags.usePaymentV2) {
    return processPaymentV2(data);
  }
  // código legado
}

// Depois de migração completa: remove legado

O que nunca aceitar como dívida

Alguns tipos de dívida têm risco assimétrico — pequena chance de acontecer, consequência enorme se acontecer.

Segurança:

• SQL injection: um ataque pode vazar todos os dados
• Senha em plaintext: uma exposição de banco quebra confiança irreversível
• Multi-tenancy quebrado: dado de cliente A visto por cliente B = fim do SaaS

Dados de usuário:

• Sem backup automático: perda de dados de cliente é catástrofe
• Sem migração segura de schema: pode corromper dados em produção

Autenticação:

• JWT sem expiração: tokens roubados são válidos para sempre
• Sem rate limiting em login: permite força bruta

Essas não são dívidas que você paga "depois". Dívida de segurança que explode mata SaaS em semanas.

A conversa difícil com founders não-técnicos

Se você é co-founder técnico com co-founder de negócio, essa conversa vai acontecer:

"Por que precisamos de 2 semanas de refactor? Não podemos adicionar a feature logo?"

A analogia que funciona:

"Imagina uma loja que não limpa o estoque há 2 anos. Pra achar qualquer produto, leva 30 minutos. Pra receber mercadoria nova, precisa reorganizar tudo. O 'refactor' é limpar o estoque. Parece custo, mas é o que mantém a velocidade."

Dívida técnica não é assunto técnico — é assunto de negócio. Velocity caindo 30% é 30% menos features, 30% menos velocidade de resposta a mercado, 30% menos competitividade.

A gente na Alienhub constrói SaaS com arquitetura que escala — e ajuda times a gerenciar dívida técnica de forma estratégica, não reativa. Se você está sentindo que o produto está ficando preso na própria dívida, bora bater um papo.