DEV Community: Matheus Morett

Redis is the ceiling: why I built bullmq-outbox

Matheus Morett — Sun, 20 Sep 2026 14:42:56 +0000

In April 2025 I went out for a barbecue lunch. I came back, opened the dashboard, and something had degraded in production.

I am the CTO of Monest, a debt collection company built on AI. The shape of our business is simple. A debtor sends a message saying they want to negotiate, we queue it, an agent drafts a response, we reply. Messages come in through a webhook. Everything after the webhook is BullMQ.

That afternoon we were processing messages far slower than they were arriving. The queue backed up. Waiting jobs piled up in Redis. And Redis filled.

A full Redis does not slow down. It refuses. queue.add() rejected, the webhook returned an error, and the message was gone. Not delayed. Gone. There was nothing to retry, because nothing had ever been written down.

We were losing negotiations. That is the part that matters. We were not dropping jobs. We were dropping people who were trying to pay us.

The flaw is not a bug

I like BullMQ a lot. We run it in production and we are not moving off it. But it has one property you have to design around.

Redis is the ceiling.

Every job you have not processed yet lives in RAM. Your backlog and your memory limit are the same number. So anything that widens the gap between arrival rate and processing rate walks you toward that limit:

A slow downstream dependency. Consumers get slower, waiting grows, memory grows.
One oversized payload. Someone ships a job carrying a whole document instead of an id, and a queue that used to cost kilobytes now costs megabytes.
A traffic spike you did not plan for.

Payload guards catch the cases you thought of. Alerts tell you after waiting is already large, which is exactly when you have the fewest options.

And the obvious answer, "put it on a cluster", does not do what people assume it does.

Redis Cluster does not split a queue

This is worth spelling out, because it is the most common reply to this problem and it is wrong in a specific way.

BullMQ lays a queue out as a set of keys sharing one qualified name: bull:orders:wait, bull:orders:meta, bull:orders:id, bull:orders:<jobId>, and so on. Its operations are Lua scripts, and a single add touches several of those keys at once. The wait list, the counter, the job hash, the marker.

In Redis Cluster, a Lua script may only touch keys that live in the same hash slot. So every BullMQ-on-Cluster setup gives the queue a hash tag. You name it {orders} instead of orders, which forces all of its keys onto one slot.

That is what makes it work. It is also what caps it.

A hash slot is not divisible. It lives on exactly one node, in that node's memory. So Cluster distributes queues across nodes. It never distributes one queue across nodes.

The consequence is not that you have a bigger ceiling. It is that you have several smaller ones, and a queue is bound to whichever one it landed on:

The limit for a queue is the memory of the single node holding its slot, not the memory of the cluster.
One hot queue can fill its node while the rest of the cluster sits nearly empty. The cluster is fine. Your queue is not.
Adding nodes does not help the queue that is in trouble. Resharding moves whole slots. It cannot move half of one, so the queue lands somewhere else, intact, with the same problem.

Cluster raises your total capacity and changes nothing about the failure you actually hit. The ceiling for any given queue is still a single machine's RAM. When you reach it, the enqueue fails and the job disappears, because the queue is the only place that job ever existed.

That is the part worth fixing.

What I built that afternoon

The fix is old and boring, which is why it works. An outbox.

If the write to the queue fails, write the job somewhere else, somewhere with a different failure domain, and put it back when the queue recovers.

I wrapped our queues so that every add() had a catch. On failure, the job went to DynamoDB: queue name, job name, payload, options, status PENDING. A cron ran every 15 minutes, read the pending rows, and re-enqueued them through the real queue.

Three details decided whether this actually worked.

The original error is still thrown. The outbox buys you a replay, not a lie. The caller still finds out the enqueue failed and still decides what to tell the user.

Job options are preserved. jobId, attempts, backoff, all serialized and restored on replay. Without jobId, replay is not idempotent and you trade lost jobs for duplicated ones.

The recovery loop does not share the failure it is recovering from. This is the one people get wrong. Our scheduler runs on a separate, dedicated Redis. A drain loop living inside the Redis that just died never fires, and you find out on Monday.

One more thing, learned the hard way. Set reserved-memory-percent on your Redis parameter group. A Redis at 100% of maxmemory does not fail cleanly. It hangs, and BullMQ hangs with it, because maxRetriesPerRequest: null is required by the framework and ioredis will retry forever. Reserving a slice makes the OOM arrive as an error you can actually catch. An outbox that never receives an error is not an outbox.

Also, not every queue should be captured. We excluded the real-time conversation queues. A chat turn replayed fifteen minutes later is worse than one never sent.

Then it paid for itself

Some time later, a regression shipped. One specific queue started writing payloads larger than planned, past the payload guards we already had. Those guards existed. It happened anyway.

The Redis backing that queue hit its limit again.

And nothing happened.

Everything that failed to enqueue went to DynamoDB. The cron picked it up and replayed it. No lost jobs, no lost negotiations, no incident call.

The difference between April and that day was not that we had gotten better at preventing a full Redis. We had not. The difference was that hitting the ceiling stopped being a data-loss event and became a latency event.

That is the whole argument. You will not prevent every one of these. You can decide what one costs you.

Why it is a package now

The Monest version was tied to things you do not have: NestJS, DynamoDB, our module structure. So I rewrote it as bullmq-outbox.

import { createOutbox } from 'bullmq-outbox';
import { Queue } from 'bullmq';

const outbox = createOutbox({ store: myStore });
const emails = outbox.wrapQueue(new Queue('emails'));

// Behaves exactly like the queue you passed in, until Redis says no.
await emails.add('welcome', { userId: 1 });

Then drain from somewhere with its own failure domain:

const result = await outbox.flush(50);
// { requeued: 12, failed: 0, skipped: 3, expired: 0 }

Design decisions worth stating, because they are the opinionated part.

Zero dependencies. It does not even import bullmq. The wrapper is structural, so v5, v6 and BullMQ Pro all work from one build. wrapQueue is a Proxy, not a subclass, for the same reason: groups, batches and every other method pass straight through.

