A Harmo fez seis anos. Escrevo como co-founder e CTO sobre o que custou caro construir: tratar pilares Drive-to-Store como um sistema único em vez de quatro produtos costurados, processar +300 mil avaliações e +10 milhões de pesquisas por mês em mais de +60 mil lojas, e por que time e arquitetura são a mesma coisa. Decisões técnicas, lições de gestão e o diferencial que só aparece quando você constrói infraestrutura/plataforma, não feature.

Case real de um incidente AWS: uma regressão sutil em uma lambda fez uma Step Function reinvocar a mesma tarefa por quatro madrugadas. A conta do mês saltou quase 6x (mesmo com AWS Cost Anomaly Detection habilitado). Como contivemos, como negociamos a concessão com a AWS via Infomach e TD Synnex, e quais guard rails entraram em pé. Case público para que outros times não descubram essa categoria de falha do mesmo jeito que a gente descobriu.

Depois de um incidente em que a conta AWS sangrou por 76 horas sem ninguém perceber, construí um CronJob no EKS que roda toda manhã, puxa o Cost Explorer, detecta anomalia com regra simples e abre task no ClickUp. Arquitetura, código e as decisões que pouparam dor.

Construí um dashboard TUI multi-host pra acompanhar uso da minha subscription Claude rodando em laptop, desktop e servidor de casa ao mesmo tempo, sem expor o token OAuth. Inspirado no Clawdmeter, posicionado contra ccusage. Conta como pensei a arquitetura, os tradeoffs, e por que decidi publicar mesmo já existindo opção parecida.

Em 30 dias dentro do Claude Code entreguei o equivalente a quatro meses de roadmap. O custo equivalente em tokens (USD 8.069 num plano fixo de assinatura) é só dimensão. O que importa é o que saiu do outro lado.

Como IRSA funciona no EKS, o que mudou com Pod Identity, quando preferir um sobre o outro, e um bug real: AccessDeniedException causado por webhook de Pod Identity não instalado no cluster.

Goroutines, channels, fan-out/fan-in, worker pool com errgroup e cancelamento via context. Os patterns de concorrência que realmente aparecem em código de produção.

Por que single-row inserts matam performance em alta frequência, como estruturar batch inserts corretamente, e a semântica do ON CONFLICT DO NOTHING vs DO UPDATE, com benchmarks reais.

Um incidente real no Aurora PostgreSQL: load spikes, sequential scans em tabelas grandes, índices mortos e inserts single-row em alta frequência. Como diagnosticamos em minutos e quais ações reverteram o quadro.

O Claude Code não tem sync nativo entre máquinas. Comparo três abordagens (git + symlinks, chezmoi e Syncthing), mostro o pega das memórias path-encoded e dou uma recomendação pragmática.