Autor: MacGyver

Dias 30 a 34 · 24 a 28 de abril – 2026

Com o fechamento de caixa de pé, chegou a hora de encarar uma chatice antiga: fazer o sistema se virar sozinho. Buscar o que precisa, quando precisa, sem alguém empurrando. Esses cinco dias foram sobre acelerar — e sobre descobrir que velocidade cobra um preço em parcelas.

A novela do crachá

Primeiro, o problema que eu já tinha avisado lá no capítulo do piloto automático: os acessos que expiram.

Pra buscar os dados do app de delivery automaticamente, o sistema precisa estar logado. E o login vence de tempos em tempos, como um crachá com validade. Quando vence, o robô chega na porta e não entra — volta de mãos vazias, sem drama e sem aviso.

Passei um bom tempo nisso, e a solução final ficou menos elegante do que eu queria: em vez de tentar imitar um login pela porta da frente, o sistema passou a abrir um navegador de verdade, com um perfil separado só pra isso, pegar o crachá válido e guardar. Deselegante? Um pouco. Funciona todo dia? Funciona. E nessa altura eu já tinha aprendido que a solução que roda na terça-feira vale mais que a solução bonita que quebra na terça-feira.

O resto daquela noite foi uma sequência que quem mexe com isso reconhece de longe: subiu a versão, achou um detalhe, subiu de novo, achou outro. Quatro versões numa noite só. Uma delas nasceu de uma conta que ignorava um tipo de vale que só aparece em algumas lojas — dessas que você só descobre porque alguém que conhece a operação bate o olho e diz “esse número tá baixo”.

Um de cada vez é confortável

Resolvido o crachá, veio agora a captura das avaliações do app de delivery. Todo dia o sistema entrava na plataforma e baixava as avaliações de cada loja, uma por uma, na fila.

Funcionava. O problema era o relógio: multiplique o tempo de uma loja pelo número de lojas e você entende por que aquilo estava virando um processo que ninguém queria esperar.

A saída foi parar de trabalhar em fila e trabalhar em paralelo: três capturas ao mesmo tempo, em vez de uma. É a diferença entre um caixa atendendo trinta pessoas e três caixas atendendo dez cada. O ganho apareceu na hora — cerca de três vezes mais rápido, exatamente o que a conta prometia.

Só que trabalho paralelo cobra, e a cobrança veio em três parcelas.

Parcela 1: todo mundo copiando ao mesmo tempo

Cada captura precisava de uma cópia do perfil do navegador pra rodar isolada das outras. Com um processo só, copiar aquilo era irrelevante. Com três copiando junto, o disco virou o gargalo — os três esperando o mesmo disco atender.

A solução foi trocar o tipo de cópia. Em vez de duplicar arquivo por arquivo, o sistema passou a usar um recurso do próprio disco do Mac que cria uma cópia instantânea: em vez de escrever tudo de novo, ele anota “isso aqui é igual àquilo ali” e só duplica de verdade o que mudar. Cópia que levava um tempo desconfortável virou coisa de piscar de olho.

Deixei o jeito antigo como plano B, pro caso de o truque não funcionar em alguma situação. Aprendi isso apanhando: otimização esperta sem plano B é bomba-relógio.

Parcela 2: erro que não parece erro

Com três processos rodando, apareceu um comportamento estranho: às vezes a captura terminava “com sucesso” e vinha vazia.

Demorei pra entender. A plataforma, quando está sobrecarregada ou desconfiada, não devolve um erro — devolve uma página de erro. Do ponto de vista do robô, a resposta chegou, o endereço respondeu, está tudo certo. Ele salvava a página de desculpas achando que era o documento.

Isso é traiçoeiro porque não acende luz vermelha nenhuma. O processo termina, o relatório diz que foi tudo bem, e o buraco só aparece dias depois, quando alguém procura uma avaliação que deveria estar ali.

Ensinei o sistema a ler o que recebeu antes de comemorar: se a página tem cara de erro, não é sucesso, é falha — e falha se tenta de novo. Parece óbvio escrito assim. Não é óbvio quando você está com a cabeça em “fazer funcionar”.

Parcela 3: dois no mesmo lugar