No storage adapters ship with it. Your outbox belongs in a database you already operate and already back up. You write four functions: save, loadPending, markProcessed, markFailed. Working Postgres, Redis, MongoDB and DynamoDB implementations live in examples/ as files to copy, each with its schema.

It is not a broker. Redis stays the queue. This is a fallback, and it should stay boring.

The integration tests break a real Redis for real. maxmemory is set just above current usage, so writes are rejected with the same OOM command not allowed error ElastiCache throws. A fake queue can prove the logic. It cannot prove the package survives the thing it exists for.

The number to watch

Not the count of replayed jobs. The age.

onJobRequeued gives you ageMs, how long that job sat in the outbox before it made it back. That is your real recovery time, and it is the number that tells you whether the fallback is working or quietly filling up. A count of 40 tells you nothing. Forty jobs with an average age of four hours tells you your drain is broken.

Which, of course, is easier to see when you can actually see your queues. If you want the best tool on the market to watch BullMQ jobs, use Bullpane. Self-hosted.

npm install bullmq-outbox · GitHub

If you fan one event out to many queues, bullmq-fanout composes with it. Wrap your queues first and the fan-out inherits the durability.

Talk is cheap: high-agency e a técnica do 1-3-1

Matheus Morett — Sat, 08 Aug 2026 13:54:41 +0000

Desde o início da minha carreira eu sempre fui uma pessoa muito ambiciosa. No dia 1 do meu primeiro emprego eu já entrava na empresa pensando: o que funciona bem aqui, o que não funciona, e como eu posso me destacar? Aquela proatividade clássica de estagiário que quer vencer na vida.

O problema é que, conforme o tempo foi passando, eu percebi uma coisa desconfortável: eu era muito mais um reclamão do que um resolvedor de problemas.

Até que um dia eu ouvi do meu chefe:

Talk is cheap.

O que eu não estava enxergando

Eu conseguia ver mil ineficiências na empresa. E minha visão afunilada só sabia produzir um pensamento: "meu Deus, vou reclamar, não é possível que ninguém vê isso".

Hoje, na posição em que estou, liderando uma área de tecnologia com mais de 50 pessoas, eu sei exatamente o motivo de ninguém estar "vendo".

Todo mundo via. Só não era prioridade.

Você não consegue garantir eficiência máxima em tudo ao mesmo tempo. Você precisa escolher as batalhas que vai comprar. No fim, o que interessa é o DRE mostrando resultado positivo, margem controlada, custo sob controle. E, na fila de prioridades, aquela ineficiência que o Matheus estagiário e o Matheus júnior enxergavam era pouco relevante diante do cenário macro.

Isso não significa que ela não era importante. Significa que, diante de todos os problemas que uma diretoria precisa resolver, aquele não era o prioritário naquele momento.

E aqui está a virada de chave: a diretoria não precisava de mais alguém apontando o problema. Precisava de alguém disposto a resolvê-lo sem consumir a atenção dela.

Quando eu ouvi "talk is cheap" do meu CEO, a mensagem era clara: você reclamar disso toda semana comigo não vai mudar nada. Você pensar e aplicar uma solução é o que vale.

Hoje, mesmo ocupando a liderança máxima de tecnologia, eu preciso tomar o mesmo cuidado — não floodar o CEO com reclamações inúteis. E pra isso eu mantenho duas técnicas sempre na cabeça.

Técnica 1: o 1-3-1

Em vez de chegar reclamando de alguma coisa, você chega com:

1 problema — claro, com impacto mensurável
3 possíveis soluções — com trade-offs honestos
1 recomendação — qual você executaria agora, com as informações e condições que você tem

O efeito disso na cabeça de quem te ouve é enorme. Você deixa de soar como "tem um problema, resolve pra mim" e passa a soar como:

Estou vendo um problema, mas pode ficar tranquilo com as suas prioridades, porque eu já pensei e vou executar uma solução. Você concorda com a direção?

Hoje, atuando como diretor, isso é música pros meus ouvidos. E, com certeza, essa pessoa fica marcada na minha cabeça quando aparece uma vaga de liderança ou uma área nova pra alguém assumir.

Um exemplo concreto

Ruim:

"Nosso pipeline de CI tá insuportável, demora 40 minutos, ninguém aguenta mais."

1-3-1:

Problema: o CI leva 40min por PR. Com ~60 PRs/semana, isso são ~40h de espera por semana no time, e a galera parou de rodar a suíte localmente porque virou hábito "deixa o CI pegar".

Opções:

Paralelizar a suíte em 4 workers — corta pra ~12min, custo de runner sobe ~R$ 800/mês, 2 dias de trabalho.

Rodar só os testes afetados por diff no PR e a suíte completa no merge — corta pra ~6min, mas exige mapeamento de dependências e tem risco de falso negativo.

Subir a máquina do runner — corta pra ~25min, custo sobe ~R$ 1.500/mês, meio dia de trabalho.

Recomendação: opção 1. Melhor relação ganho/risco, reversível, e não depende de refactor. Começo quinta se não houver objeção.

A segunda versão não é mais longa por capricho. Ela transfere o trabalho cognitivo de quem decide pra quem propõe, que é exatamente o ponto.

Técnica 2: cultura high-agency

A outra coisa que me ajudou muito foi entender a pirâmide de high-agency e onde eu estava nela.

Do chão pro topo:

Espera mandarem. Executa quando pedem.
Pergunta o que fazer. Identifica que tem algo errado e devolve a decisão.
Recomenda e espera aprovação. Aqui mora o 1-3-1.
Age e reporta imediatamente. Decide, executa, comunica na sequência.
Owner. Age dentro do seu domínio e reporta na cadência normal, porque a confiança já está estabelecida.

O topo da pirâmide é o owner: a pessoa que age e depois reporta qual foi a ação e o resultado. É um passo mais arrojado que o 1-3-1, e tem muito mais valor, mas só funciona se a sua empresa de fato empodera uma cultura de "peça desculpas, não permissão".

Se sua empresa tem essa cultura, é definitivamente o que eu recomendo.

Como escolher entre 1-3-1 e owner

A régua que eu uso é simples: qual o custo de estar errado?

