Maestro: o app de treino que eu desenhei e construí de ponta a ponta com IA

Os apps de academia que eu uso são ruins, e o Maestro nasceu dessa irritação. É um app de treino que liga professor e aluno: o professor monta a rotina e acompanha a evolução, e o aluno registra cada série no celular. Em outubro de 2026, 3 professores e 17 alunos usam o app de verdade.

Foi o meu primeiro app nativo, feito sozinha a partir de julho de 2026, do design system no Figma ao código em Flutter. Eu não sou desenvolvedora. O código foi escrito por agentes de IA que eu criei e orquestrei, e as decisões de produto que este case conta são minhas.

Aprender antes de publicar

O projeto começou com uma escolha de meta. Na mesa havia duas: montar logo a esteira de publicação nas lojas ou aprender Flutter sem prazo de loja. Fiquei com a segunda. Stack nova custa semanas antes de chegar à loja, e eu preferia entender o que estava construindo a correr atrás de uma data.

Até ali, todo app mobile que eu tinha feito era PWA. Escolhi Flutter porque já tinha desenhado dois apps nele. Dos concorrentes, tirei a referência do que um app de treino precisa resolver; a parte visual não veio deles.

Duas restrições moldaram o resto. Medida corporal é dado de saúde, sensível pela LGPD (art. 11), por isso o banco fica em São Paulo e o consentimento entra no fluxo do produto. E a IA do app tem teto: US$ 30 por mês.

A decisão de deixar o vínculo nascer dos dois lados

No primeiro desenho, só o professor convidava. O aluno que queria levar o próprio personal para o app não tinha caminho nenhum. Em 27 de julho, decidi espelhar o convite para os dois lados, sem fluxo de aceite: qualquer um chamava o outro e o vínculo estava feito.

Quatro dias depois, desconfiei da minha própria solução e perguntei: "não seria mais fácil... ter um código fixo... ou isso é arriscado?". O código fixo virou endereço. Digitar o código de alguém manda um pedido, e quem recebe aceita. Com isso voltei atrás no "sem aceite" de julho, e os códigos antigos ainda não usados pararam de valer.

A outra metade da decisão chegou em 20 de agosto. O professor pode cadastrar a ficha de um aluno, com medidas, antes de o aluno ter conta. Entre três propostas, escolhi um híbrido em que o aluno decide quando entra pelo código: sem o sim dele, as medidas são apagadas e não ficam com ninguém.

Assumi um limite junto: quem nunca resgata o código segue sem saber que existe num banco. E a decisão mexeu com os dois lados. O aluno ganhou um caminho próprio até o professor, e o professor perdeu o vínculo automático que tinha antes.

A decisão de não deixar a IA prescrever carga no escuro

A IA do Maestro ajuda o professor a montar o treino do aluno. A primeira regra que eu dei a ela foi sobre carga: sem histórico de treino, ela não sugere peso nenhum. Com histórico, a carga aparece como sugestão explícita, porque, como eu disse na época, "temos dias bons e dias ruins de treino e nem sempre dá pra manter".

A segunda regra mudou depois de um teste meu. A versão antiga recusava qualquer assunto de saúde, e eu pedi um "treino de hipertrofia focado em lipedema". A regra derrubaria o pedido, justo de quem mais precisa de um treino pensado para a sua condição. Corrigi: "o disclaimer deve ser que precisa do aconselhamento de um profissional".

Desde 8 de agosto, a condição de saúde é entrada do treino. A IA usa o que a pessoa conta como contexto e continua recusando diagnóstico, laudo, remédio e dieta. Na dúvida entre recusar e adaptar, ela adapta.

A IA também nunca grava sozinha. O chat não salva nada no treino do aluno, e o rascunho que ela monta cai numa tela de revisão do professor. Escolhi ainda três limites de produto: a resposta chega inteira, sem streaming, porque o filtro de carga precisa ler tudo antes de mostrar; sair da tela encerra a conversa; e cada pessoa tem 20 mensagens a cada 24 horas.

Até outubro de 2026, nenhum desses limites gerou reclamação. O custo ficou longe do teto: na primeira medição, em agosto, foram US$ 0,78 em 30 dias, 2,6% do orçamento. Cobrar pela IA ficou registrado como pergunta em aberto, porque sem dado de uso qualquer preço seria chute.

A decisão de dar ao token o mesmo nome no Figma e no código

Desde 2 de agosto, o Figma usa o nome literal que o token tem no código Dart, e um teste automático confere se os dois batem. Em 13 de agosto, os 20 tokens conferidos batiam. Para as divergências, decidi que o código vence: o Figma é corrigido até alcançar o app.

Em 26 de agosto, fiz uma rodada de escolhas no sistema. Criei um degrau novo de espaçamento e declarei como exceção quatro espaçamentos miúdos, com o porquê escrito no código. E tirei o eixo de vidro do input depois de perguntar "isso não é uma inconsistência?".

Na mesma rodada, mandei criar o botão de CTA contra a recomendação do agente. Ele queria tratar o caso como bug, apoiado numa regra do projeto que estava velha: o código já tinha mudado, com o contraste medido. A minha escolha fechou uma dívida que o próprio código declarava.

Medido nas páginas de componente, o Figma tem 1.107 propriedades de espaçamento ligadas a token e 57 sem token, das quais 55 são as exceções declaradas. O teste confere só o nome do token; o valor fica de fora, e em outubro ainda havia divergências abertas. Prefiro deixar isso escrito a dizer que tudo bate.

A decisão de tirar Editar e Vídeo do menu

Em 9 de setembro, chegou a primeira reclamação de campo: um professor não conseguia subir os vídeos dos exercícios. A minha leitura foi direta: "o card precisa ter essas opções fora. Como botões." Pedi três propostas e escolhi a mistura de duas delas, em que Editar e Vídeo saem do menu e viram botões no card.

Aceitei duas perdas. O card deixou de diferenciar o exercício que ainda está sem vídeo do que já tem vídeo, e quem começa o gesto em cima de um botão não consegue arrastar o bloco. O atalho direto para o upload ficou de fora: subir um vídeo levava cinco toques e passou a levar dois.

Crédito

Fiz o Maestro de ponta a ponta, com o suporte da IA. Não sou desenvolvedora, então preciso da IA para escrever o código. Quem orquestrou tudo fui eu: criei os agentes que escreveram o código, os guardrails que seguram esses agentes e os evals que conferem o resultado. Até o registro de decisões do projeto foi escrito por um agente, e as decisões registradas ali são minhas.

Os guardrails que eu mais defendo são quatro. Um teste confere se os nomes de token batem entre Figma e código. Uma auditoria de segurança e LGPD procura vazamento de dado sigiloso. Uma checagem cuida da qualidade do código. E há travas para quem tem problema de saúde quando a IA monta o treino.

O que eu faria diferente

Se começasse hoje, colocaria a IA no centro e desenharia a experiência a partir dela, com um app mais conversacional, mais perto de um assistente. É uma aposta minha, olhando como o uso de apps tem mudado depois da IA no dia a dia das pessoas.

A revisão do professor continuaria. O tema é sensível, e não dá para excluir a revisão 100%. O que mudaria é o alcance da IA, que entraria em avaliação, insights e planejamento. É para lá que eu quero levar o Maestro.