A terceira foi a mais difícil de achar, dessas que fazem duvidar da própria sanidade.

De vez em quando o índice do fechamento de caixa — a lista que diz o que já foi conferido e o que falta — voltava a um estado antigo. Alguém marcava, e pouco depois estava desmarcado. Ninguém tinha desfeito nada.

O culpado era a combinação de duas coisas boas. De um lado, o salvamento automático, que vai guardando sozinho enquanto a pessoa preenche pra ninguém perder trabalho. Do outro, a atualização do índice. Os dois mexiam no mesmo lugar, e às vezes o salvamento chegava atrasado carregando uma foto antiga da situação, e escrevia essa foto por cima da versão mais nova. Não era erro de conta: era erro de ordem.

Esse tipo de problema tem nome — os programadores chamam de corrida, porque é literalmente dois processos correndo pro mesmo lugar e o resultado dependendo de quem chega primeiro. É a pior categoria de bug que existe, porque não acontece sempre: acontece quando o tempo conspira. Você testa dez vezes, funciona dez vezes, e quebra na décima primeira na frente do usuário.

Resolvi impedindo que o salvamento automático sobrescrevesse um estado mais recente que o dele, e pus um botão pra reconstruir o índice do zero — quando se mexe com esse tipo de coisa, é bom ter um jeito manual de dizer “esquece tudo e conta de novo”.

O robô que acorda sozinho

Fechei essa parte com uma peça pequena e libertadora: o programa das capturas passou a subir sozinho quando o computador liga. Antes, se a máquina reiniciasse — queda de luz, atualização, qualquer coisa — alguém precisava lembrar de abrir o programa. E “alguém precisa lembrar” é o mesmo que “uma hora ninguém lembra”.

E aí veio o dia 28

Os quatro primeiros dias foram sobre o sistema trabalhar sozinho. O quinto foi sobre ele falar.

Até ali, tudo que o sistema descobria ficava dentro dele: você tinha que entrar, abrir a tela, procurar. Se um número estranho aparecesse às três da manhã, ele esperava educadamente alguém passar por ali.

No dia 28 nasceu o Hub de Comunicação — o lugar de onde o sistema manda mensagem pra quem precisa saber, sozinho, na hora certa. Comecei o esqueleto de manhã e ele foi pro ar na mesma noite. Foi tanta coisa junta que a versão pulou de 3.70 pra 4.0 — e virar um número inteiro, num projeto, é aquele momento em que você olha pra trás e percebe que a coisa mudou de patamar.

Alerta de Spoiler: esse hub vai ser o berço do nascimento dos robôs. E eu nem imaginava isso…

A lição desses dias

Velocidade não é de graça. Quando você põe três coisas pra rodar ao mesmo tempo, não ganha só três vezes o resultado: ganha também três vezes as chances de duas delas se atrapalharem. Tudo que era simples porque acontecia em fila passa a exigir combinação.

E fica a que mais me marcou: desconfie do sucesso silencioso. O erro que grita é fácil, ele te obriga a olhar. O perigoso é o processo que termina dizendo que deu tudo certo e entrega uma pasta vazia. Automação madura não é a que faz o trabalho — é a que sabe reconhecer quando não fez.

No próximo capítulo, o sistema estreia a voz: as primeiras mensagens saindo sozinhas, um vigia de olho nos números o tempo todo — e a descoberta de que um sistema que fala demais é tão ruim quanto um que fica calado.

Um aviso rápido antes de começar: a partir deste capítulo, cada post passa a cobrir 5 dias da história, em vez de 3. Capítulo maior, com mais coisa acontecendo dentro, e um respiro melhor pra contar direito. O resto continua igual: tudo real, tudo datado, do jeito que aconteceu.

Dias 25 a 29 · 19 a 23 de abril – 2026

Tem uma distância enorme entre “o sistema está pronto” e “o sistema está no ar”. Esses cinco dias foram sobre atravessar essa distância — cair no meio do caminho, levantar e atravessar de novo.

Antes da estreia, a parte que ninguém vê

No capítulo passado eu tinha montado o esqueleto do Fechamento de Caixa: a tela onde o operador, no fim do turno, conta o que tem e bate com o que o sistema esperava. Esqueleto é a palavra certa — funcionava comigo clicando com calma, sabendo exatamente onde não encostar.