Porta de duas mãos (reversível — feature flag, refactor interno, mudança de processo do squad): aja. Reporte depois. Nível 4 ou 5.
Porta de uma mão (difícil ou caro de desfazer — migração de banco, contrato, mudança que impacta cliente, decisão de arquitetura estrutural): use 1-3-1. Alinhe antes.

Confundir os dois é o erro mais comum dos dois lados. Gente sênior pedindo permissão pra coisa reversível trava o time. Gente agindo sozinha em porta de uma mão gera incidente.

O que isso muda quando você está do outro lado da mesa

Aqui é onde a coisa fica interessante pra quem lidera.

Se você é diretor ou liderança, isso muda como você desenha a burocracia da sua empresa.

A diretoria nunca vai ter olhos pra tudo. E uma ineficiência que parece irrelevante lá de cima pode ser um baita gargalo pra operação no dia a dia. Então qual é o pior papel que você pode assumir?

Ser o gargalo que impede pessoas high-agency de brilhar.

Se toda melhoria precisa passar por você, você acabou de transformar o seu calendário no teto de crescimento da empresa. As pessoas boas vão tentar duas ou três vezes, esbarrar na fila de aprovação, e voltar pro nível 1 da pirâmide. Aí você olha o time e pensa "por que ninguém toma iniciativa aqui?".

Criar uma cultura com controles de qualidade, mas sem burocracia que desencoraje a ação é fundamental pro time evoluir sozinho. Na prática, isso significa trocar aprovação prévia por trilho:

Decisões estruturais viram RFC/ADR — documento público, discussão assíncrona, decisão registrada.
Qualidade vira automação — review, testes, lint, limite de tamanho de PR — e não uma pessoa de plantão pra dizer "pode".
Domínio tem dono explícito, então a pessoa sabe onde ela tem autonomia total e onde ela precisa alinhar.

A regra que eu tento seguir: controle na saída, não na entrada. Você não pede permissão pra tentar, você garante que o que sai tem qualidade.

Por que isso é ainda mais crítico em empresa crescendo

Pra empresa em crescimento isso é vital, porque é exatamente através desses movimentos que surgem as novas lideranças.

Área nova sendo criada precisa de alguém pra guiar. E adivinha quem você escolhe? Não é quem reclamou mais alto. É quem já vinha operando como owner sem ninguém mandar.

Na Monest a gente saiu de um time de tecnologia com 10 pessoas em janeiro de 2025 para mais de 50 em junho de 2026. Construir uma cultura data-driven, com controle de qualidade e sem burocracia, foi essencial pra gente conseguir crescer otimizando eficiência e não virar uma máquina de reuniões de aprovação.

Fechando

Se você está no começo da carreira e enxerga mil coisas erradas onde trabalha: parabéns, você tem o olho. Falta a segunda metade.

Escolhe uma. A que mais dói. Monta o 1-3-1. Leva.

E se você lidera: olha pro seu processo e pergunta honestamente quantas decisões reversíveis ainda estão passando por você. Cada uma delas é uma pessoa high-agency esperando na fila.

Talk is cheap. Sempre foi.

Você não vai mais entregar código. Você vai entregar times que entregam código.

Matheus Morett — Sun, 22 Feb 2026 21:26:39 +0000

Quando você é dev, você controla a qualidade do que sai das suas mãos. Se algo vai pra produção com seu nome, você garante que tá do jeito que você quer.

Quando você vira Head, isso muda. Você não entrega mais código. Você entrega times que entregam código.

E isso dói.

O desespero de ver "diferente"

No começo, eu olhava as entregas e ficava desesperado. Via um PR e pensava "eu teria feito diferente". Via uma arquitetura e pensava "não era assim que eu faria".

A tentação era meter o dedo em tudo. Microgerenciar cada decisão, cada IF, cada nome de variável.

Cheguei a fazer isso. Não escala. Você vira gargalo, o time para de pensar sozinho, e você não consegue fazer seu trabalho de verdade.

Deixar o time aprender

Teve PR que eu vi débito técnico. Nada crítico, mas débito claro. Deixei. Queria ver se o time ia perceber sozinho.

Percebeu. Corrigiu no sprint seguinte. Sem eu precisar falar nada.

Claro que tem coisa e coisa. Se fosse algo crítico, eu teria intervindo. Mas parte de escalar é saber onde dá pra deixar o time aprender sozinho.

Seu papel é criar o sistema. Não é operar o sistema.

Como a gente fez na Monest 💜

Pra escalar qualidade sem microgerenciar, a gente criou camadas de proteção:

Automação. Lint, tipagem, padrões de código. Se dá pra automatizar, a máquina cobra.

AI como guardiã. Dezenas de guidelines alimentam um agente interno. A mesma AI revisa PRs e O approve dela é obrigatório. Se você programa com AI, ela já faz no padrão Monest.

RFC antes, ADR depois. Feature grande passa por RFC no GitHub, aprovada por Tech Lead. Depois da entrega, ADR documenta as decisões. A AI tem contexto do começo ao fim.

Documentação que respira. Pilares de engenharia no Notion. E um documento que todo mundo conhece: "O que um dev na Monest faz bem?!". Soft-skills, hard-skills, expectativas claras. Dev, Tech Lead, Data Engineer, cada função tem o seu.

Rituais e cultura. Engineering All-Hands, Post-Mortems, Tech Talks internas. Nada disso funciona se o time não compra a ideia. A cultura é a última linha de defesa.

A surpresa

Quando você constrói esse sistema e essa cultura, uma coisa inesperada acontece.

Você para de ver entregas "diferentes". Você começa a ver entregas melhores do que você faria.

Hoje tenho lideranças técnicas e engenheiros entregando muito melhor do que eu faria.

Seu papel é garantir que a barra de qualidade seja alta. O time faz o resto. E te supera.

A lição

Meu papel não é mais entregar código. É construir o sistema que permite 40+ pessoas entregarem no nível que a Monest precisa.

Se eu ainda quisesse controlar cada linha, a gente ainda seria 12.

