O primeiro módulo levou um dia. O que veio antes levou dois anos.

Se eu contar só o número, ele soa como propaganda: o primeiro módulo da nossa plataforma ficou pronto em um dia. Uma semana depois, quatro pessoas estavam usando.

O número é verdadeiro. E ele é enganoso, porque antes dele vieram dois anos.

Por onde a gente começou, e por quê

O primeiro foi a gestão do imposto de renda.

Não porque fosse o mais importante, mas porque era a dor que eu conseguia descrever de olhos fechados. A gente controlava aquilo em três planilhas. Quem entregou, quem pagou, quem não pagou. Se alguém mexia, não havia registro de quem mexeu nem do que mudou. Não tinha log, não tinha histórico, não tinha acesso organizado.

Era chato, era manual e era arriscado — a combinação exata que pede software.

Por que um dia bastou

Porque eu não estava inventando um processo. Eu estava transcrevendo um que eu domino.

Quando você sabe fazer, fica fácil no seguinte sentido: você já tem o processo na cabeça, você conhece cada exceção, você sabe onde ele costuma falhar. Transformar isso em software vira quase tradução. O que me custou não foi programar — foi ter, antes, clareza absoluta de qual dor eu ia atacar.

Essa é a parte que eu recomendaria a quem está pensando em começar: o gargalo não é técnico. Se você não consegue explicar a dor em duas frases, o dia não vai bastar.

O que veio antes: dois anos e um monte de GPT

A Trady está nessa jornada há dois anos, estudando o uso de inteligência artificial dentro do escritório de verdade — não em apresentação.

Nesse período a gente tinha vários GPTs funcionando. Eles ajudavam. Mas todos dependiam de uma coisa frágil: a ação do humano. Alguém precisava lembrar de usar. E aí você descobre que não está fazendo um projeto de tecnologia, está fazendo um projeto de cultura. Tem que motivar, tem que insistir, tem que lidar com o medo do novo — que é legítimo, ainda mais com tanta gente falando besteira sobre o assunto.

Esse é o tempo que não aparece no "um dia". Ele aparece na qualidade da pergunta que eu consegui fazer no primeiro dia.

O teste que salvou o projeto

Terminei e mandei para a Fabiana, minha sócia, que é especializada em processos.

Ela usou de verdade. E foi me devolvendo os apontamentos: o que falhava, o que estava faltando, o que ela enxergava e eu não. Foram dois dias assim, ela usando e eu ajustando. Depois abrimos para o time — em uma semana, as quatro pessoas do processo já estavam dentro, dando retorno também.

E a planilha continuou existindo. Não foi eliminada de cara: a gente rodou os dois lados em paralelo, de propósito, para validar a jornada inteira do aplicativo antes de confiar nele. Isso não é desconfiança do software, é método. Sistema novo se prova contra o processo antigo, não contra a expectativa de quem construiu.

O que eu achei que seria simples e não foi

Colocar no ar.

O software estava pronto e estava no meu computador. Local, como se diz. Como é que aquilo virava um endereço na internet que o time inteiro acessa?

Isso foi um desafio de tecnologia, sim. Mas foi principalmente um desafio de medo. Sair da minha máquina significava responsabilidade sobre acesso, sobre segurança, sobre o que acontece se cair. São perguntas que você só é obrigada a responder quando decide que aquilo não é mais um teste seu.

Foi ali que o projeto deixou de ser meu e virou da empresa.

E foi ali que as coisas começaram a quebrar — que é o assunto do próximo texto.