Só que quem ia usar aquilo não era eu. Era gente com pressa, no fim do expediente, com a loja fechando em volta. Software que só funciona quando o dono usa não é software: é demonstração.

O dia 19 foi inteiro endurecendo a tela. Bloquear o que não podia ser preenchido errado, tratar campo vazio, impedir que um clique duplo salvasse duas vezes. Nada disso dá orgulho de mostrar pra alguém — é o corrimão da escada: ninguém repara, até faltar.

No meio disso, uma dívida antiga finalmente saiu do papel: senha de verdade. Até ali o sistema tinha usuários de um jeito improvisado, que servia enquanto éramos quatro gatos pingados. Reescrevi tudo. Agora cada senha é guardada embaralhada, e embaralhada sem volta: nem eu, olhando o banco de dados, consigo descobrir a senha de alguém. É o mínimo que qualquer sistema sério faz, e eu estava devendo.

Junto veio o pacote de gente grande: tela pra criar e editar usuário, permissão por pessoa, e um registro de quem mexeu em quê. Esse último importa mais do que parece numa operação com várias lojas — quando um número muda, você quer saber quem mudou. Não por desconfiança, por rastreabilidade. Some a dúvida, sobra o fato.

E pus o número da versão visível na tela inicial. Bobagem de dois minutos que mata uma confusão recorrente: quando alguém diz “aqui tá dando erro”, a primeira pergunta deixa de ser adivinhação. Olha o número e você sabe se a pessoa está na versão nova ou ficou com a página velha aberta desde ontem.

Conferência, vales e a maquininha

Com a base firme, ataquei o que o gerente esperava. Não basta o operador contar o dinheiro — o sistema precisa dizer se aquilo bate.

Montei a tela que põe lado a lado o esperado e o que realmente entrou, quebrado por forma de pagamento. E resolvi o caso que sempre trava o fechamento na vida real: o vale. Aquele dinheiro que sai do caixa por um motivo legítimo no meio do turno e que, se ninguém anotar, vira um buraco misterioso no fim do dia. Agora o vale é registrado na hora e sai em PDF, com a assinatura de quem pegou. Buraco misterioso vira papel.

Também tornei obrigatório informar a hora do fechamento — sem isso dois turnos se misturam e ninguém sabe mais de quem era o caixa.

E encaixei a importação automática da administradora de recebíveis, a maquininha do cartão. Antes alguém baixava o relatório e subia na mão. Agora o sistema puxa sozinho, inclusive vouchers e vendas online, e amarra cada arquivo à loja certa pelo CNPJ. Detalhe que evita o erro mais chato de todos: número certo na loja errada.

17h52

No dia 21, liguei a chave. O Fechamento de Caixa saiu do meu computador e foi pro ar, valendo pra todo mundo.

Às 20h34 eu desliguei de novo.

Duas horas e quarenta e dois minutos. Foi o que o módulo durou em produção na primeira tentativa.

Não vou romantizar: bateu aquele frio na barriga de quem vê a coisa desandar com gente de verdade do outro lado. O que corria lisinho comigo clicando devagar encontrou a realidade — telas abertas ao mesmo tempo, sequências de clique que eu nunca testei, dado chegando num formato que eu não previ. Nada catastrófico, nada que perdesse dinheiro. Mas o suficiente pra entender que aquilo ainda não ficava de pé sozinho.

A parte boa dessa história é o que eu tinha feito antes: aquela chavinha que liga e desliga o módulo sem mexer no código nem republicar nada. Voltar atrás foi um clique. Sem a chave, teria sido uma noite inteira desfazendo na marra, com a operação parada no meio.

O conserto

Os dois dias seguintes foram de olhar no olho do que quebrou.

Comecei pelo mais silencioso e mais perigoso: a conta estava errada. A fórmula que extraía os recebimentos do app de delivery pegava os valores de um jeito que funcionava na maioria dos casos e escorregava nos outros. É o pior tipo de erro que existe: o que acerta quase sempre. Erro que erra sempre você descobre no primeiro teste; erro que acerta em nove de dez passa despercebido até virar prejuízo no fim do mês.