Esse é o sexto post de uma série sobre lições que aprendi no meu primeiro ano como Head de Tecnologia. Semana que vem tem mais.

Contratando para áreas que você não domina

Matheus Morett — Sun, 08 Feb 2026 14:36:16 +0000

Tenho 10 anos de experiência em tecnologia. Nove deles foram como desenvolvedor ou tech lead. Sempre perto de código.

Quando você vira Head de Tech, isso muda. De repente você precisa gerenciar e guiar áreas que nunca foram suas. E uma das primeiras que me pegou foi segurança da informação.

A Monest 💜 é uma empresa de cobrança com AI. Processamos dados de milhares de devedores todo mês. Ser seguro aqui não é diferencial, é requisito.

Quando entrei, a segurança era terceirizada. Funcionava, mas eu queria alguém interno. Alguém que vivesse o dia a dia da operação, que conhecesse nossos sistemas, que pudesse construir uma cultura de segurança de dentro pra fora.

Eu precisava montar essa área. Contratar a primeira pessoa. Estruturar.

O problema: eu mal sabia a diferença prática entre blue team e red team. Como eu ia julgar se um candidato era bom se eu não entendia o trabalho que ele ia fazer?

Pedindo ajuda

Fui conversar com o Alexandre Neto, CTO renomado e um dos investidores da Monest. Expliquei minha dor: precisava acertar nessa contratação, mas não tinha base técnica pra avaliar.

Ele me deu um panorama do que buscar na posição. E fez algo ainda mais valioso: me conectou com o Ricardo Barbosa, Coordenador de Segurança do Bradesco, com quem ele já tinha trabalhado.

O Ricardo me ensinou o que esperar de um profissional de segurança. E participou da entrevista comigo.

Um mês depois, contratamos o Paulo Roberto. Ele se candidatou pra vaga e foi o selecionado.

Hoje, quase um ano depois, o Paulo estruturou a área de segurança internamente. Junto com a Gabriela Lemes, responsável pela LGPD, passamos por 22 due diligences de segurança de clientes em 2025. Estamos caminhando cada vez mais perto da ISO 27001.

O modelo que funcionou

Esse não foi um caso isolado. Usei o mesmo modelo pra estruturar a área de Dados. Busquei mentores externos que conheciam o que eu não conhecia.

O padrão é simples:

Reconhecer que você não sabe. Parece óbvio, mas o ego atrapalha. A tentação é fingir que dá conta sozinho.

Buscar quem sabe. Não precisa ser um consultor pago. Pode ser um investidor, um contato de rede, alguém que você admira. A maioria das pessoas topa ajudar se você pedir direito.

Trazer pra dentro do processo. Não é só pedir conselho. É pedir pra participar da entrevista, validar o perfil, revisar o escopo da vaga.

A lição

Virar Head de Tech não significa que você precisa dominar tudo. Significa que você precisa garantir que as áreas estejam bem estruturadas, mesmo as que você não entende.

E a melhor forma de fazer isso é se cercar de gente que sabe mais que você.

Pedir ajuda não é fraqueza. É estratégia.

Esse é o quinto post de uma série sobre lições que aprendi no meu primeiro ano como Head de Tecnologia. Semana que vem tem mais.

As melhores pessoas precisam saber que você existe

Matheus Morett — Sun, 01 Feb 2026 22:39:47 +0000

Muita gente acha que líder técnico não tem que ficar postando em rede social. Que isso é coisa de influencer, de quem quer vender curso.

Eu pensava parecido. Até perceber uma coisa:

Se a empresa tem a visão correta, a cultura correta, e você fornece meios pros seus desenvolvedores performarem, o que muda o jogo é a qualidade do seu time.

Ferramentas, processos e metodologias importam. Mas quem faz tudo isso funcionar são as pessoas

E o melhor jeito de ter as melhores pessoas é fazendo com que elas queiram trabalhar com você.

A pergunta é: como essas pessoas vão saber que você existe?

Como eu contratei um Tech Lead pelo Twitter

Durante o ano de 2025, eu postei no meu Twitter sobre desafios técnicos que a gente passava na Monest 💜. Coisas reais. Problemas de escala, decisões de arquitetura, erros que a gente cometeu.

Nada polido. Nada pensado pra viralizar. Só o dia a dia de quem tá construindo produto.

Um desses posts chegou no Samuel. Ele tem 10k+ seguidores no Twitter, é referência técnica na bolha dele. Viu o que a gente tava fazendo e pensou: "esses caras devem estar fazendo uma coisa legal."

Ele veio falar comigo.

Hoje o Samuel é Tech Lead na Monest 💜, liderando nossa frente de canais (Voz e WhatsApp).

Não teve recruiter. Não teve vaga publicada no LinkedIn. Conteúdo real atraiu talento real.

E o Samuel não é o único. Tem outras pessoas que trabalham hoje na Monest 💜, ajudando a gente a revolucionar o mercado de cobrança todo dia, que vieram de relacionamentos feitos na internet.

Por que isso funciona

Os melhores profissionais que eu conheço não ficam procurando vaga. Eles estão trabalhando, aprendendo, e observando.

Observando quem tá resolvendo problemas interessantes. Quem pensa de um jeito que faz sentido pra eles. Quem trata o time de um jeito que eles gostariam de ser tratados.

Quando você posta sobre como resolve problemas, como pensa sobre arquitetura, como lida com erro, você tá mostrando quem você é como líder. Sem filtro de processo seletivo, sem discurso de página de carreiras.

E isso atrai gente que se identifica com o jeito que você trabalha. Gente que já chega alinhada.

Não é sobre viralizar

Não precisa ter milhões de seguidores. Não precisa fazer post todo dia. Não precisa virar influencer.

É sobre ser visível na sua comunidade técnica.

Postar aquele problema que você resolveu. Compartilhar uma decisão que deu certo ou errado. Contar o que você tá aprendendo.

Isso já é suficiente pra que as pessoas certas te encontrem.

O livro que me fez levar isso a sério

Li no "The Engineering Executive's Primer" do Will Larson que como líder, sua rede é seu ativo mais importante. Não só pra trocar ideias com outros líderes, mas pra construir o time que você precisa.

