App de foco no vibe coding: o que medir além do tempo trabalhado

Antes de abrir o projeto principal da série, Thiago ajeita e ativa uma ferramenta que ele mesmo construiu para acompanhar o próprio foco. Ele conta na hora por que ela existe: diz ter dificuldade de manter o foco e que precisava de ajuda com isso. A ferramenta saiu de uma restrição concreta do dia dele, do tipo que atrapalha o trabalho toda semana.

Essa origem é o motivo de ela estar ligada quando ele senta para trabalhar. Mais tarde, na mesma live, o alerta do sistema disparou e cortou a frase dele na frente de quem estava assistindo.

O problema veio antes da ferramenta

A maior parte dos apps de foco é desenhada para um usuário médio com um problema médio de produtividade. O sistema dele começou dentro de um problema específico, o dele. Ele descreve o motivo com naturalidade, no meio do setup do dia: "eu criei, né, na verdade um sistema que que me ajuda a a ter foco".

Isso muda o desenho inteiro da ferramenta. Quem constrói para um usuário médio precisa adivinhar quais métricas importam. Quem constrói para si já sabe onde o próprio dia se perde.

O que a ferramenta mede, e o que quase nenhum app de foco mede

Ele lista ao vivo o que o sistema grava:

- quanto tempo ele fica trabalhando - quanto tempo ele fica navegando - a média por sessão trabalhada - o tempo em pausa, para saber quanto tempo ele está perdendo parado - quanto tempo o PC fica desligado

Os dois primeiros itens qualquer cronômetro entrega. Os outros são o que dá valor à medição, porque medem o vazio. Saber quanto tempo você trabalhou explica pouco sem a duração da sessão média e sem o tempo em que a máquina ficou parada, incluindo "quanto tempo o PC fica desligado". Os intervalos raramente entram em algum relatório, e é neles que a tarde vai embora.

Tem também a camada física. O sistema lembra de beber água e de se alongar de hora em hora, com um aviso sonoro. Nas palavras dele, "Tá dando um bip na minha orelha de uma em uma hora".

O alerta disparou no meio da live

Mais tarde, com a transmissão rodando e ele revisando uma lista de tarefas, o aviso chegou e ele parou no meio da frase:

Eita, o sistema aqui acabou de me avisar. Hora de se alongar e beber água. Clique aqui quando for iniciar sua pausa.

E ele obedeceu: "Então eu vou apertar OK. Vou me alongar." Agachou e levantou na frente da câmera, bebeu água, justificou com "senão a gente fica todo quadrado, torto, com dor nas costas, com dor no braço" e voltou ao trabalho.

Essa cena vale mais que qualquer print de dashboard, porque mostra a ferramenta ganhando de quem a escreveu, ao vivo, sem ensaio. Ele avisa no começo que vai parar algumas vezes ao longo da live, mas essa parada específica quem decidiu foi um software que ele escreveu, e ele acatou sem discutir.

Ele diz na live que pretende oferecer o sistema de graça para quem tiver interesse. Quando isso acontecer, a ferramenta já vai ter passado pelo teste mais barato que existe, que é o autor usando no próprio expediente, com o cronômetro rodando enquanto ele trabalha de verdade. Ninguém precisa marcar entrevista com usuário quando o usuário está sentado na cadeira.

Por que construir para si é onde o vibe coding paga mais rápido

O escopo é pequeno porque você já sabe qual comportamento quer mudar, e o feedback chega no mesmo dia, já que a pessoa que vai abrir o programa amanhã de manhã é você. O critério de sucesso é continuar abrindo depois que a novidade passa.

É aí que o vibe coding tem a melhor relação entre esforço e retorno. Um SaaS exige encontrar cliente e provar que alguém paga por aquilo. Uma ferramenta pessoal exige que funcione para uma pessoa, e essa pessoa está disponível para testar o dia inteiro. Na mesma live, ele faz o oposto com o projeto principal e prefere responder o questionário do agente antes do plano, com 15 perguntas sobre caixa, tempo e capacidade.

Ele construiu para resolver o próprio problema, usou, e só então pensou em distribuir, nessa ordem. Quem começa pela ideia de produto costuma terminar com uma ferramenta que nem o autor abre uma segunda vez.

O que fazer com isso amanhã

Pegue a coisa que te atrapalha toda semana e que você já tentou resolver com força de vontade. Escreva o que você quer medir sobre ela, incluindo o lado feio: o tempo parado, o tempo na aba errada, o tempo com a máquina desligada. Construa a versão mínima que registra isso e que consegue te interromper com um som no fone. Depois use por alguns dias.

Se você abandonar a ferramenta na primeira semana, ela não resolvia um problema real seu, e dificilmente resolveria o de outra pessoa. Se ela te interromper e você levantar da cadeira, você tem uma coisa que funciona antes de ter produto. Dá para assistir à live inteira e ver o momento em que o alerta ganha da vontade dele de continuar trabalhando.