Quando assumi o DAM em fevereiro de 2019, o projeto não estava atrasado: estava num beco sem saida. 5 gerentes de projeto já haviam passado, mais de 360 mil euros haviam sido gastos em licencas OpenText, prestadores integradores e gestao interna, e a plataforma servia apenas 20 pessoas onde deveria equipar os 1.400 funcionarios do Grupo Pichet. A direcao hesitava entre o abandono puro e a contratacao de mais um prestador - o que reproduziria o mesmo padrao de fracasso.

Recusei atacar a solução antes de reformular o problema. Com Stephanie L., a nova Diretora de Comunicação, colocamos 3 perguntas fundamentais antes de relancar qualquer coisa: qual resultado de negocio a plataforma deve produzir (eliminar a redistribuicao manual de assets, não apenas hospedar imagens), qual reversibilidade contratual e inegociavel (sair do SaaS sem lock-in), e com o que se parece um dia 90 bem-sucedido (um vendedor encontra sozinho seu visual de programa em menos de 2 minutos). Apenas depois de fixados esses 3 criterios, montei a metodologia de benchmark independente em 6 etapas e orientei a avaliacao para Bynder em vez de mais uma tentativa OpenText.

Bynder entrou em produção em 18 de novembro de 2020, 1.400 usuarios onboardados, contrato assinado com clausulas de SLA e reversibilidade travadas pelo nosso juridico. Onde 5 tentativas haviam falhado, o reframing entregou o projeto em menos de 2 anos por algumas dezenas de milhares de euros.

Esse metodo de reframing - reformular o problema antes de tocar a solução - virou um reflexo que rejogo hoje em cada missao de CTO advisory na ACCENSEO. A licao principal: um projeto em fracasso quase nunca têm um problema de solução, ele têm um problema de enunciado.

No final de 2025, Tailwind v4 foi lancado, completamente reescrito em Rust/Oxide. A única ferramenta de obfuscacao existente (unplugin-tailwindcss-mangle) dependia de patching dos internals do Tailwind - abordagem que quebrou imediatamente com a v4. Nenhuma solução compativel existia no mercado, e varias equipes que eu aconselho precisavam explicitamente dessa ferramenta para entregar seu design system. A janela era curta: 6 semanas antes que a comunidade recorresse a contornos ad hoc.

Tomei uma decisão contra-intuitiva: em vez de aplicar patches nos internals como o concorrente, apostei em análise estatica pura - escanear diretamente os arquivos fonte para identificar as classes usadas, sem depender de nenhum internal Tailwind. Isso significava apostar numa stack que eu nunca havia tocado: Babel AST para parsear JSX/TSX/Vue/Svelte/Astro/Qwik, PostCSS para transformar o CSS compilado, magic-string para substituicoes preservando sourcemaps, e 5 plugins de bundlers (Vite, Webpack, Rollup, esbuild, modulo Nuxt) compartilhando o mesmo motor central. Aprendi a stack em pair-programming com Claude Code, validando cada hipotese com testes.

6 semanas depois publiquei tailwindcss-obfuscator no npm: 82 mil linhas de TypeScript, 295 testes, 10 frameworks suportados, deteccao automatica de Tailwind v3 vs v4, monorepo TurboRepo. Primeira ferramenta compativel com Tailwind v4 no mercado, adotada por equipes externas nas primeiras semanas.

O que guardo não e a ferramenta, e o metodo: quando uma stack desconhecida está no caminho critico, você não contorna, você aprende - mas aprende por meio de testes, não de tutoriais. A mesma mecanica vai me permitir absorver Bun + edge runtimes amanha, ou qualquer stack que um futuro papel de CTO scale-up exija.

Quando comecei o SaaS contabil da ACCENSEO no inicio de 2025, eu conhecia bem o desenvolvimento full-stack mas não tinha qualquer expertise contabil formal. O dominio não perdoa aproximacoes: PCG, CGI, Código de comercio, EDI Teledec, DSP2 para Open Banking, mandato de e-fatura 2026-2027. Qualquer erro de calculo fiscal têm consequencia financeira direta para o cliente. E o horizonte não era flexivel: a conformidade e-fatura precisava estar pronta antes do fim de 2026.

Tratei a regulacao como uma spec de sistema, não como uma camada de negocio acessoria. Salvei as paginas chave do PCG, intercepei as respostas de API dos concorrentes, conduzi um estudo de mercado das plataformas de desmaterializacao e uma auditoria de seguranca dos SaaS existentes (que revelou falhas IDOR + KYC em varios atores). Depois mapeei as regras em modelos Prisma: 91 modelos, 63 enums, 6 papeis diferenciados (Admin, Colaborador, Consultor, Contador, Contabilidade, Banco). Para cada feature - VAT CA3, IS, CFE, CVAE, DAS2, PAS - escrevi a spec, depois scripts de verificacao para cada calculo, antes de encadear testes de nao-regressao sistematicos.

234 mil linhas de código entregues em solo, 42 features, 382 rotas API, integração 3 provedores Open Banking (GoCardless/Nordigen, Bridge, Qonto), envio EDI via Teledec, assistente IA multi-fornecedor (OpenAI, Claude, Gemini), conformidade e-fatura 2026-2027 atingida antes do prazo.

A adaptabilidade não apenas me ajudou a sobreviver - ela transformou um dominio regulado em moat de produto. E exatamente a postura que um CTO scale-up B2B em industria regulada (saude, financas, imobiliario institucional) e contratado para ter: provar que se pode absorver um quadro legal em meses e codifica-lo sem concessao.