Eu sempre soube disso intuitivamente. Mas ver escrito me fez parar de tratar rede social como opcional.

A lição

Você pode ter a melhor visão, a melhor cultura, o melhor produto. Mas quem constrói tudo isso são as pessoas.

E as melhores pessoas precisam saber que você existe antes de querer trabalhar com você.

Isso não é vaidade. Isso é estratégia.

Esse é o quarto post de uma série sobre lições que aprendi no meu primeiro ano como Head de Tecnologia. Semana que vem tem mais.

O medo de ficar pra trás

Matheus Morett — Sun, 25 Jan 2026 14:10:46 +0000

Você também sente que está ficando pra trás porque todo mês surge uma tecnologia nova?

Em janeiro de 2025, eu tinha acabado de assumir como Head de Tecnologia da Monest 💜. Tinha budget pra dobrar o time, um esboço de planejamento, e uma pergunta na cabeça: onde alocar essa galera nova?

1 mês antes, a Anthropic havia lançado o MCP.

Meu LinkedIn explodiu. "O futuro da integração de AI." Todo mundo falando. Todo mundo implementando. Todo mundo menos a gente.

A Monest é uma empresa de AI. E a gente não tinha MCP.

Bateu a ansiedade. Será que eu deveria parar tudo e colocar o time pra explorar isso?

A pergunta que me acalmou

Me forcei a pensar: o MCP invalida nossa estratégia, ou é algo que dá pra incorporar depois?

Era a segunda opção.

Seis meses depois, implementamos MCP. Mas não como produto principal.

Nossos Biz Devs usam pra consultar insights da operação de cobrança.

Inovamos onde fazia sentido, e o resto da energia foi pra escalar nossa AI de cobrança, onde crescemos 4x a quantidade de conversas por Voz e WhatsApp em 2025.

Se eu tivesse parado tudo em janeiro, nada disso teria acontecido.

Nenhuma tecnologia se consolida do dia pra noite

React foi lançado em 2013. Só em 2015 que Netflix e Airbnb adotaram. Virou mainstream em 2016. Três anos.

Docker foi lançado em 2013. Em 2017, adoção em empresas era 20%. Só em 2021 passou de 90%. Oito anos.

Tecnologia muda as coisas. Mas no ritmo dela, não no ritmo do hype.

Não é pra ignorar o novo

Não tô dizendo pra fingir que tecnologia nova não existe. Tô dizendo pra dosar.

O que funciona pra mim:

Separar sinal de ruído. Se pessoas que eu respeito estão falando de algo, presto atenção. Se só tem post patrocinado e tutorial raso, ignoro.

Estudar antes de implementar. Fiz POCs de MCP internamente antes de decidir onde usar.

Perguntar: isso resolve um problema real nosso agora? MCP não resolvia nosso problema de janeiro. Ia criar trabalho novo sem entregar valor imediato.

A lição

A ansiedade de ficar pra trás é real. Mas a maioria das tecnologias leva anos pra se consolidar.

Você tem tempo.

Inovar não é adotar tudo primeiro. É saber onde colocar energia pra gerar resultado de verdade.

Esse é o terceiro post de uma série sobre lições que aprendi no meu primeiro ano como Head de Tecnologia. Semana que vem tem mais.

O delay entre esforço e recompensa

Matheus Morett — Sun, 18 Jan 2026 15:20:07 +0000

Na vida real, você não faz uma quest e já ganha a recompensa.

Em jogos, você mata o monstro e o loot cai na hora. No TikTok, você scrolla e a dopamina vem em segundos. Mas quando você tenta mudar cultura ou processo numa empresa, o ciclo é outro: meses entre o esforço e o resultado.

O alerta que salvou o dia

Em fevereiro, o time começou a implementar alertas customizados de monitoramento no New Relic. Não foi glamouroso. Foi trabalho chato de configurar thresholds, pensar em cenários de falha, escrever mensagens de alerta que fizessem sentido.

Dois meses depois, em abril, um desses alertas disparou no final da manhã. Nossas recebimento de mensagens tinha ficado fora do ar.

Detectamos na hora. Corrigimos em 15 minutos.

Sem aquele alerta, só descobriríamos horas depois. Milhares de negociações perdidas. Clientes frustrados tentando fazer acordos e não conseguindo.

O trabalho de fevereiro só mostrou valor em abril. E se nada tivesse quebrado, talvez o time nunca percebesse o quanto aquele esforço valeu.

Os números que demoraram pra aparecer

Entre janeiro e fevereiro, implementamos processos de post-mortem, melhoramos code review e introduzimos testes automatizados.

Sabe quando vimos o impacto real? Em agosto.

Tickets de bugs caíram de 20% para 10% do esforço de desenvolvimento. Metade.

Seis meses entre plantar e colher.

O dev que foi entendendo aos poucos

No começo do ano, comecei a insistir com o time sobre a importância de logs bem feitos. Como usar o New Relic direito. Como pensar em observabilidade desde o início.

Tinha um dev que ouvia, fazia o básico, mas não tinha clicado ainda.

Com o tempo, ele foi percebendo que a vida ficava mais fácil quando os logs estavam lá. Que debugar produção virava minutos em vez de horas. Que ele dormia mais tranquilo.

Não teve um momento de virada. Foi aos poucos. Meses até virar natural.

Isso é o oposto de dopamina rápida. É investimento de longo prazo em alguém.

Por que isso é difícil

Esse delay causa ansiedade em todo mundo.

O CEO pergunta "cadê o resultado daquele processo novo?". O time questiona "pra que perder tempo com isso?". E você mesmo fica se perguntando se tá no caminho certo.

A tentação é abandonar o processo antes de validar. Ou mudar tudo porque não viu resultado em duas semanas.

O que funcionou pra mim

Três coisas:

Clareza de propósito. Se você não sabe por que tá fazendo algo, não vai aguentar esperar o resultado. Antes de implementar qualquer mudança, eu preciso conseguir explicar em uma frase por que aquilo importa.

