Escalar uma fintech sem reinventar o core é um dos problemas mais subestimados do mercado financeiro brasileiro. Segundo reportagem do Terra.com.br sobre o crescimento das fintechs, o que está separando empresas que crescem de forma saudável daquelas que travam em planilhas e controles manuais é exatamente a camada de tecnologia de gestão — e isso, para quem programa, é onde mora o ouro (e também onde mora a maioria dos bugs críticos em produção).
O crescimento sem stack é só acumulação de risco
Na minha experiência construindo sistemas para empresas de crédito e meios de pagamento, vejo o mesmo padrão se repetir: a operação comercial cresce, o time de engenharia é chamado tarde demais, e quando chega já tem três planilhas compartilhadas, dois ERPs paralelos e um webhook que “funciona às vezes”. O relatório Fintech Report 2024, citado na matéria do Terra, mostra que o Brasil concentra a maior quantidade de fintechs da América Latina — ou seja, a competição não está só no produto, está na engrenagem interna.
A fala do Rodrigo Mendes, CEO da Pegcard, resume o que eu chamo de inflexão tecnológica: “se a gestão continua sendo feita de forma manual ou em sistemas desconectados, o risco de erros cresce junto”. Em termos de engenharia, isso significa débito técnico operacional — e em fintech, débito técnico vira prejuízo direto, não um simples refactor agendado para o próximo sprint.
O que uma plataforma de gestão financeira realmente precisa resolver
Quando uma fintech decide centralizar sua operação (como a Pegcard fez com o Pegsystem), ela está, na prática, construindo três coisas que quase nunca vêm prontas em SaaS genérico:
- Camada de orquestração de propostas e contratos — onde o estado da operação muda constantemente e precisa ser auditável.
- Painel de parceiros — cada parceiro comercial precisa de uma visão isolada, com permissões granulares e métricas próprias.
- Motor de indicadores — não BI decorativo, mas indicadores operacionais que alimentam decisão em tempo real.
Em projetos meus, sempre que algum cliente pede “um sistema igual ao da concorrência”, eu respondo a mesma coisa: você não quer um sistema, você quer substituir cinco processos manuais por um fluxo determinístico e rastreável. A diferença parece sutil, mas muda completamente o desenho da arquitetura.
Na Prática: um esqueleto de orquestrador de operações financeiras
Para ilustrar o tipo de decisão técnica que aparece quando você constrói algo como o Pegsystem, vou mostrar um esqueleto minimalista de um serviço que centraliza o ciclo de vida de uma proposta de crédito, com eventos imutáveis (essencial para auditoria em fintech).
from dataclasses import dataclass, field
from datetime import datetime
from typing import List
from enum import Enum
import uuid
class StatusProposta(Enum):
CRIADA = "CRIADA"
EM_ANALISE = "EM_ANALISE"
APROVADA = "APROVADA"
REJEITADA = "REJEITADA"
CONTRATADA = "CONTRATADA"
@dataclass(frozen=True)
class EventoProposta:
proposta_id: str
tipo: str
payload: dict
autor: str
timestamp: datetime = field(default_factory=datetime.utcnow)
@dataclass
class Proposta:
cliente_id: str
valor: float
status: StatusProposta = StatusProposta.CRIADA
eventos: List[EventoProposta] = []
def aplicar(self, evento: EventoProposta):
# Validação de transição de estado aqui
self.eventos.append(evento)
class Orquestrador:
def __init__(self):
self.propostas = {}
def criar(self, cliente_id: str, valor: float, autor: str) -> str:
pid = str(uuid.uuid4())
proposta = Proposta(cliente_id=cliente_id, valor=valor)
proposta.aplicar(EventoProposta(
proposta_id=pid, tipo="CRIADA",
payload={"valor": valor}, autor=autor
))
self.propostas[pid] = proposta
return pid
def transicionar(self, pid: str, novo_status: StatusProposta, autor: str):
p = self.propostas[pid]
p.status = novo_status
p.aplicar(EventoProposta(
proposta_id=pid, tipo=f"STATUS_{novo_status.value}",
payload={}, autor=autor
))
# Aqui dispara webhook para parceiro + atualiza dashboard
Esse é o coração de qualquer plataforma desse tipo: estado + eventos imutáveis. Nada de UPDATE direto no banco. Cada mudança vira um evento que pode ser reproduzido, auditado e usado para reconstruir o histórico. É exatamente o que o Rodrigo Mendes aponta como “rastreabilidade” na entrevista ao Terra.
Erros Comuns que devs cometem ao construir (ou comprar) sistemas de gestão para fintech
Depois de alguns anos quebrando a cabeça nesse tipo de projeto, listei os erros que mais aparecem em code review, em produção ou em chamada de incidente às 3h da manhã:
- Usar o banco de transações para relatórios: ERP e CRM compartilham schema, queries lentas derrubam o core. Separe leitura de escrita desde o dia 1 (CQRS).
- Confiar em integração por planilha: cada parceiro mandando Excel por e-mail é um vetor de ataque e um bug esperando para nascer. Exija API ou webhook.
- Não versionar regras de aprovação: política de crédito muda o tempo todo. Se a regra está hardcoded, você vai auditar proposta errada por meses.
- Esquecer idempotência: webhook do parceiro vai cair e ser reenviado. Se o seu endpoint não é idempotente, você cobra duas vezes. Esse bug paga meu boleto há anos.
- Tratar permissões como afterthought: em fintech, o parceiro A nunca pode ver dados do parceiro B. Se você não modela isso na primeira migration, vira um Frankenstein de filtros SQL.
Por que “comprar” um SaaS pronto quase nunca resolve
Recebo com frequência a pergunta “Yuri, por que não usar Salesforce/HubSpot/Pipedrive e pronto?”. Resposta curta: porque fintech tem ciclos regulatórios, trilhas de auditoria e lógicas de comissão que SaaS genérico não entende. Você acaba configurando 300 campos customizados e nenhum relatório funciona como deveria.
Quando a Pegcard decidiu construir o Pegsystem internamente, segundo a reportagem, foi exatamente porque “continuar crescendo exigia mais do que ampliar a equipe”. Traduzindo para linguagem de engenharia: o custo de adaptação do SaaS genérico era maior do que o custo de construir e manter a plataforma própria. Esse cálculo vale ouro em qualquer decisão de build vs. buy.
Implicações práticas para quem está programando hoje
Se você é dev e trabalha (ou quer trabalhar) em fintech, três habilidades vão te diferenciar em 2026:
- Modelagem de eventos e event sourcing: o mercado financeiro vive de auditoria, e audit-friendly vira diferencial de carreira.
- Conhecimento regulatório mínimo: não precisa virar advogado, mas entender LGPD, BACEN e Open Banking te coloca em outro patamar de conversa com o time de produto.
- Observabilidade financeira: logs e métricas pensados para valores em R$, não só para HTTP status. É outro jogo.
FAQ — Perguntas que devs reais fazem sobre construir sistemas de gestão para fintech
Qual stack é mais comum em fintechs brasileiras hoje?
Na prática, vejo muito Python (FastAPI) + PostgreSQL no core, Node.js ou Go em serviços auxiliares, React/Next.js no front e Kafka ou RabbitMQ para eventos. Nada disso é obrigatório, mas é o que o mercado contrata.
Vale a pena usar event sourcing em sistema de gestão?
Vale quando você precisa de auditoria forte e reprocessamento. Para um CRM interno simples, é overkill. Para um core de crédito, é praticamente mandatório.
Como evitar o problema de parceiro ver dados de outro parceiro?
Row-level security no banco + filtros obrigatórios no ORM + testes automatizados simulando o ataque. Nunca confie só no filtro do controller.
Construir plataforma própria vs. comprar SaaS: como decidir?
Regra que uso: se a regra de negócio muda toda semana e o SaaS não tem API para isso, construa. Se o processo é estável e commodity, compre.
Qual o maior erro técnico em fintech?
Esquecer idempotência e reconciliação. Não é cache, não é performance — é a integridade financeira. Quem domina isso, domina o jogo.
Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.