← voltar ao portfólio

// estudo de caso · projeto pessoal

Agenda Nelci Leite · Podologia

Aplicativo que substituiu o caderno de papel de uma podóloga. Seis telas, uma usuária, nenhuma tela de configuração. O caso mais útil do portfólio para mostrar como eu decido escopo — porque metade do trabalho foi tirar coisa.

Papel: projeto pessoal, ponta a ponta Stack: React · TypeScript · Firebase · PWA Código: repositório privado (dado de paciente)

O problema

A Nelci é podóloga e atende cerca de cinco pacientes por dia. O paciente marca pelo WhatsApp; ela anota numa agenda de papel. São dois lugares que não conversam.

A dor não era "não ter sistema". Era que o papel não é pesquisável, enquanto a marcação acontece em outro lugar. Como muito paciente marca e depois quer trocar de horário, toda remarcação virava uma sincronização manual entre um chat e um caderno: achar a pessoa no papel, apagar, achar vaga nova, voltar no WhatsApp, confirmar. Várias vezes por dia.

O diagnóstico veio de cinco perguntas sobre a rotina real, não de um brainstorm de funcionalidades. Sem elas, eu teria construído um sistema de gestão de clínica — e ela teria continuado no caderno.

O que foi construído

Seis telas, e uma regra: nada pede que ela aprenda um jeito novo de trabalhar. Ela continua marcando como marca hoje; o que muda é onde a informação fica.

O toque em "atendida" na tela Hoje já é o registro do atendimento. Ela não digita nada a mais — e esse toque gera exatamente o histórico de que a fase seguinte precisa. Registro que exige trabalho extra é registro que não acontece.

O app instala na tela inicial do celular como PWA. Para uma usuária não-técnica, "abrir o navegador e digitar o endereço" já é atrito suficiente para o projeto morrer.

A ponte com o WhatsApp: dez linhas em vez de uma integração

O botão "Avisar no WhatsApp" é um link wa.me com a mensagem já escrita — abre a conversa do paciente no telefone dela, e ela só toca em enviar. Sem API oficial, sem verificação de negócio na Meta, sem automação intermediária, sem custo mensal.

Isso mata a parte mais chata da remarcação — reescrever a mensagem toda vez — com um punhado de linhas. A camada oficial pode entrar depois, se um dia fizer falta. Começar por ela seria pagar uma conta antes de ter o problema.

Onde eu decidi NÃO colocar IA

O reflexo óbvio seria um bot de IA atendendo o WhatsApp. Eu fiz a conta: são cerca de dez mensagens por dia. Ela responde melhor e mais rápido do que qualquer bot, e em contexto de saúde o tom importa — mensagem automática sobre tratamento soa errada com muita facilidade.

IA que não paga o próprio custo é enfeite caro. O mesmo filtro tirou da v1 a ficha clínica (dado pessoal sensível na LGPD, entra quando puder ser feito direito), os relatórios (derivam do registro — com dois meses de uso saem quase de graça) e toda tela de configuração, que é dúvida transformada em interface.

Modelagem: a decisão que barateou tudo

Agendamento e atendimento são o mesmo registro, mudando de status. É por isso que o toque no círculo sai de graça: ela não cria nada, só muda um campo. Em duas coleções separadas, ela teria que registrar duas vezes — e não registraria.

No mesmo espírito, o status faltou existe desde a v1, mesmo sem tela para ele. É o dado mais valioso que ninguém coleta no começo, e histórico retroativo não se inventa.

Como se sabe que funcionou

O critério não é elogio. São três semanas rodando em paralelo com o caderno: se ela largar o papel sozinha, funcionou. Se voltar para o papel, a pergunta certa é "o que o caderno faz que o app não faz" — e a resposta vale mais do que qualquer funcionalidade planejada.

O teste de usabilidade é entregar o celular sem explicar nada e pedir quatro coisas: quem vem hoje depois do almoço, mudar o horário de uma paciente, marcar outra como atendida, achar um terceiro pelo nome. Ficar calado e anotar onde ela hesita. Cada hesitação é defeito de interface, não falha de entendimento dela.

O que eu precisei saber para construir isso

entrevistar antes de projetar Cinco perguntas sobre a rotina real mudaram o produto inteiro. O volume baixo — cinco atendimentos por dia — foi o dado que derrubou metade das ideias, e eu só teria descoberto perguntando.
regra de segurança como fronteira A chave do Firebase no front é pública por natureza: dá para ler no navegador de qualquer jeito. Quem protege o dado é a regra do Firestore, não o segredo da chave — e "autenticado" sem lista de UIDs significa qualquer pessoa que criar conta no projeto.
acessibilidade obriga decisão de design Calculei o contraste das cinco cores da marca: três não passam para texto. Em vez de descartá-las, dei função a elas — cada serviço virou uma cor. E o estado "atendida" nunca é comunicado só por cor: tem opacidade, risco no nome e círculo preenchido.
fuso horário e casos-limite de telefone Data "solta" faz o horário aparecer três horas deslocado — bug que só se descobre quando o paciente não vem. E testar se um número já tem o código do país por "começa com 55" dá falso positivo: DDD 55 existe, é Santa Maria. Testar pelo tamanho.
LGPD como restrição de escopo Nome e telefone são dado pessoal. Ficha clínica, evolução e foto são dado pessoal sensível, com regime bem mais rígido. Saber a diferença é o que define o que pode entrar agora e o que precisa de preparo antes.

Próximo passo

A fase seguinte é a lista de retorno: paciente que não volta não reclama, não aparece em lugar nenhum e some sem ninguém notar. Ela só vem depois de dois meses de registro acumulado — antes disso não há o que ler.

Conversar sobre um projeto assim