Depois fui atrás de uma situação que a vida real mostrou e eu não tinha previsto: caixa com sobra. Eu construí o fluxo assumindo que a diferença sempre seria pra menos — falta dinheiro, registra o vale, explica o buraco. Só que às vezes sobra. E o sistema, teimoso, exigia um vale mesmo quando não havia nada a justificar. O operador ficava preso numa tela pedindo explicação pra um problema que não existia.

Anotei mentalmente: quase todo travamento de sistema vem de alguém ter assumido que a vida só acontece de um jeito.

Aproveitei e fechei o primeiro acesso — agora o usuário novo define a própria senha no primeiro login. Antes eu criava a senha e mandava pra pessoa, o que significa que, por um tempo, duas pessoas sabiam a senha de uma conta só. Funciona entre conhecidos; envelhece mal quando a equipe cresce.

Dia 23, 13h22

Liguei a chave de novo.

E dessa vez ficou.

Não teve foguete — teve alívio, que é uma emoção bem mais honesta na programação. Passei o resto do dia com o olho no sistema esperando um susto que não veio.

Com o módulo de pé, deu pra construir por cima. E aí entrou a peça que mudou quem o sistema atendia: o Consolidado da Direção. Até então o fechamento era coisa de cada loja olhando o próprio umbigo. O consolidado juntou tudo numa visão só — todas as unidades, lado a lado, no mesmo período.

Foi a primeira vez que o sistema deixou de ser ferramenta de operação e virou ferramenta de decisão. Quem opera precisa saber se o caixa da loja bateu hoje. Quem dirige precisa saber quais lojas batem sempre, quais escorregam toda semana e onde está o padrão. Mesma informação, dois usos completamente diferentes — e o segundo só existe quando o primeiro é confiável.

Por fim, uma certeza: a colaboração valiosa de um de nossos gerentes topando ser “cobaia” fez tudo isso acontecer. Contribuição valiosíssima dele e do time.

A lição desses dias

Existe uma distância entre “funciona” e “aguenta”. Funciona é comigo, com calma, sabendo dos atalhos. Aguenta é com o operador apressado, no pior dia do mês, fazendo exatamente o que eu não previ.

E ficam duas lições que carrego até hoje. A primeira: construa a saída antes de precisar dela. Não liguei o módulo torcendo pra dar certo — liguei sabendo que, se não desse, eu voltaria em um clique. Isso não é pessimismo, é engenharia. Quem sobe sem plano de descida não está corajoso, está apostando.

A segunda: software que fica de pé na segunda tentativa quase nunca é software com mais sorte. É software com mais informação. As três coisas que eu consertei entre uma estreia e outra, eu jamais descobriria testando sozinho — a realidade apontou cada uma. Aquelas duas horas e quarenta e dois minutos no ar foram o teste mais barato que eu podia ter feito.

No próximo capítulo, o sistema aprende a se virar sem mim: buscar sozinho o que precisa, trabalhar em três frentes ao mesmo tempo — e as armadilhas que aparecem exatamente quando você acelera.

Dias 22 a 24 · 16 a 18 de abril – 2026

Todo esse tempo, o sistema respondia uma pergunta: “quanto eu vendi?”. Nesses três dias, ele começou a responder outra, bem mais difícil e mais útil no dia a dia da loja: “o dinheiro que entrou bate com o que foi vendido?“.

Mas antes, um acerto de casa que já estava passando da hora. O projeto ainda carregava, lá no fundo, o nome improvisado que eu dei na primeira noite — aquela gambiarra de batismo de quem não sabia que ia longe. Finalmente rebatizei tudo, do começo ao fim, de Sistema de Gestão DMR. Parece detalhe, mas dar o nome certo é assumir que a coisa cresceu e veio pra ficar.

Feito isso, ataquei o caixa. Montei uma tela de Conferência de Caixa: ela junta o que entrou por cada meio — as plataformas de delivery, os pagamentos online — e mostra, lado a lado, quanto era esperado e quanto realmente caiu, separado por forma de pagamento. É o tipo de conta que, na mão, toma a manhã de um gerente e ainda sai com erro.

