Dez 2025 · fintech cripto

13 apps em 70 dias.
Sozinho. Em produção.

Uma fintech cripto inteira: pagamento, câmbio e liquidação on-chain, com dinheiro real e segurança de banco central. O que uma equipe faria em um ano, uma pessoa entregou em 70 dias. Não pela IA. Pelo método que faz a IA construir certo.

o desafio

Uma plataforma de pagamento inteira. Sozinho. Em 70 dias.

O escopo não era um protótipo: gateway de pagamento PIX em conformidade com o banco central, um motor de câmbio OTC com preço determinístico, e liquidação on-chain na Liquid Network do Bitcoin. Ponta a ponta. Dinheiro real, compliance real, prazo real.

Um monorepo Turborepo de 13 aplicações: 3 APIs Fastify, 9 frontends Next.js e uma biblioteca de componentes, sobre 3 bancos PostgreSQL isolados (auth, pagamentos, câmbio), deployado em Kubernetes. Cada domínio carrega seus próprios modos de falha, e eles se compõem: uma premissa errada na camada de preço aparece depois, na liquidação, com o dinheiro do cliente em trânsito.

entregue em 70 dias, solo

13: apps em produção
138K: linhas de TypeScript
~1.650: testes automatizados
3: APIs · 3 bancos · K8s

Isso não é projeto que se improvisa numa janela de chat.

a tese

Spec primeiro. Prompt nunca.

Toda capability começou como uma especificação escrita, requisitos, design e tarefas, antes de existir uma linha de código. Não uma mensagem de chat. Um documento. A razão não é gosto pessoal: capacidade amplifica direção, não fornece direção.

A contraprova é desconfortável. Um estudo randomizado de 2025 (METR) mediu devs experientes trabalhando com IA em código real: ficaram 19% mais lentos, esperando ser 24% mais rápidos. Errados sobre o resultado, e sobre a própria percepção dele. A falha não é o modelo. É capacidade sem direção. Numa fintech multi-tenant com hooks de compliance, prompt-and-pray não te atrasa aos poucos: constrói algo que parece pronto, passa numa revisão rasa, e quebra quando chega o caso real, com o saldo de um cliente pendurado nele.

Quanto mais capaz o modelo, mais longe uma instrução vaga o leva na direção errada.

o método

Especifica, gera, verifica. E conserta a spec, não o código.

o loop de entrega, repetido por capability

Entrada

uma capability pra entregar (ex.: o motor de liquidação)

01Especificar
requisitos, design e tarefas escritos antes de uma linha de código, com aprovação humana antes de avançar. A spec é o contrato, não decoração.
02Gerar
o agente implementa contra a spec e escreve os testes junto. As 28 specs em 12 domínios entram como contexto no início de cada sessão.
03Verificar
revisão contra os critérios de aceite e o gate: Prettier, ESLint zero-warning, tsc estrito e ~1.650 testes contra um PostgreSQL vivo.
04Corrigir a spec
saída errada é spec errada. Conserta o documento e regenera. Nunca remenda o código deixando a spec pra trás.

Saída

merge, testado, deploy no Kubernetes

O passo 4 é onde mora a disciplina. Quando algo sai errado, o instinto é remendar o código e seguir. No scale, esse instinto é veneno: da próxima vez que o módulo for regenerado, o agente reconstrói pela spec e reintroduz o mesmo erro. As 28 specs e os 8 slash commands são a arquitetura do método, não do app: a memória externa que o agente não tem entre sessões.

A spec é a fonte da verdade. O código é o que cai dela.

os comprovantes

O que foi pra produção, não pro slide.

pra quem é dev e quer ver que é engenharia real, não vaporware:

em produção

