Contexto
Trabalho sozinho, fazendo design e front-end para clientes pequenos, quase todos no mesmo nicho: clínicas, cursos e eventos de fisioterapia. São muitos projetos abertos ao mesmo tempo, cada um com um site no ar onde um push errado vai para produção.
Antes disso trabalhei em agência. O que me frustrava não era o volume, era o briefing frio: chegava um documento dizendo o que fazer, sem eu ter conversado com quem ia usar. O processo era em cascata, e numa cascata basta uma falha de comunicação em qualquer ponto para o projeto inteiro se perder. Nem sempre o que o cliente pede é o que ele precisa, e eu não tinha como descobrir.
Dois limites meus também entram nessa conta. Não decido cor a olho; preciso do número. E com muitas frentes abertas, a pergunta que fica sem resposta é o que mais se perde: não por desinteresse, mas porque a atenção já foi para a próxima coisa.
O problema
A pergunta nunca foi "como usar IA". Foi: como um designer sozinho mantém qualidade de produção em vários projetos, sem equipe, sem esquecer decisão de cliente e sem publicar o que não devia?
Os riscos eram concretos, porque cada um já tinha acontecido ou quase:
- um deploy sem querer, num servidor compartilhado onde o caminho errado sobrescreve o site do vizinho;
- uma cor escolhida porque "ficou bonita" e que não passa de contraste;
- uma decisão que o cliente tomou numa conversa e que ninguém anotou;
- um depoimento ou um preço inventado pela ferramenta para preencher o vazio;
- uma pergunta minha que o cliente não respondeu, e que eu também esqueci de repetir.
A abordagem
Existe um tipo de profissional, o forward deployed engineer, que fica alocado dentro do cliente, entende como ele trabalha de verdade, constrói o software para aquela realidade e devolve o que aprendeu como sistema. Eu fiz isso comigo mesmo como cliente.
O processo foi o mesmo que uso com qualquer projeto. Conversar e entender onde a pessoa está. Saber quem vai usar. Prototipar rápido, na mão. Pedir para a IA prototipar em cima do rabisco. Validar. Testar com gente de verdade. Aplicar, aprender, refinar. A diferença é que a pessoa era eu, e o "produto" era o meu dia de trabalho.
A regra que saiu dessa investigação: limite vira método quando vira regra escrita, não força de vontade. Tudo o que eu fazia "de cabeça" e às vezes esquecia passou a ser um arquivo que a ferramenta lê antes de começar.
O sistema
Cada peça existe para cobrir uma falha específica. Nenhuma foi planejada de cima para baixo; todas nasceram de um erro ou de um quase-erro.
Gatilhos de deploy em linguagem natural. "Fechou" e "pode commitar" significam commit, e a ferramenta pergunta "Posso publicar?" antes de qualquer push. "Pode publicar" é o único sim. Em repositório onde push não publica nada, a regra inverte: commit e push sempre, para não perder conteúdo. Cobre o deploy acidental.
Cor é número, não impressão. Toda cor chega com três coisas: o hex, o papel dela (fundo, texto, ação) e a razão de contraste calculada contra o fundo real. "Ficou bom" não é resposta aceita. Cobre a decisão de cor a olho.
Memória externa versionada. Um arquivo por fato, com data: quem é o cliente, o que ele decidiu, o que nunca fazer. Um índice de uma linha por arquivo é lido em toda sessão. Decisão de cliente anotada com a data em que foi tomada. Cobre a decisão esquecida e o conteúdo inventado: sem material do cliente, a regra é marcar como pendente, nunca preencher.
Uma pergunta por vez, e a lista viva. As pendências ficam numa lista que a ferramenta reapresenta no início e no fim de cada bloco de trabalho, separando o que depende de mim do que depende de outra pessoa. Perguntas vêm uma de cada vez, começando pela que destrava trabalho. Cobre a pergunta perdida.
Um CLAUDE.md por projeto. As regras que não mudam: o caminho de deploy no servidor compartilhado, o que é proibido, as convenções do código. É o briefing que eu nunca recebi na agência, escrito para a ferramenta e para o meu eu de daqui a seis meses.
Um ambiente que se restaura sozinho. A configuração inteira, regras, memória e atalhos, vive num repositório privado. Em qualquer Mac novo, um script devolve o mesmo ambiente de trabalho.
Ferramentas que saíram do processo. O rabisco rápido virou um kit de prototipagem em papel que o cliente usa junto comigo. A dificuldade de igualar fotos de equipe virou um script que recorta retratos por detecção de rosto. Cada vez que um problema se repetiu, ele virou ferramenta.
Na prática
O Reeduca Fisio prepara fisioterapeutas para a prova de título de especialista em terapia intensiva. A ideia era um app de quiz para iPhone com questões reais das provas anteriores, organizadas por tema e com a fonte de cada uma.
O caminho óbvio era a especialista criar as questões. Mas eu conversei antes de desenhar, e o que vi foi uma pessoa que trabalha o dia inteiro na clínica e dá aula à noite. Pedir a ela 120 questões do zero era pedir um projeto que nunca sairia do papel, não por falta de vontade, por falta de horas.
Então inverti a dependência. As provas de 2023, 2024 e 2025 existiam em PDF. Um script lê cada prova, transcreve as questões para o banco do app com as alternativas e o gabarito, propõe um tema e palavras-chave para cada uma e marca tudo como não revisada. Questão anulada fica fora. Questão com figura fica oculta até o app saber mostrar imagem. Nada entra no quiz sem passar por uma pessoa.
Para a especialista, gerei uma planilha por prova, no formato que ela já usa: uma linha por questão, o tema proposto, uma coluna "Tem imagem" e uma de observação. O trabalho dela deixou de ser "criar 119 questões" e virou "conferir 119 questões", que cabe numa noite. Um segundo script aplica a revisão dela no banco e sobe a build nova para o TestFlight.
Num dos PDFs a estrutura da prova era diferente das outras. Em vez de adivinhar, a pergunta ficou registrada na lista de pendências até ela responder. É o sistema inteiro num exemplo pequeno: entender como a pessoa trabalha, construir para aquela realidade, deixar a validação humana no meio e não inventar nada.
O que mudou
Antes, um projeto parado por duas semanas voltava com perguntas. Onde estava o texto da cliente? Ela aprovou aquela cor? Qual era o caminho do deploy? Hoje abro a sessão e a primeira coisa que aparece é a lista do que ficou pendente, com quem está a bola.
Antes, "fechou" podia ser um deploy. Hoje "fechou" é um commit e uma pergunta.
Antes, a IA preenchia o espaço vazio com um depoimento plausível e eu precisava caçar o que era inventado. Hoje o espaço vazio fica marcado como pendente, e o cliente sabe o que falta mandar.
E o que eu mais gosto: trabalho mais do que trabalhava na agência, porque investigo antes de desenhar. Só que agora a investigação não se perde entre um projeto e outro.
O que aprendi
- A IA não substitui a conversa com o cliente. Ela entra depois do rabisco na mão, nunca antes.
- O risco não é a ferramenta errar. É a pergunta ficar sem resposta.
- Um limite que vira regra escrita deixa de ser limite. Vira a parte mais confiável do processo.
- O método que uso com clientes serve para mim. Entender a fundo, construir para a realidade encontrada, devolver como sistema.
"Entender como alguém trabalha de verdade e devolver isso como ferramenta."
Este case é para quem precisa de alguém que faça exatamente isso dentro de uma empresa: entender um domínio a fundo e devolvê-lo como sistema utilizável. Vamos conversar.