E aí comecei o módulo que promete ser um divisor de águas: o Fechamento de Caixa. A ideia é dar ao operador, no fim do expediente, uma tela simples pra fechar o caixa do dia — contar o que tem, bater com o que o sistema esperava e registrar. Montei o esqueleto: os cálculos, o jeito de ir salvando sozinho enquanto se preenche (pra não perder nada) e a primeira versão da tela. Ainda é o começo, mas já dá pra sentir pra onde vai.

Finalmente os anos conferindo caixa na unha serviram pra pra passar o aprendizado adiante.

A lição desses dias: um sistema fica adulto quando para de só te informar e começa a te ajudar a operar. Sair do “quanto vendi” pro “o caixa bate?” foi o sistema descer da sala do escritório pro balcão da loja — perto de onde o dinheiro de verdade passa. E foi aqui que ele deixou de ser meu projeto pessoal pra começar a virar ferramenta de trabalho da equipe inteira.

No próximo capítulo, esse fechamento de caixa ganha corpo — e com ele, as primeiras dores de fazer uma tela que gente de verdade, com pressa e no fim do turno, precisa usar sem errar.

Dias 19 a 21 · 13 a 15 de abril – 2026

Agora que o sistema buscava os números sozinho, um novo medo apareceu: e se ele trouxer o número errado — e eu confiar nele? Automatizar sem conferir é como dirigir de olhos fechados só porque o carro é automático. Esses três dias foram sobre uma palavra: confiança.

Ataquei três fantasmas.

O primeiro foi o backup. Todos os dados de venda, de todas as lojas, viviam num lugar só. E eu vinha dormindo sem nenhuma cópia de segurança — um erro bobo e sumiria tudo. Coloquei um backup automático de madrugada, guardando as últimas versões. Simples, invisível, e o tipo de coisa de que você só lembra no dia da tragédia — melhor ter antes.

O segundo foi o pior de todos: a venda contada duas vezes. Quando o sistema busca os dados sozinho e por acaso pega o mesmo pedido de novo, o faturamento incha sem ninguém perceber — e número de venda errado é veneno pra quem decide pelo número. Ensinei o sistema a reconhecer o que já tinha entrado e ignorar a repetição, na hora da importação. Chega de fantasma.

O terceiro foi pôr um detetive dentro do próprio sistema: todo dia, num horário fixo, ele confere se as importações realmente aconteceram e se bate tudo. Se faltou alguma coisa, ele avisa. É o sistema vigiando o sistema — porque o pior cego é o que não sabe que está cego.

Percebi agora que essa frase: “sistema vigiando o sistema” virou praticamente um mantra de todo o projeto depois desse dia.

A lição desses dias: número bonito não vale nada se você não confia nele. Um sistema que decide o rumo do seu negócio precisa ser, antes de tudo, honesto — e honestidade, em software, se chama backup, conferência e o cuidado de não contar a mesma coisa duas vezes. O trabalho invisível que ninguém elogia é justamente o que deixa você dormir tranquilo.

No próximo capítulo, o sistema dá um salto: sai de “mostrar quanto vendi” e começa a entrar na operação de verdade da loja — o fechamento do caixa no fim do dia.

Dias 16 a 18 · 10 a 12 de abril – 2026

Até aqui, todo dia começava igual: eu abrindo as plataformas de delivery, baixando as planilhas de venda e jogando no sistema pra ele organizar. Funcionava, mas era eu, na mão, todo santo dia. E era isso que me incomodava: eu tinha construído um sistema esperto, mas ele ainda dependia de mim pra comer.

Nesses três dias, virei a chave. Programei o sistema pra ir buscar os números sozinho, direto das plataformas, todo dia, no horário certo — sem eu levantar um dedo. Parece pouco, mas foi aqui que ele deixou de ser uma ferramenta que eu uso e começou a virar um funcionário que trabalha.

O mundo real, claro, não facilitou. Primeiro, os acessos que expiram: as plataformas te deslogam de tempos em tempos, por segurança. Se o sistema fosse buscar os dados e estivesse “deslogado”, voltava de mãos vazias — tive que ensiná-lo a se reconectar sozinho. E, principalmente, as plataformas não gostam muito de robô mexendo nelas: vira e mexe aparecia aquele teste de “prove que você é humano” no meio do caminho. Fazer o sistema atravessar tudo isso e ainda assim chegar todo dia com os números certos foi, de longe, o maior perrengue desses dias — uma novela que eu poupo você de acompanhar em detalhe.

