Visão geral

Este documento é o material de apoio do vídeo do YouTube. Aqui você tem o passo a passo de como o Pagamentos Médicos foi construído — um app que resolve a dor de controle financeiro do que o médico recebe nas clínicas, criado 100% por linguagem natural dentro do Claude Code.

🗺️ Mapa da jornada

Etapa 1 — A dor que originou tudo

O problema real

Médico que atende em múltiplas clínicas vive um inferno silencioso: cada clínica tem sua própria régua de repasse, prazo, retenção, glosas, descontos. No fim do mês, ninguém sabe direito quanto deveria ter recebido, o que ainda está pendente e se o que caiu na conta confere com o que foi atendido.

Isso é trabalho de auditoria que ninguém faz. E o que não se mede, se perde.

A decisão

Em vez de aceitar a planilha de Excel mal feita ou pagar uma agência caríssima pra desenvolver um sistema, decidi construir eu mesmo — usando IA como a equipe inteira de desenvolvimento.

Etapa 2 — As regras do jogo antes de começar

Antes de digitar qualquer prompt, configurei dois documentos que governam todo projeto que eu inicio. Sem isso, IA vira bagunça.

Regras Globais (CLAUDE.md)

É um arquivo de regras que o Claude Code lê automaticamente em cada projeto. Define padrões de código, stack preferida, como nomear arquivos, como tratar erros, quando perguntar antes de agir.

Protocolo PROCEED

Meu framework de execução de projetos com IA. Define as fases (Plan → Refine → Organize → Code → Evaluate → Execute → Deploy) e o que precisa estar pronto antes de avançar pra próxima.

Etapa 3 — Backend primeiro (a engrenagem)

Por que comecei pelo backend

A ordem que faz sentido pra um app que resolve um problema real é diferente da ordem que faz sentido pra um app que vende uma promessa.

Quando o foco é resolver minha dor de controle financeiro, a primeira pergunta não é "como vai parecer?" — é "como os dados vão se comportar?". Backend primeiro = lógica funcionando antes de qualquer pixel.

A ferramenta: Anti-gravity

O Anti-gravity é o ambiente que usei como complemento ao Claude Code para acelerar o desenvolvimento — especialmente pela integração nativa com MCP servers (Notion, Stripe, Vercel, GitHub).

A dinâmica é simples: eu falo o que quero, em português, e o sistema escreve, testa, corrige, integra.

O que construí no backend

• Modelo de dados: clínicas, atendimentos, repasses, status de pagamento
• Regras de negócio: percentual de repasse, prazo, cálculo de pendências
• Endpoints (as "portas" que o frontend vai usar pra ler e escrever os dados)
• Autenticação preparada para receber Google depois

Exemplos de comandos reais que usei

"Crie o modelo de dados para clínicas (nome, CNPJ, percentual de repasse, prazo) e atendimentos (data, valor bruto, clínica vinculada, status: pendente/recebido)"

"Quando o médico marcar um atendimento como 'recebido', mova automaticamente da lista de pendentes pra lista de pagos e some no total do mês"

Etapa 4 — Frontend (a interface que o médico usa)

Com o backend rodando, o frontend faz sentido

Com os dados e regras já fluindo, construir o frontend virou um exercício de visualizar o que já existe — não de inventar lógica nova.

Isso muda tudo: cada tela tem um propósito claro, cada botão chama uma ação que já está pronta no backend, cada número exibido vem de um cálculo que já foi testado.

O que construí no frontend

• Dashboard principal: total recebido no mês, total pendente, evolução dos últimos 6 meses
• Listas filtráveis de atendimentos (por clínica, por status, por período)
• Telas de cadastro: clínicas, atendimentos, percentuais
• Componentes de visualização (gráficos, cards de KPI, indicadores)

Exemplos de comandos reais que usei

"Crie a tela principal do dashboard mostrando: total recebido no mês, total pendente, lista das últimas 10 transações, gráfico de evolução dos últimos 6 meses"

"Adicione um botão pra cadastrar uma nova clínica com os campos: nome, CNPJ, percentual de repasse, prazo de pagamento em dias"

Etapa 5 — Landing page (a porta de entrada)

Por que deixei a landing por último

Landing é a embalagem. Embalar um produto que ainda não funciona é vender promessa. Eu construí o app primeiro, validei que ele resolve a dor, e só depois fiz a landing — porque agora a copy não inventa: descreve o que o app realmente faz.

Isso elimina o risco de ter uma landing linda prometendo o que o produto não entrega.

Como construí — 21st.dev

O 21st.dev é um catálogo de componentes visuais (hero sections, cards, animações, backgrounds com efeitos) onde cada componente tem um botão "Copy prompt". Você copia o prompt, cola no Claude Code, e o componente aparece pronto no seu projeto.

Como usar na prática

1. Entre no 21st.dev
2. Navegue pela galeria, escolha o componente (ex: hero com gradiente animado)
3. Clique em Copy prompt
4. Cole no Claude Code dentro do seu projeto
5. O Claude monta o componente, ajusta as cores, adapta o conteúdo

Animações com Remotion

