case-study
13 apps em 70 dias: o case da cripto fintech que provou que SDD escala (com 1 engenheiro)
13 aplicações em 70 dias, sozinho, com SDD. APIs Fastify, OAuth federada, Pix multi-PSP e OTC engine sobre Liquid Network. O case e o que NÃO prova.
13 aplicações. 70 dias. Solo. Em produção, com dinheiro real fluindo.
Esse é o case que mais virou citação no canal nos últimos meses — e também o mais mal-entendido. Esse artigo é a versão honesta: o que entreguei, a stack, o método que destravou, e o que esse case não prova (mais importante que o que prova).
Quem prefere ouvir falando, tem o vídeo (o “ADEUS N8N” cobre parte da história). Aqui vai a versão escrita, com mais detalhe técnico.
O contexto
Em dezembro de 2025 fui chamado pra construir do zero a plataforma técnica de uma fintech cripto brasileira focada em OTC (Over-the-Counter — operações com tickets grandes via mesa, fora de exchange pública) sobre a Liquid Network (sidechain do Bitcoin com confidencialidade de valores e tokens nativos).
Cliente queria:
- Plataforma multi-tenant operacional em produção em ~3 meses
- Integração completa com Pix (incluindo as variações de cada PSP brasileiro)
- OTC com pricing dinâmico, KYC/compliance, OAuth federada com identity providers externos
- 13 aplicações distintas (admin panel, customer app, mesa de operação, settlement engine, monitor, etc.) — todas em um monorepo
Solo. Eu, com agentes de IA guiados por spec.
O que foi entregue (70 dias depois)
| Componente | Detalhe |
|---|---|
| Monorepo | 13 apps em Turborepo (Next.js admin/customer, dashboards, mesa de op, monitor, settlement, etc.) |
| APIs | 3 servidores Fastify, todos com auth OAuth 2.1/OIDC federada |
| Bancos de dados | 3 PostgreSQL multi-tenant (segregação por workspace) |
| Infra | Kubernetes em produção (não Heroku, não Vercel — k8s mesmo) |
| Pagamentos | Integração Pix completa com 4 PSPs diferentes (cada um com sua particularidade técnica) |
| OTC engine | VWAP pricing sobre Liquid Network com settlement automático |
| Open source | PR #104 mergiado na Aqua Wallet (carteira Liquid da Jan3) — prova auditável externa |
Dinheiro fluindo desde semana 9. Não foi protótipo.
O método que destravou: Spec-Driven Development
Eu não programei mais rápido. Eu especifiquei melhor.
Cada uma das 13 apps começou com uma sequência idêntica:
1. /spec-new <feature> ← cria estrutura .claude/specs/XXX/
2. /spec-requirements ← agente pergunta, eu respondo, vira EARS
3. [gate humano] aprovo requirements
4. /spec-design ← agente propõe arquitetura, Prisma, endpoints
5. [gate humano] aprovo design
6. /spec-tasks ← agente quebra em tasks de 2-4h
7. [gate humano] aprovo tasks
8. /spec-implement <task-id> ← agente codifica, eu revisoA IA fazia o trabalho braçal (escrever código, sugerir Prisma models, esboçar endpoints). Eu fazia a decisão — qual feature, qual arquitetura, qual trade-off, qual stack pra qual problema.
O que esse padrão eliminou:
- Retrabalho por requisito mal entendido (a spec era o briefing congelado)
- Drift entre sessões (o agente lia o
.claude/e continuava do ponto certo) - Code review eterno (revisor compara código vs spec, não código vs preferência pessoal)
- “Esqueci o porquê” 3 semanas depois (a spec era a memória)
Aprofundamento completo: Spec-Driven Development — o método completo
A stack escolhida (e por quê)
Não dá pra recomendar essa stack pra qualquer projeto — foi tuned pro problema. Mas vale documentar as decisões:
| Camada | Escolha | Por quê |
|---|---|---|
| Monorepo | Turborepo | caching, workspace deps, build paralelo de 13 apps |
| Frontend (3 apps publicas) | Next.js 14 App Router | server components reduzem JS no cliente; mature ecosystem |
| Frontend (10 apps internas/admin) | Next.js + shadcn/ui | tooling consistente, reduz cognitive load |
| Backend | Fastify (não Express) | 2-3× mais rápido, TypeScript-first, schema validation nativa |
| ORM | Prisma | type-safety, migrations, multi-tenant via row-level security |
| Auth | OAuth 2.1/OIDC com identity provider externo | compliance, escalável, não reinventei roda |
| Real-time | Socket.io | rooms (workspace isolation), fallback polling, reconexão automática |
| Queue | BullMQ | retry, delayed jobs, rate limit, dashboard |
| Pagamentos | 4 PSPs Pix integrados (não usei “agregador”) | cada PSP tem caso de uso/custo diferente; agregador adiciona latência |
| Cripto | Liquid Network via aqua-wallet-sdk + nó próprio | confidencialidade nativa, settlement em ~2 min |
| Infra | Kubernetes (DigitalOcean) | controle de custo + escalabilidade vertical pra OTC |
| CI | GitHub Actions com cache Turborepo | builds < 4 min mesmo com 13 apps |
O que cortei explicitamente (e perguntam muito):
- Não usei microsserviços puros — modelei como modular monolith com APIs públicas. Microsserviço prematuro custa 3× mais que ganha
- Não usei GraphQL — REST + tRPC pros consumers internos. Performance, simplicidade
- Não usei Vercel — Kubernetes pra controle de custo previsível em volume OTC
O que o case PROVA
1. SDD escala vertical com operador experiente. Um único engenheiro sênior consegue saída comparável a um time de 5-8 engenheiros sem IA, no mesmo prazo. O multiplicador não foi a IA. Foi a spec.
2. Stacks complexas se tornam tratáveis.
A combinação fintech + cripto + multi-tenant + auth federada + compliance exige normalmente meses de design. SDD comprime esse design em specs lidas e executadas iterativamente.
3. Open source viabiliza credibilidade técnica. O PR #104 da Aqua Wallet (Jan3) ancora o trabalho em ecossistema externo verificável. Não é “trust me bro” — é commit auditável.
O que o case NÃO prova (importante)
Esse é o lado que ninguém quer ler. Vou ser honesto:
Não prova generalização pra qualquer dev
Eu tenho 25+ anos de engenharia. Expertise prévia em fintech (TUI Group, 20M clientes em produção). Integração enterprise (Solvay). Treinei 30k+ pessoas em workflows técnicos.
SDD potencializa um operador já maduro. Falta evidência de que recupera quem ainda está construindo o modelo mental do domínio. Se você está aprendendo TypeScript e tentando rodar claude --spec-design, vai dar errado — porque você não consegue revisar o que o agente sugere.
A próxima evidência crítica não é outro feito meu. É alunos da Academy construindo coisas em escala, com seus próprios bagagens.
Não prova zero-bug
13 apps em 70 dias diz nada sobre:
- Densidade de defeitos pós-launch
- Dívida técnica acumulada
- Facilidade de manutenção 6 meses depois
Velocidade ≠ qualidade. O case fala em time-to-production, não em MTBF (mean time between failures).
Não prova viabilidade comercial
Ter código em produção ≠ ter receita sustentável. Ponto cego do case. Cliente tem que provar mercado, retenção, unit economics. Eu entreguei a plataforma técnica — o resto é tese deles.
Não prova que eu sustento esse ritmo
Houve custo pessoal. Sono tardio crônico nas últimas semanas, irritação documentada no meu diário operacional. Não é fórmula sustentável pra 12 meses contínuos. Foi sprint, não maratona.
A pergunta que ficou
Em abril/2026 eu mesmo perguntei, num áudio reagindo aos dados:
“Se eu fiz o crypto fintech liquid em 70 dias, por que muitos dos meus projetos próprios não saíram do papel?”
Não tenho resposta padrão ainda. Hipótese de trabalho: presença de deadline externa real (cliente pagando, sistema crítico) vs. ausência de deadline em projetos próprios.
Se confirmada, sugere que SDD potencializa execução dado operador maduro + pressão externa real. Sozinha, não dispara em vacuum interno.
Implicação pra quem quer reproduzir: o método sozinho não substitui accountability. Clientes, cohorts, deadlines reais são variável de primeira ordem, não secundária. Por isso a Academy é cohort com revisão semanal — não curso self-paced.
O que aprendi sobre IA aplicada (que mudou meu canal e a Base25 toda)
Esse case foi o que me fez parar de vender n8n como oferta principal. Não porque n8n é ruim — eu usaria de novo se fizesse sentido. Mas porque a parte cara é a decisão, não a configuração.
Quando você pode entregar 13 apps em 70 dias com IA guiada por spec, sua oferta deixa de ser “implemento workflow X” e passa a ser “decido qual o problema certo + entrego solução em escala”. Isso vale 10× mais.
Manifesto completo: workflow virou commodity
O método em detalhe: Spec-Driven Development
Próximos passos
Se você quer aprender SDD aplicado em projeto real (com revisão na mão):
→ Formação Consultor AI — Academy
Se você quer só estudar o método antes de decidir:
→ Ebook SDD (gratuito com email)
Perguntas frequentes
Posso ver o código do crypto fintech? Não — é proprietário do cliente. Mas o PR #104 da Aqua Wallet é auditável publicamente (anchor verificável). E o método SDD que destravou está totalmente aberto no ebook gratuito.
Quantas horas/dia trabalhei nos 70 dias? Média ~10-12h/dia, picos de 14h em sprints específicos (settlement engine, integração 4º PSP). Não sustentável long-term. Documentado no diário operacional.
Quanto custou em ferramentas de IA? Claude Code (200 USD/mês), GitHub Copilot enterprise (~20 USD/mês), 1 API key OpenAI pra fallbacks de feature específica (~50 USD total no período). Total ~660 USD em 70 dias pra construir 13 apps em produção. Esse é o ROI que ninguém quer enxergar.
Por que Liquid Network e não Lightning ou L2 Ethereum? Liquid foi escolha do cliente (OTC com confidencialidade de valor importa pra mesa institucional; Lightning não tem confidencialidade nativa; L2 Eth tem custo de gas + UX pior pra non-crypto users).
Você usou TDD?
Sim, em ~40% dos módulos (testes escritos junto com implementação via /spec-implement). Não 100% — em alguns módulos de UI/admin priorizei velocidade sobre teste exaustivo. Trade-off consciente.
Stack vai funcionar pro meu SaaS? Provavelmente não. Esse stack foi escolhido pra fintech multi-tenant com OTC. Pro seu SaaS, comece pelo problema, monte Driver Tree, e a stack vira óbvia depois. Como precificar e estruturar projeto de IA.
Vai ter case de outros projetos? Sim. Os 12 SaaS em 12 meses que vou construir publicamente (documentado na Library + canal) é exatamente isso — cada SaaS vira case + repo aberto onde der.