Medir os pequenos ganhos. O resultado final demora, mas sinais aparecem no caminho. Um deploy que não quebrou. Um bug que foi pego antes de ir pra produção. Um dev que fez a pergunta certa. Esses sinais mantêm o time engajado.

Paciência. Não tem atalho. Às vezes você só precisa esperar.

A lição

Mudança de cultura não funciona no ritmo de TikTok. Funciona no ritmo de plantação: você planta, cuida, espera, e torce pra chover na hora certa.

Os frutos chegam. Mas não no tempo que a ansiedade quer.

Esse é o segundo post de uma série sobre lições que aprendi no meu primeiro ano como Head de Tecnologia. Semana que vem tem mais.

Como tirar o mindset de early-stage sem criar burocracia

Matheus Morett — Sun, 11 Jan 2026 05:04:06 +0000

Como tirar o mindset de early-stage sem criar burocracia

Quando entrei na Monest como Head de Tecnologia, o time de tech tinha 12 pessoas. Um ano depois, somos 35.

Esse crescimento muda tudo. Processos que funcionavam com 12 pessoas simplesmente quebram com 35. O problema é que ninguém percebe na hora. O time continua operando do mesmo jeito, até que algo estoura.

E quando você tenta mudar, ouve a frase que todo líder de tech conhece: "mas sempre foi assim".

O desafio real

O difícil não é identificar o que precisa mudar. O difícil é mudar sem transformar a empresa numa máquina burocrática que demora 3 semanas pra fazer um deploy.

Startup vive de velocidade. Se você cria processo demais, mata o que fez a empresa chegar até ali.

O que mudamos

Vou dar quatro exemplos concretos de coisas que implementamos e que geraram atrito inicial:

Testes e2e obrigatórios. Antes não tinha. O time testava na mão, ou não testava. Com 12 pessoas, todo mundo conhecia o sistema inteiro e sabia o que podia quebrar. Com 35, ninguém tem essa visão completa. Testes e2e viraram obrigatórios.

Tipagem real no TypeScript. Nosso "TypeScript" era JavaScript com extensão .ts. Qualquer coisa era any. Isso funcionava quando todo mundo sabia o que cada função esperava. Não funciona mais. Escrevi sobre como eliminamos 4.041 erros de TypeScript em 6 meses nesse artigo.

Observabilidade como regra. Implementamos New Relic em tudo. Antes, quando algo dava problema em produção, era um detetive tentando reproduzir o erro localmente. Agora a gente sabe exatamente o que aconteceu, onde, e por quê. Com 12 pessoas, dava pra perguntar "quem mexeu nisso?". Com 35, você precisa de dados, não de memória.

RFC pra features novas. Antes, alguém tinha uma ideia e começava a codar. Agora, se é algo que muda o rumo do produto, precisa de um documento mínimo explicando o que, por que, e como. Não precisa ser longo. Mas precisa existir.

Nos quatro casos, a reação inicial foi a mesma: "mas antes não precisava".

Como convencer sem impor

A resposta pra "antes não precisava" não pode ser "agora precisa porque eu mandei". Isso não funciona e cria ressentimento.

O que funcionou pra mim foi mostrar dados. Não opinião, não "melhores práticas", não "em empresa séria é assim". Dados.

Depois de um ano com essas mudanças, nossos números mostram:

50% menos tickets de suporte
36% menos post-mortems no Q4 comparado ao Q1, mesmo com o time quase 3x maior e fazendo 80+ deploys por semana

Quando você mostra que a "chatice" gerou resultado concreto, a conversa muda.

Onde não exagerar

Tão importante quanto saber o que implementar é saber onde parar.

Exigimos testes e2e, mas não exigimos 100% de coverage.
RFC pra feature nova, mas não pra bugfix.
Tipagem correta, mas com migração gradual.

A pergunta que me faço antes de criar qualquer processo novo: "isso vai ajudar o time a entregar melhor, ou só vai dar mais trabalho?"

Se a resposta for só mais trabalho, não implemento.

A lição

Crescer dói. O jeito que funcionava antes vai parar de funcionar, e você vai precisar convencer pessoas a mudar algo que elas não veem como problema.

O equilíbrio é: criar processos que protegem a empresa sem criar burocracia que trava a empresa.

Não existe fórmula. É tentativa, erro, e prestar atenção nos resultados.

[Boost]

Matheus Morett — Fri, 05 Dec 2025 21:31:39 +0000

Sam

Dec 5 '25

How I made BeeThreads and what doest it solve

#showdev #ai #node #performance

3 min read

Como Eliminamos 4.041 Erros de TypeScript em 6 Meses

Matheus Morett — Mon, 10 Nov 2025 20:38:44 +0000

Quando assumi como Head de Tecnologia da Monest em janeiro de 2025, me deparei com um cenário que muitos times de engenharia conhecem bem: TypeScript configurado com strict: false. Na prática, isso significava que nosso "TypeScript" era apenas JavaScript com extensão .ts — sem as verdadeiras garantias de tipo que tornam o TypeScript valioso.

O problema era simples de identificar: código como object.value onde object poderia ser undefined passava tranquilamente no build, só para explodir em runtime. Mas a solução? Essa era outra história.

O Desafio: 4.041 Erros de Uma Vez

Quando finalmente ativamos strict: true para avaliar a situação, fomos recebidos por uma parede vermelha no VSCode: 4.041 erros de TypeScript.

Ninguém consegue resolver 4.041 erros do dia para a noite. E mesmo que conseguisse, o risco de quebrar funcionalidades críticas em produção — especialmente em uma startup de cobrança por IA como a Monest — era inaceitável.

Precisávamos de uma estratégia diferente.

Nossa Abordagem: Migração Gradual e Sustentável

1. Strict em Dev, Permissivo em Prod

A primeira decisão foi aparentemente contraditória, mas fundamental:

✅ strict: true em desenvolvimento — para que os erros aparecessem na nossa cara enquanto editávamos arquivos
⚠️ strict: false em deploy — para que a build funcionasse mesmo com erros pendentes

Isso nos deu visibilidade do problema sem bloquear o time ou comprometer entregas.

2. Uma GitHub Action para Criar Accountability