Pra dar vida à landing, usei o Remotion — uma biblioteca que permite criar vídeos e animações usando código React. Em vez de animar em After Effects ou Premiere, você descreve o que quer em código e renderiza.

No contexto da landing, usei Remotion para gerar pequenas animações — transições, gráficos animados, ilustrações em movimento — que mostram o produto em ação sem precisar gravar tela.

Você descreve em linguagem natural pro Claude Code: "crie uma animação de um gráfico de barras subindo, mostrando o crescimento do recebimento mensal, em estilo minimalista, paleta azul" — e o Claude gera o componente Remotion.

Etapa 6 — Login com Google

O que é autenticação Google

É o "Entrar com Google" que você vê em todo lugar. O usuário não cria senha — ele usa a conta Google dele e o app recebe a confirmação de identidade do Google.

Por que escolhi Google

• Médico não cria mais uma senha (já tem conta Google quase sempre)
• Sem responsabilidade de armazenar senha (Google cuida)
• Setup rápido via OAuth 2.0

Como implementei

Um prompt em linguagem natural pro Claude Code:

"Adicione autenticação via Google usando OAuth. O usuário deve poder logar com a conta Google dele. Após login, leve pra tela do dashboard. Persista a sessão."

Claude Code gerou o setup completo: configuração no Google Cloud Console, callback de autenticação, gerenciamento de sessão, redirecionamento.

Etapa 7 — Pagamentos com Stripe

O que é Stripe

Stripe é a plataforma de pagamentos online mais usada por SaaS no mundo. Você cria planos, conecta no seu app, e o Stripe cuida de cobrança recorrente, cartões, faturas, cancelamentos.

Como conectei

Mesma lógica: linguagem natural.

"Conecte o Stripe ao app. Crie 3 planos: Básico (R$ X), Pro (R$ Y), Premium (R$ Z). Quando o usuário clicar em 'Assinar' em qualquer plano, abra o checkout do Stripe. Quando o pagamento for confirmado, libere acesso ao plano correspondente."

Os planos no app

O app tem planos de assinatura conectados ao Stripe — quem assina libera os recursos pagos (ex: número ilimitado de clínicas, relatórios avançados, exportação).

Etapa 8 — Deploy na Vercel via MCP

O que é deploy

"Deploy" é colocar o app no ar, com URL pública, pra qualquer pessoa acessar. Sem deploy, o app só roda na sua máquina.

O que é Vercel

Vercel é a plataforma de hospedagem mais popular pra apps modernos (Next.js, React). Conecta com GitHub, faz build automático, dá URL pública, escala sozinho.

O que é MCP

MCP (Model Context Protocol) é um padrão que permite a IA conversar diretamente com ferramentas externas. Em vez de eu abrir o painel da Vercel e clicar em "Deploy", o Claude (via MCP) conversa direto com a Vercel e faz o deploy.

Como foi na prática

"Faça o deploy desse projeto na Vercel. Use o domínio padrão. Configure as variáveis de ambiente do Stripe e do Google Auth."

O MCP da Vercel dentro do Anti-gravity executou tudo: criou o projeto na Vercel, conectou ao GitHub, configurou as variáveis de ambiente, fez o build, retornou a URL pública.

Etapa 9 — Documentação dentro do próprio app

Dentro do Pagamentos Médicos eu coloquei toda a documentação que eu mesmo precisaria pra usar e manter o app: tutoriais de uso, FAQ, fluxo de cadastro de clínicas, como interpretar os relatórios.

É a regra do dogfooding: se eu não uso meu próprio produto com prazer, ninguém vai usar.

🎯 A lição central

Não construí um app porque sabia codar. Construí porque:

1. Tinha uma dor real e específica (controle financeiro multi-clínica)
2. Sabia descrever a dor com clareza clínica (médico é treinado pra isso — anamnese é especificação de produto)
3. Tinha um framework de execução (CLAUDE.md + PROCEED)
4. Usei IA como equipe de desenvolvimento inteira, falando em português

✅ Checklist pra você começar o seu app

Antes de abrir qualquer ferramenta

• Escrevi a dor em uma frase clara
• Descrevi quem é o usuário (eu? outros médicos? secretária?)
• Listei as 3 a 5 funcionalidades essenciais do MVP
• Decidi se vou cobrar ou se é uso pessoal

Setup inicial

• Criei meu CLAUDE.md global (regras de projeto)
• Estudei o Protocolo PROCEED
• Instalei Claude Code
• Configurei conta no GitHub

Desenvolvimento

• Construí o backend primeiro (modelo de dados + regras de negócio)
• Depois o frontend, consumindo o backend pronto
• Por último a landing (com 21st.dev e Remotion se quiser efeitos)
• Especifiquei comportamentos, não código
• Testei cada funcionalidade antes de avançar

Integrações

• Auth (Google ou outra) configurada
• Pagamento (Stripe ou outro) em modo teste
• Variáveis de ambiente em arquivo .env (nunca commitar)

Deploy

• Repositório no GitHub criado
• Deploy na Vercel feito
• Domínio configurado
• Modo produção do Stripe ativo

🔗 Links de referência

Material de apoio do canal IA para Médicos — Júlio Andrade

Domine a IA na sua prática médica 👇🏻

Método do Zero à IA na Prática Médica →