Eu mal sabia que isso ainda me atormentaria um bocado. Não quer dar spoiler, mas ainda me atormenta mesmo digitando “do futuro”. Rsrsrs.

E aprendi (de novo) que automação sem rede de segurança é cilada. Então blindei tudo: se uma busca falha, o sistema tenta de novo sozinho; se insiste em falhar, ele me manda um e-mail avisando. Nada de descobrir três dias depois que os números pararam de entrar. Ah, e teve o velho conhecido: um dos arquivos vinha grande demais pro limite da hospedagem — de novo tive que processá-lo antes de enviar, pra caber.

A lição desses dias: a diferença entre uma ferramenta e um sistema de verdade é quem faz o trabalho braçal. Enquanto eu era o motor, tudo parava quando eu parava. Automatizar não foi luxo — foi tirar o gargalo (eu) do caminho. E automação de verdade não é só “fazer sozinho”: é fazer sozinho e avisar quando algo dá errado.

No próximo capítulo, a consequência natural disso: se o sistema ia rodar sozinho, eu precisava confiar nos números que ele trazia. E confiança se constrói com rede de proteção — backup, conferência automática e o fim de um fantasma chato: a venda contada duas vezes.

Dias 13 a 15 · 7 a 9 de abril – 2026

Esse foi o dia em que eu quis ser esperto e a tecnologia me deu uma surra educativa.

A ideia era linda: toda reunião virar uma ata sem ninguém ter que sentar pra escrever. Eu jogava a transcrição da conversa, a inteligência artificial lia tudo e devolvia o resumo organizado — decisões, tarefas, responsáveis. Montei o módulo, liguei na IA e… funcionou de primeira. Bom demais pra ser verdade — e era.

O primeiro tapa veio da hospedagem: no plano grátis, qualquer tarefa que passa de 10 segundos é cortada no meio. E resumir uma reunião inteira demora bem mais que isso. A resposta vinha sempre picada. A saída foi fazer o texto pingar aos poucos na tela, em vez de esperar o resultado inteiro de uma vez — assim nada estoura o tempo. Primeiro muro vencido.

Aí veio o segundo: custo. Deixar a IA mais parruda trabalhando o dia todo pesava no bolso. Então comecei uma via-crúcis atrás da opção gratuita. Troquei pela IA do Google, a Gemini — e passei a manhã apanhando de erro de formato, modelo que não existia, resposta que não vinha. Larguei ela e fui pra uma terceira, a Groq, famosa por ser rápida e de graça — mas, pra caber no limite gratuito, eu tinha que cortar pedaços da reunião, e aí a ata saía capenga.

Depois de três robôs e uma manhã inteira, cheguei a uma conclusão que, no fundo, eu já suspeitava: voltei pro primeiro, o Claude, que fazia o serviço direito. Só que voltei sabendo exatamente por quê — tinha testado os outros na marra. No fim do dia ainda sobrou fôlego pra uns ajustes: juntar duas lojas que apareciam duplicadas e mostrar as porcentagens nos cartões de faturamento.

Interessante demais essa coisa de jogar pra IA resolver e terminar aprendendo a fazer com ela mesmo. Quase um ciclo vicioso.

A lição do dia: às vezes você precisa dar a volta ao mundo pra descobrir que a porta certa era a primeira. Não foi tempo perdido — foi o preço de saber, e não só achar, qual era a melhor escolha. Testar as alternativas transformou um palpite numa decisão.

E com as reuniões virando ata sozinhas, o sistema deu o primeiro passo pra algo maior: parar de só mostrar números e começar a pensar em cima deles. Mas isso é conversa pro próximo capítulo.

Dias 10 a 12 · 4 a 6 de abril – 2026

Todo projeto que cresce rápido chega num ponto em que vira uma gaveta bagunçada: funciona, mas tem coisa demais que ninguém usa. No começo de abril foi a vez de eu abrir essa gaveta e limpar.