Criamos uma GitHub Action que contava os erros de TypeScript a cada PR. A regra era simples: cada PR precisava reduzir pelo menos 1 erro.

Não importava se você estava trabalhando em uma nova feature ou em um bugfix — você tinha que resolver ao menos um débito técnico de TypeScript. Sem exceções.

3. A Regra de Ouro: Produção em Primeiro Lugar

Estabelecemos uma regra de ouro para guiar decisões difíceis:

"O sistema funciona em produção. Na dúvida entre alterar o código ou o tipo, altere o tipo."

Essa diretriz foi crucial. Em vez de tentar "corrigir" código que funcionava (e potencialmente introduzir bugs), priorizamos ajustar as definições de tipo para refletir a realidade do código existente. Refatorações podiam vir depois, quando entendêssemos melhor cada parte do sistema.

Nem tudo foi perfeito nessa jornada. Tivemos um deploy que acabou quebrando produção — ironicamente, o erro foi justamente fazer o oposto da nossa regra de ouro: confiamos no tipo (que estava errado) em vez do código (que funcionava). Foi um lembrete valioso de que tipos são ferramentas para nos ajudar a entender o código, não verdades absolutas sobre ele.

Esse incidente reforçou ainda mais a importância da nossa abordagem cautelosa e incremental.

4. Visibilidade e Celebração do Progresso

Incorporamos na nossa reunião de engineering all-hands o ritual de ver quantos erros tínhamos eliminado no mês. Transformamos o que poderia ser uma tarefa chata em um indicador de progresso coletivo.

Ver aquele número caindo mês a mês criou um senso de conquista compartilhada.

5. Atenção Especial para Código Crítico

Para arquivos sensíveis — como nossa lógica de geração de acordos, o coração da nossa plataforma — criamos tickets específicos. Essas partes do código mereciam atenção focada e revisão cuidadosa, não podiam ser tratadas como "apenas mais um erro para resolver".

Os Resultados

Mantivemos uma média de 800 erros removidos por mês.

Em 6 meses, chegamos a zero erros de TypeScript.

Hoje, em novembro de 2025, arquivos vermelhos com erros de TypeScript são coisa do passado na Monest. Mais importante: ganhamos:

✅ Confiança — refatorações são menos arriscadas
✅ Produtividade — o autocomplete realmente funciona
✅ Qualidade — pegamos erros em tempo de desenvolvimento, não em produção
✅ Onboarding — novos engenheiros entendem o código mais rapidamente

Lições Aprendidas

1. Débito técnico não se resolve em um sprint heroico

Tentativas de "resolver tudo de uma vez" geralmente falham. Progresso consistente e incremental vence.

2. Automação cria disciplina

A GitHub Action transformou a resolução de débito técnico de "quando der tempo" para "sempre, um pouco por vez".

3. Visibilidade gera engajamento

Compartilhar o progresso publicamente nas all-hands criou senso de propriedade coletiva.

4. Produção não pode esperar perfeição

A configuração híbrida (strict em dev, permissivo em prod) nos deu o melhor dos dois mundos: visibilidade sem bloqueio.

5. Tipos servem o código, não o contrário

Nosso único incidente em produção nos ensinou: quando os tipos contradizem código que funciona, questione os tipos primeiro.

Why You Shouldn't Use `as` in TypeScript 🚫

Matheus Morett — Sun, 03 Nov 2024 14:36:39 +0000

Introduction

TypeScript, since its inception, has aimed to provide static typing for JavaScript, helping developers write safer and more reliable code. The as operator was introduced to allow type assertions, a powerful feature but one with great potential for misuse. In this article, we'll explore the creation and purpose of as, common mistakes associated with its use, and how alternatives like zod can offer a more robust solution.

The Creation of `as` in TypeScript

The as keyword in TypeScript is used to inform the compiler that a value should be treated as a specific type, regardless of its original inference. It's useful in situations where the developer is certain about the correct type of a variable, but the compiler cannot infer it.

For example:

const value: unknown = getValueFromSomewhere();
const valueAsString = value as string; // I know `value` is a string!

In this case, as tells the compiler that value is a string, even though it was initially inferred as unknown.

Common Mistake: Using `as` with Fetch and JSON.parse

While as is useful, it can easily be misused, especially in scenarios where data comes from external sources, such as APIs.

With Fetch

When using fetch to get data from an API, it's tempting to use as to tell TypeScript what type of data to expect:

async function fetchData() {
    const response = await fetch('https://api.example.com/data');
    const data = await response.json() as MyDataType; // Beware!
    return data;
}

Here, we're telling TypeScript: "Trust me, data is of type MyDataType." The problem is that fetch doesn't guarantee the format of the returned data. This can lead to runtime errors that TypeScript cannot predict or prevent.

With JSON.parse

The same issue arises when using JSON.parse():

const jsonString = '{"name": "John", "age": 30}';
const parsedData = JSON.parse(jsonString) as MyDataType; // Risky!

Although jsonString seems to contain an object of type MyDataType, there are no guarantees. If the JSON structure changes or is incorrect, the code will fail silently, leading to hard-to-track bugs.

The Solution: Using `zod` for Safe Type Validation

To avoid these issues, it's better to validate external data before trusting it. zod is a TypeScript schema validation library that can be used for this purpose.

Example with `fetch` and `zod`

import { z } from 'zod';

const MyDataType = z.object({
    name: z.string(),
    age: z.number(),
});

async function fetchData() {
    const response = await fetch('https://api.example.com/data');
    const json = await response.json();

    const result = MyDataType.safeParse(json);
    if (!result.success) {
        throw new Error('Invalid data');
    }

    return result.data; // Now we are sure that `result.data` is of the correct type!
}

Example with `JSON.parse` and `zod`

const jsonString = '{"name": "John", "age": 30}';
const json = JSON.parse(jsonString);

const result = MyDataType.safeParse(json);
if (!result.success) {
    console.error(result.error);
} else {
    console.log('Valid data:', result.data);
}

When It’s Safe to Use `as`

