Como reescrevi o NeuroPace do zero depois do Gemini Hackathon — e o que aprendi construindo IA para estudantes neurodivergentes

Fiquei em 15º lugar no Gemini Hackathon do Google entre mais de 35.600 participantes.
Depois disso, tive duas opções:
colocar o troféu na prateleira ou fazer o projeto de verdade.

Escolhi a segunda.
Este post não é um pitch. É um relato das decisões técnicas que tomei ao transformar um MVP de hackathon em um produto com fundações reais — e o que aprendi no processo sobre acessibilidade cognitiva e design de sistemas de IA.

O problema com o MVP original
O NeuroPace da hackathon funcionava, mas tinha as fundações que você esperaria de algo construído em sprint: frontend em HTML/CSS/JS puro, sem banco de dados (tudo em sessão), sem autenticação, e uma arquitetura de chamadas à API do Gemini que funcionava lindamente no papel e explodia em produção.
O maior culpado? Um loop de análise multimodal disparando chamadas em paralelo sem controle de rate limit. Passei dois dias só reescrevendo a fila de requisições.
Para uma demo de 3 minutos, estava ótimo. Para um produto que vai ser usado por estudantes com TDAH no meio de uma sessão de estudos — inaceitável.

A reescrita: decisões e porquês
Frontend: de HTML puro para Next.js 14 + TypeScript
A migração não foi por modismo. Foi porque o público do NeuroPace exige componentes de acessibilidade que são trabalhosos de manter sem uma estrutura sólida:

Tipografia adaptável (tamanho, espaçamento, família de fonte para dislexia)
Layout de baixa densidade de informação
Transições suaves para não disparar sobrecarga sensorial

Com TypeScript, os contratos entre os componentes de UI e a lógica de adaptação ficaram explícitos. Bugs que antes apareciam em runtime passaram a aparecer no editor.
Backend: adicionando persistência real com PostgreSQL
A ausência de banco de dados era o maior limitador do MVP. O sistema "esquecia" o aluno a cada sessão.
O problema central do NeuroPace é longitudinal: ele precisa aprender como aquele aluno específico processa informação ao longo do tempo. Sem persistência, não há grafo de conhecimento. Sem grafo de conhecimento, não há adaptação real — só personalização superficial de sessão.
Migrei para FastAPI + SQLAlchemy 2.0 + PostgreSQL. O schema central gira em torno de três entidades: User, Session e KnowledgeNode.
Os nós de conhecimento acumulam um score de confiança que decai com o tempo (para implementar o SRS — Spaced Repetition System) e se conectam via arestas de pré-requisito.
Detecção de sobrecarga cognitiva: do heurístico para algo mais robusto
Na versão da hackathon, o "score de confusão" era calculado com heurísticas simples: tempo entre mensagens, comprimento das respostas do aluno, presença de palavras como "não entendi" ou "confuso".
Funcionava. Mas gerava falsos positivos com frequência.
Na versão atual, o score é alimentado por três sinais:

Padrão linguístico: o Gemini analisa as mensagens do aluno em busca de marcadores de frustração e desorientação conceitual
Comportamento de sessão: velocidade de digitação, revisões frequentes, abandono de perguntas no meio
Histórico do nó: se o aluno já demonstrou dificuldade com aquele conceito antes, o threshold para acionar a mudança de abordagem é mais baixo

Quando o score ultrapassa o threshold, o prompt do sistema é reconstruído dinamicamente: respostas mais curtas, mais analogias, divisão em micro-passos. Para TDAH, bullet points ao invés de parágrafos.
Autenticação:
nada de muito especial mas resolveu o problema de sessão, perfis e segurança de dados em um dia. O tempo que economizei foi investido no que realmente diferencia o produto.

O que aprendi construindo para neurodivergentes
Acessibilidade cognitiva não é acessibilidade visual.
Contraste alto e fonte grande são necessários, mas insuficientes. Acessibilidade cognitiva é sobre:

Carga de informação por tela: quanto o usuário precisa processar de uma vez
Previsibilidade: o usuário sabe o que vai acontecer quando clica em algo
Ritmo: o sistema respeita o tempo do usuário, não impõe o seu próprio

Isso mudou como estruturo prompts. Uma "boa resposta" para um usuário com TDAH não é a resposta mais completa. É a resposta mais curta que ainda resolve o problema imediato — com uma oferta explícita de aprofundamento se o aluno quiser.
Construir IA adaptativa exige métricas de adaptação.
É fácil dizer "a IA se adapta ao aluno". É difícil saber se a adaptação está funcionando. Precisei definir o que seria "sucesso" em cada interação: o aluno fez uma pergunta de follow-up? Completou a sessão? Voltou no dia seguinte?
Sem essas métricas, a adaptação é teatro.

Estado atual e próximos passos
O MVP está funcional e em fase privada. A stack completa:

Frontend: Next.js 14, TypeScript, Tailwind CSS, shadcn/ui
Backend: FastAPI, SQLAlchemy 2.0, PostgreSQL
IA: Gemini 3 Flash (multimodal: texto, imagem, PDF)
Infra: Vercel (frontend), Railway (backend/DB), Cloudflare R2 (storage) por enquanto, depois vou comprar um domínio e colocar em um servidor melhor

Os próximos passos antes de abrir para early access: testes com usuários reais neurodivergentes e refinamento das métricas de adaptação com base no feedback.
Mas tenho um problema que ainda não sei como resolver, manter algo assim no ar não é barato, ainda mais se varias pessoas começarem a usar, já que a chave que eu uso, por ser grátis tem diversos limites.
Provavelmente, mais para frente, terei que cobrar para as pessoas poderem usar o programa, algo que consiga pelo menos manter o projeto no ar.