O que quebrou — e o projeto que eu joguei fora

Série de construção sem erro é propaganda. Então esse é o texto que eu mais quis escrever — e o que mais me custou, porque é o que expõe.

Não teve uma sexta-feira. Teve várias semanas

Me perguntaram qual foi a pior sexta-feira, aquele dia em que quebra tudo e você resolve na raça. Não consigo escolher uma. Foi segunda, foi terça, foi quarta.

Eu tinha entrado numa imersão para consolidar aquilo tudo — estava aprendendo e executando ao mesmo tempo, juntando conhecimento e produzindo com ele no mesmo dia. E não era mais uma experiência isolada minha: era algo que o time inteiro ia usar, e que eu precisava mostrar que era diferente do que a gente vinha fazendo até ali.

Foram vários dias de quebrar o código e ficar olhando para a tela pensando: e agora, como é que eu conserto isso? Dor de barriga de verdade. Isso faz parte e ninguém publica.

O projeto que eu joguei fora

O que mais marcou foi o resumo fiscal.

É uma planilha nossa, em Excel, que controla faturamento e impostos dos clientes e serve de conferência: a gente compara com o que o sistema gerou, para saber se está batendo. Eu automatizei aquilo inteiro. Coloquei automação, coloquei inteligência artificial, fiz o caminho completo.

E o resultado não se pagou. O custo de processamento e o custo financeiro não justificaram o que saía do outro lado.

A causa foi a que eu menos queria admitir: as regras não estavam claras. E a culpa não era da automação. Era do processo — um processo espalhado por várias planilhas interligadas, cada uma com uma exceção que só existia na cabeça de quem preenchia.

Então eu parei, joguei fora e recomecei do zero, de outro jeito.

A lição que eu levo para todo projeto novo

Processo confuso não vira software. Vira automação cara de confusão.

Automatizar um processo mal desenhado não conserta o processo — ele só faz a bagunça acontecer mais rápido e com um custo por mês. Se as regras não estão claras para uma pessoa, elas não vão ficar claras para uma máquina.

Hoje, quando alguma coisa resiste demais a virar software, eu já sei que a resistência está no processo, não na ferramenta. É um sinal, não um obstáculo.

E tem um consolo real nisso: como já passou um tempo dessas construções iniciais, a gente foi ganhando corpo e força. Essas coisas vão ficando muito mais fáceis ao longo da jornada. O primeiro tropeço é o mais caro.

Por que nada disso chegou no cliente

Essa foi uma decisão de estratégia, e ela segurou o estrago dentro de casa.

A gente começou automatizando as tarefas repetitivas do próprio time — o que era chato de fazer, o que desgastava, o que consumia tempo em conferência e validação. Desde março de 2026 são várias automações operando, e o ganho de velocidade é visível.

Só depois de rodar internamente é que a gente começou a liberar para cliente. Tudo é testado aqui dentro antes.

O melhor exemplo é o aplicativo da reforma tributária, que ainda não saiu. E não saiu justamente porque a legislação muda toda hora: eu monto o checklist, o checklist não fica pronto, porque quando eu vou liberar mudou de novo. Segurar é decisão, não atraso.

Transparência como método

E tem uma parte que eu não esperava que fizesse tanta diferença: a gente conta.

Os clientes que estão usando sabem que estão usando algo em construção. Eles viram case, eles validam conosco, eles opinam. Isso não é enfeite de discurso — é o que permite liberar cedo sem trair a confiança de ninguém.

Até aqui, graças a Deus, nenhum erro custou credibilidade com cliente. Não por sorte: porque a gente combinou antes o que estava pronto e o que não estava.

No próximo texto, a parte que quase ninguém conta — o que acontece quando você entrega software novo para uma equipe que já tem prazo em cima.