Although we’ve discussed the dangers of misusing as, there is one specific scenario where I personally find it acceptable to use: Gradual Migration to TypeScript.

Gradual Migration to TypeScript

During the migration of a large JavaScript codebase to TypeScript, it might be necessary to use as temporarily to maintain compatibility while you gradually add more specific and safe types to your code.

function processData(data: any) {
    const typedData = data as MyDataType; // Temporary use
    // Processing logic here
}

This is an acceptable use of as during the transition but should be replaced by more precise types or validations as soon as possible.

Conclusion

While as can be a handy tool, its misuse, especially when dealing with dynamic or external data, can lead to silent and hard-to-debug runtime errors. Instead, adopting validation tools like zod provides a more robust and secure approach, ensuring that data matches the expected types before trusting it in your TypeScript code. Personally, I would only use as in the context of gradual migration to TypeScript, where its temporary nature is understood, and plans are in place to phase it out.

🔍 "Overlooked Use Cases in Your Tasks?"

Matheus Morett — Mon, 04 Sep 2023 22:32:32 +0000

Throughout my 8️⃣ years in software development, I've faced a recurring challenge: poorly specified tasks. 😰

How many times were use cases overlooked by the PO? And what if, during development, I forgot a crucial detail? 🤔 These oversights often only emerged during testing or, even worse, once users began interacting with the application. 😓

This scenario began to shift for the better when I was fortunate enough to work with a PO who employed Gherkin for specifications. 🌟 From that point on, the responsibility to define use cases was shared between the PO and myself. This change not only made it easier to introduce automated testing but also helped me deliver more bug-free software. 🛠️💡

Let's dive into a practical example. 🧐

Imagine you were given this User Story:

As a user, I should be able to redeem a discount coupon at checkout. 🛍️

Translating this User Story to automated tests in Jest:

describe('Coupon Redemption based on User Story', () => {
  it('should allow users to redeem a discount coupon', () => {
    // Mock checkout process
    // Insert coupon code
    expect(finalPrice).toBeDiscounted();
  });
});

However, this test seems quite general and lacks detail.

Now, let's see how Gherkin can refine this: 👇

Scenario: Redeeming a valid coupon
Given the user is finalizing a purchase
When they enter a valid coupon code
Then the appropriate discount should be applied to the total 🟢

Scenario Redeeming an expired coupon
Given the user is finalizing a purchase
When they enter an expired coupon code
Then no discount should be applied
And a message stating the coupon has expired should be displayed. 🔴

Translating the refined Gherkin scenarios to Jest tests:

describe('Coupon Redemption based on Gherkin', () => {
  it('should apply discount for valid coupon', () => {
    // Mock checkout process
    // Input valid coupon code
    expect(finalPrice).toBeDiscounted();
  });

  it('should show error for expired coupon', () => {
    // Mock checkout process
    // Input expired coupon code
    expect(finalPrice).not.toBeDiscounted();
    expect(displayErrorMessage).toBeCalledWith('Coupon expired');
  });
});

The Gherkin specifications not only address the scenario of a valid coupon but also consider the situation of an expired coupon, which could easily be overlooked with a vaguer User Story.

DEV Community: Matheus Morett

Redis is the ceiling: why I built bullmq-outbox

The flaw is not a bug

Redis Cluster does not split a queue

What I built that afternoon

Then it paid for itself

Why it is a package now

The number to watch

Talk is cheap: high-agency e a técnica do 1-3-1

O que eu não estava enxergando

Técnica 1: o 1-3-1

Um exemplo concreto

Técnica 2: cultura high-agency

Como escolher entre 1-3-1 e owner

O que isso muda quando você está do outro lado da mesa

Por que isso é ainda mais crítico em empresa crescendo

Fechando

Você não vai mais entregar código. Você vai entregar times que entregam código.

O desespero de ver "diferente"

Deixar o time aprender

Como a gente fez na Monest 💜

A surpresa

A lição

Contratando para áreas que você não domina

Pedindo ajuda

O modelo que funcionou

A lição

As melhores pessoas precisam saber que você existe

Como eu contratei um Tech Lead pelo Twitter

Por que isso funciona

Não é sobre viralizar

O livro que me fez levar isso a sério

A lição

O medo de ficar pra trás

A pergunta que me acalmou

Nenhuma tecnologia se consolida do dia pra noite

Não é pra ignorar o novo

A lição

O delay entre esforço e recompensa

O alerta que salvou o dia

Os números que demoraram pra aparecer

O dev que foi entendendo aos poucos

Por que isso é difícil

O que funcionou pra mim

A lição

Como tirar o mindset de early-stage sem criar burocracia

Como tirar o mindset de early-stage sem criar burocracia

O desafio real

O que mudamos

Como convencer sem impor

Onde não exagerar

A lição

[Boost]

How I made BeeThreads and what doest it solve

Como Eliminamos 4.041 Erros de TypeScript em 6 Meses

O Desafio: 4.041 Erros de Uma Vez

Nossa Abordagem: Migração Gradual e Sustentável

1. Strict em Dev, Permissivo em Prod

2. Uma GitHub Action para Criar Accountability

3. A Regra de Ouro: Produção em Primeiro Lugar

4. Visibilidade e Celebração do Progresso

5. Atenção Especial para Código Crítico

Os Resultados

Lições Aprendidas

1. Débito técnico não se resolve em um sprint heroico

2. Automação cria disciplina

3. Visibilidade gera engajamento

4. Produção não pode esperar perfeição

5. Tipos servem o código, não o contrário

Why You Shouldn't Use `as` in TypeScript 🚫

Introduction

The Creation of as in TypeScript

Common Mistake: Using as with Fetch and JSON.parse

With Fetch

With JSON.parse

The Solution: Using zod for Safe Type Validation

Example with fetch and zod

Example with JSON.parse and zod

When It’s Safe to Use as

Gradual Migration to TypeScript

The Creation of `as` in TypeScript

Common Mistake: Using `as` with Fetch and JSON.parse

The Solution: Using `zod` for Safe Type Validation

Example with `fetch` and `zod`

Example with `JSON.parse` and `zod`

When It’s Safe to Use `as`