Comecei pelo que ninguém vê: o banco de dados. Nas primeiras semanas eu tinha criado um monte de campo “por via das dúvidas” — informação que o sistema guardava e nunca olhava. Cada um era um peso morto que deixava tudo mais confuso de mexer. Fui removendo, um a um, com aquele friozinho de “e se eu precisar depois?”. Não precisei. O sistema ficou mais enxuto e bem mais fácil de entender.

Depois parti pra parte que todo mundo vê: a tela de subir os dados. Ela tinha nascido feia e funcional, do tipo “resolve, mas dá trabalho”. Redesenhei do zero, mais limpa e óbvia, e coloquei uma coisa que fazia falta — uma lista dos últimos arquivos enviados, pra bater o olho e saber o que já entrou sem ter que adivinhar. De quebra, cacei um filtro teimoso na tela de vendas do mês, que insistia em mostrar o período errado.

Nada disso vira um recurso novo e brilhante pra mostrar pra alguém. É trabalho invisível. Mas foi um dos dias em que mais senti o sistema “respirar” — como quando você organiza a oficina e de repente acha todas as ferramentas na hora que precisa.

Vou confessar: melhor mesmo desse dia foi ver os gráficos de vendas montando e desmontando sempre que eu mudava de marca. Jesus!! No excel isso dava um trabalhooo!

A lição da semana: às vezes progredir é subtrair. A gente acha que construir é só empilhar coisa nova, mas um sistema (como uma casa) também melhora quando você tira o que atrapalha. Código que você apaga é código que nunca mais vai te dar dor de cabeça.

No próximo capítulo, o dia mais louco até aqui: eu quis colocar inteligência artificial pra escrever as atas das reuniões — e entrei numa via-crúcis de trocar de robô três vezes antes de achar o caminho.

Dias 7 a 9 · 1 a 3 de abril – 2026

Primeiro de abril, e a brincadeira foi comigo. O sistema já engolia as planilhas de venda numa boa — até o dia em que uma delas veio gorda demais.

Toda vez que eu tentava subir o arquivo mais pesado, a resposta era a mesma: erro. Demorei pra cair a ficha de que o problema não era o meu código — era um limite da hospedagem. No plano que eu usava, nada acima de 4,5 megabytes podia ser enviado pro servidor de uma vez. E a planilha de um mês inteiro, com todas as marcas juntas, passava disso fácil.

Eu tinha dois caminhos: pagar por um plano maior ou ser mais esperto. Escolhi o segundo. A virada foi mudar onde a conta é feita. Em vez de mandar o arquivo cru pro servidor mastigar, passei a mastigar no próprio navegador — o computador de quem usa lê a planilha, organiza os números ali mesmo e manda pro sistema só o resultado, já limpo e leve. O arquivo pesado nunca precisa viajar.

Fiz primeiro pra planilha que dava erro e, quando vi que funcionava, estendi pra todas as importações. De quebra ficou até mais rápido — o servidor parou de suar com arquivo grande. E ainda encaixei um detalhe bobo que me pouparia cliques pra sempre: um botão “marcar todos” na hora de escolher as lojas. Dessas coisinhas que a gente só sente falta depois de ter.

Brasileiro é danado mesmo. Sempre “criativo” pra fugir das adversidades. Eu não podia fugir dessa máxima.

A lição do dia: nem todo muro se derruba na força — às vezes se passa por baixo. O limite da hospedagem parecia um beco sem saída, mas a resposta não era um servidor mais caro, e sim fazer o trabalho num lugar mais inteligente. Restrição, de vez em quando, é o melhor professor de engenharia.

No próximo capítulo, a fase chata e necessária de toda obra: parar de construir cômodo novo e arrumar a casa — jogar fora o que não presta e deixar tudo mais leve pro que vem pela frente.

Dias 4 a 6 · 29 a 31 de março – 2026

Três dias depois, o brinquedo já não era só meu. Outras pessoas precisavam usar — e isso muda tudo.

No dia 29 adicionei os primeiros usuários da equipe e, com eles, um monte de coisa “chata mas necessária”: resetar e apagar dados por estabelecimento, separar o que é de cada um. Também engordei os relatórios — comparar a semana com o mesmo período do mês anterior, olhar sábado e domingo separados. E tive minha primeira briga séria com versão de framework: uma atualização nova simplesmente parou de aceitar um jeito de montar as páginas que eu usava. Tive que refazer. (Bem-vindo a construir na ponta da tecnologia.)

