Apruvly vs. construir seu próprio motor de aprovação: uma comparação objetiva

Quando faz sentido construir um motor de aprovação in-house e quando usar infraestrutura pronta. Critérios, esforço estimado e o que o Apruvly cobre hoje.

Apruvly vs. construir seu próprio motor de aprovação: uma comparação objetiva

A pergunta "não dá para construir isso internamente?" aparece em toda conversa com tech leads. A resposta honesta: depende do que aprovação significa para o seu negócio — produto central, requisito regulatório de isolamento ou apenas mais uma feature no roadmap.

Quando construir faz sentido

1. Aprovação é o produto. Plataformas de governance ou compliance cuja diferenciação é o próprio fluxo de aprovação precisam controlar o motor em profundidade. Infraestrutura externa complementa, mas não substitui o core.

2. Um único fluxo trivial e estável. Ex.: "todo PR precisa de um review no GitHub". Isso cabe em dezenas de linhas; não justifica integração externa.

3. Dados não podem sair do perímetro. Setores com restrição rígida de egress podem exigir deploy on-premises. O Apruvly oferece opção enterprise nessa linha (ver docs/onprem-shield.md), mas construir interno continua válido quando a política é "zero dependência de fornecedor cloud".

4. Time e roadmap de longo prazo para produto interno. Construir não termina no MVP: manutenção de integrações, edge cases de concorrência e suporte interno duram anos.

Se dois ou mais desses pontos se aplicam fortemente, construir pode ser a decisão correta.

Quando construir vira armadilha de escopo

Sintomas frequentes:

  • Aprovação é feature do produto, não o produto inteiro.
  • O roadmap já tem dezenas de itens que diferenciam você no mercado.
  • Engenharia estima "duas a três semanas" para o motor completo.

Na prática, a v1 costuma subestimar:

Componente Estimativa otimista Esforço realista (ordem de grandeza)
CRUD + estados dias ~1 semana
E-mail com templates dias ~1 semana
Slack (OAuth + bot + interação) dias ~2 semanas
Escalação por timeout dias ~1 semana
Webhooks com retry e SSRF dias ~1 semana
Multi-conta + permissões dias ~2 semanas
Idempotência / race / double-click dia ~1–2 semanas
UI ou designer semana semanas a meses
WhatsApp / Teams / SMS / … "depois" semanas por canal

Total realista para uma v1 utilizável: meses, não semanas — antes de manutenção contínua.

Onde o Apruvly compete bem

1. Tempo até a primeira aprovação real

Uma chamada POST /api/v1/workflow/ com config JSON válida coloca notificações, links de decisão e trilha em produção no mesmo dia — versus scaffolding de semanas in-house.

2. Multi-canal sem N integrações paralelas

Canais suportados como steps: email, slack, ms-teams, whatsapp, twilio-whatsapp, twilio-sms, telegram, discord, dingtalk. Cada um exige OAuth, templates, rate limits e retries próprios se construído do zero.

Gates por plano (resumo):

  • Twilio (SMS/WhatsApp): Starter+
  • Webhook do integrador na API key: Starter+
  • MCP para agentes: Growth+ ($59/mês)
  • SMTP próprio: Business+ ($149/mês)
  • Export consolidado de auditoria: Business+

3. Trilha para compliance

Cada workflow tem ID; cada aprovador recebe challenge UUID; decisões registram timestamp, aprovador, comentário e, conforme o plano, IP e user-agent. Export ZIP assíncrono em Business e Professional (/security/audit-export).

4. Concorrência e idempotência

Transições persistidas no Postgres com SELECT FOR UPDATE; segundo clique no mesmo challenge é rejeitado; replay de link antigo não duplica decisão.

5. Custo previsível

Modelo de créditos: 1 por destinatário notificado (detalhes em docs/pricing.md). Sem surpresa de "broadcast de 10 mil destinatários" se você modela o UnitCost antes de criar o workflow.

Onde construir in-house ainda ganha

  • Regras com lookup profundo no seu banco no momento da decisão, sem passar contexto via API.
  • Latência extrema dentro do mesmo processo (raro em aprovação humana).
  • Política de zero egress sem flexibilidade para on-prem gerenciado.
  • Motor já existente e estável — migrar por moda raramente compensa.

Dependência de fornecedor

O Apruvly expõe API REST estável; status e decisões são consultáveis e exportáveis; webhooks de retorno são HTTP padrão. Trocar de fornecedor exige trabalho — como com Stripe, SendGrid ou qualquer SaaS de infraestrutura. A alternativa in-house troca dependência de vendor por dependência do time que mantém o código.

Exercício de decisão (30 minutos)

  1. Liste os cinco fluxos de aprovação necessários nos próximos 12 meses.
  2. Para cada um: canais, escalação, trilha auditável, aprovador externo sem login.
  3. Estime esforço de eng para entregar e manter.
  4. Compare com Growth ($59/mês, 40k créditos, MCP) ou Business ($149/mês, export de auditoria, SMTP próprio).
  5. Some o custo de atrasar features que diferenciam seu produto no mercado.

Se a conta fechar para construir, construa. Se não, infraestrutura pronta libera o time para o que só o seu produto faz.

Testar antes de decidir

Plano Free: 180 créditos/mês, sem cartão. Rode um workflow real do seu domínio e compare com o escopo que vocês estimaram internamente.

apruvly.io