Obrigatório:
Gateway de pagamento PIX4 provedores atrás de um factory pattern, incluindo integração bank-direct BACEN Cob v2 sobre mTLS. Webhooks assinados com HMAC-SHA256, fila de 6 tentativas com backoff. Idempotência garantida no banco, num UNIQUE(merchant_id, idempotency_key) na migration, não na aplicação.
Obrigatório:
Motor de câmbio OTCpreço VWAP em janela de 24h (só ativa com ≥5 trades confirmados), cross-rate de 5 fontes por mediana com filtro de outliers, spreads assimétricos por par. Toda conta em inteiros de 8 casas (satoshi): um float em qualquer campo de resposta é falha de teste, não warning.
Obrigatório:
Motor de liquidação on-chainpolling de depósito a cada 10s, confirmação de 2 blocos, auto-refund por tolerância acima de 10%, teto de auto-settle que transborda pra aprovação manual, commit atômico em 3 fases e recuperação de crash pra liquidações presas no meio.
Obrigatório:
Auth server OAuth 2.1 / OIDC5 papéis, 19 escopos, 18 permissões granulares, 2FA (TOTP), JWT via JWKS e tokens máquina-a-máquina com escopo por linha. Cada rota declara o escopo que exige no registro.
Obrigatório:
Plataforma e operaçãoKubernetes (DOKS, HPA 2-10, pods non-root), Terraform IaC e observabilidade Prometheus/Grafana/Loki com 23 métricas de negócio, não só de infra.

Stack

TypeScript
Fastify 5
Next.js 16
React 19
PostgreSQL
Drizzle ORM
Redis
BullMQ
Turborepo
Kubernetes
Terraform
Claude Code

não é demo

Produção deixa comprovante. Aqui estão os meus.

E um dado verificável por terceiros: durante a construção, uma contribuição de asset-registry e resolução de saldo foi enviada upstream pra Aqua Wallet (a carteira Liquid da Jan3), com 11 testes unitários, no PR #104. O código passou na revisão de outra pessoa, numa wallet de produção. Isso é uma prova diferente de um selo verde no seu próprio repo.

Nenhum desses números prova que o código é perfeito. Provam que ele foi construído contra um contrato, não improvisado.

o multiplicador

A IA escreveu o código. As decisões foram minhas.

"A IA escreveu o código" é literalmente verdade e quase irrelevante. A arquitetura foi decisão humana. O corpo de specs foi decisão humana. A definição de "pronto", os critérios de aceite que decidiam se uma saída estava certa ou se a spec tinha que ser reescrita, foi decisão humana.

Sem as specs, o agente é um pedreiro rápido sem planta. Com elas, é um engenheiro sênior com memória perfeita de cada decisão que você tomou. A distinção não é metáfora: aritmética de float em software financeiro não quebra alto, ela deriva. Pequenos erros de arredondamento se acumulam por operação, por trade, por cliente. A spec transformou isso numa falha de teste no dia 1. O agente não decidiu isso. A spec decidiu. O agente cumpriu.

A IA escreveu o código. A arquitetura, as specs e a decisão do que é “pronto” foram minhas. É essa a diferença entre um demo e um sistema por onde passa dinheiro de verdade.

sem hype

Onde o método não salva.

os limites honestos

Anti-padrão:
Ele externaliza expertise, não fabrica.as specs eram boas porque o operador já sabia o que pôr nelas: onde o float dá dor, como estruturar um fallback. Isso veio de 25 anos, não do método.
Anti-padrão:
Velocidade foi medida; qualidade não foi auditada.“13 apps em 70 dias” não diz nada sobre densidade de defeito em 5 anos. CI apertado e testes reais já enviaram sistemas ruins antes.
Anti-padrão:
Um prazo externo fazia trabalho real.a spec amplifica execução, não substitui urgência. O mesmo método em projeto pessoal, sem prazo, empacou.
Anti-padrão:
Produção não é um negócio.dinheiro em infra endurecida não é o mesmo que empresa com margem e fila de suporte. Isso prova um método de engenharia, não um mercado.

A resposta certa a esse case não é “SDD sempre funciona nessa escala”. É “SDD funcionou nessa escala, uma vez, pra esse operador”.

o que prova

O código se escreveu. As specs não.

Um agente não tem memória entre sessões. A spec é a memória externa que você dá pra ele. Isso não é opinião sobre uma ferramenta: é a realidade arquitetural de como esses sistemas funcionam. O case mostra que o mecanismo funcionou no scale. A mesma capacidade do modelo, com uma instrução vaga e com uma spec precisa, produz sistemas completamente diferentes. A spec é a única variável, e é a diferença inteira.

Foi aí que os 70 dias foram, e por isso bastaram. É o mesmo método que a Base25 ensina na Academy, no seu projeto, do primeiro spec ao deploy.

próximo case →3 clientes salvos em 30 dias, sem gastar em aquisição