No dia 30, mais lapidação — visão geral, comparativos, cancelamentos — e comecei a montar uma segunda peça do quebra-cabeça.

E aí veio o dia que, olhando pra trás, foi um divisor de águas. No dia 31 eu tinha duas coisas separadas: uma ferramenta de repasse/financeiro e um painel de vendas, cada uma por conta. Naquele dia juntei as duas numa só e dei um nome: Sistema de Gestão DMR. Parece pouco, mas foi o momento em que aquilo deixou de ser “uns experimentos que eu fiz” e virou um sistema — com identidade e um lugar pra crescer. No mesmo dia configurei a primeira “memória” do meu copiloto de IA, pra ele lembrar do projeto de um dia pro outro.

Aqui vale uma colocação bem pertinente: a equipe começou a entender do que se tratava, o poder da ferramenta e começou a demandar novos inputs e melhorias. Pensei: “me lasquei! Rsrsrsr. Agora o negócio ficou sério!”

A lição da primeira semana: ferramenta solta resolve um problema; sistema resolve o problema e aguenta crescer. Unificar cedo — dar um nome, um teto comum — foi o que abriu caminho pra tudo que veio depois.

E veio muita coisa. Porque esse “Sistema de Gestão” ainda nem sonhava que, uns meses à frente, viraria um portal tocado por robôs de IA com nome e personalidade. Mas isso é assunto pros próximos capítulos.

Dias 1 a 3 · 26 a 28 de março – 2026

Começou numa quarta-feira, quase 22h.

Tela preta, um primo tricolor online na tela que se dispôs a me ajudar a dar os primeiros passos, projeto vazio e uma ideia que não me deixava dormir: eu estava afogado em números de venda espalhados — cada plataforma de delivery, cada marca, um relatório num formato diferente. Eu queria um lugar só pra enxergar tudo.

Naquela noite criei o projeto do zero. Poucas horas depois já existia um primeiro painel: eu jogava a planilha que a plataforma cospe e ele me devolvia os números organizados, marca por marca. O primeiro parser*. E, claro, o primeiro bug — as colunas vinham trocadas e os totais saíam errados. Passei um tempão só acertando “qual coluna é qual”. Fui dormir tarde (ou cedo…rsrs), mas com aquela sensação boba e ótima de ver a primeira tela funcionar.

Aqui uma pausa pra agradecer ao primo tricolor que me explicou o que é Commit, Vercel, Claude Code e trouxe a programação de volta a minha vida. No grupo dos primos ele profetizou: “Galera, ensinei McGyver a voltar a codar. Prevejo noites insones pela frente!”. Os próximos posts provarão que ele é de fato um profeta. 😂

No dia seguinte, deixei quieto. (Faz parte — nem todo dia é dia de código.)

Aí veio a primeira parede. No dia 28 eu quis tirar aquilo do meu computador e colocar no ar, pra acessar de qualquer lugar. E aprendi do jeito difícil a lição que todo mundo aprende uma vez: funcionava na minha máquina, mas quebrava publicado. O motivo? Eu salvava os arquivos localmente, e na nuvem não existe “a minha pasta” — cada vez que o serviço reinicia, some tudo. Tive que reescrever a parte de armazenamento pra usar um armazenamento de nuvem de verdade. Deu conflito, deu dor de cabeça pra deixar o acesso privado, mas no fim do dia estava no ar.

A lição dos 3 primeiros dias: ideia vira protótipo rápido — o difícil é a realidade (dado bagunçado, “na nuvem nada é local”). E que começar feio e funcionando vale mais que planejar bonito e não sair do papel.

No próximo capítulo, esse painel deixa de ser só meu: aparecem os primeiros usuários, uma briga com a versão de um framework, e o dia em que dois protótipos soltos viram um sistema com nome.

*Parser é um componente ou programa que recebe dados desestruturados ou sequenciais (como textos e códigos) e os organiza em uma estrutura lógica e compreensível, geralmente uma árvore sintática.