De 0 a 100 Clínicas: Como Construí o ProABA

Quase dois anos atrás, entrei num projeto que mudou minha carreira. Não era um app de delivery, nem uma rede social, nem um SaaS de produtividade.

Era uma plataforma para terapeutas que atendem crianças com autismo.

Hoje, o ProABA é usado diariamente por ~100 clínicas e centros de terapia no Brasil. Cada clínica atende entre 10 e 100 crianças. A plataforma não pode cair — porque quando cai, terapeutas não conseguem trabalhar.

Esse é o tipo de responsabilidade que não aparece no portfólio de ninguém. Mas é o que define se você sabe entregar de verdade.

O problema que precisava ser resolvido

Terapeutas ABA no Brasil gerenciavam tudo em planilhas, papel e WhatsApp. Registros de crianças, avaliações clínicas, planos de intervenção, relatórios de evolução — tudo fragmentado.

O problema não era técnico. Era humano:

• Dados se perdiam entre sessões
• Não havia continuidade quando um terapeuta saía
• Relatórios para pais eram feitos manualmente
• Compliance com protocolos era difícil de rastrear

O ProABA precisava resolver isso com uma plataforma que:

• Funcionasse todo dia útil, sem falhas
• Atendesse dezenas de clínicas, cada uma com seu fluxo
• Fosse intuitiva para profissionais de saúde (não devs)
• Suportasse português e inglês
• Tratasse dados sensíveis de saúde com segurança

A stack — e por que escolhemos cada peça

Não escolhemos tecnologia por hype. Escolhemos pelo problema.

Tecnologia	Por quê
Next.js (App Router)	SSR + Server Actions = menos API boilerplate, mais velocidade de entrega
TypeScript strict	Dados de saúde não podem ter erros silenciosos
Prisma + MySQL	Schema tipado + migrations = confiança em mudanças de banco
Playwright	Testes E2E em fluxos críticos (registro, avaliação) — se quebrar, sabemos antes do terapeuta
Tailwind CSS	Consistência visual numa equipe de 20 devs
BetterAuth	Autenticação robusta sem reinventar a roda
next-intl	i18n real — não só tradução de botão, mas formulários, mensagens de erro, relatórios
Sentry	Monitoramento de erros em produção — sabemos quando algo quebra antes que reclamem
Docker	Deploy previsível — funciona local = funciona em produção

O que eu construí

Não sou “o dev do ProABA”. Sou um de 20 desenvolvedores. Mas contribuí em praticamente todas as camadas — do formulário que o terapeuta preenche ao erro que aparece no Sentry às 23h.

Sistema de registro multi-step

Wizard que coleta dados detalhados sobre cada criança: informações pessoais, contatos de emergência, histórico médico. Cada etapa com validação via Zod, campos opcionais inteligentes, tudo bilíngue.

O desafio real: Terapeutas preenchendo formulários entre sessões, com pressa, no celular. O formulário precisava ser rápido, perdoar erros, e nunca perder dados no meio do caminho.

Ferramentas de avaliação clínica

Componentes para scoring por nível e grupo, visualizações individuais que terapeutas usam durante a sessão com a criança. Performance importa aqui — não pode ter lag enquanto o terapeuta observa e registra comportamentos em tempo real.

Planos de intervenção e notas clínicas

Toda criança tem um plano de intervenção que precisa ser acompanhado sessão a sessão. Construí a navegação entre etapas do plano, drawer buttons para ações rápidas, e o CRUD completo de notas — onde o terapeuta registra observações durante o atendimento.

O que aprendi: Funcionalidade de “atendimento ao cliente” em saúde é diferente de qualquer outro setor. Cada campo precisa ser rápido, preciso e funcionar offline-first na cabeça do terapeuta. Sem animações bonitas — só dados confiáveis.

Design e UX para quem não é dev

Os usuários do ProABA são terapeutas, coordenadores de clínica, pais. Nenhum deles sabe (ou precisa saber) o que é React. Interface aqui não é “bonita” — é invisível. Componentes como LevelGroupSelector, filtros de busca por criança, e visualizações de PersonDetails foram desenhados para que a pessoa encontre o que precisa em 2 cliques ou menos.

Participei diretamente do design de componentes reutilizáveis, sistema de cores consistente via Tailwind, e responsividade real (não “funciona no celular só pra dizer que funciona”).

Monitoramento e logging com Sentry

Site de clínica de saúde não pode ficar fora do ar em silêncio. Integrei Sentry para capturar erros em produção com contexto: qual usuário, qual fluxo, qual ação. Isso nos permitiu saber de um bug antes que o terapeuta abrisse ticket.

Na prática: quando um Server Action falhava, o Sentry capturava o stack trace + os dados da requisição. Em vez de receber um “não tá funcionando” no WhatsApp, a gente já sabia o que, onde e por quê.

AI no workflow de desenvolvimento

Não usei IA no produto (ainda). Usei no processo de construir o produto:

• GitHub Copilot para autocompletar patterns repetitivos (i18n keys, Zod schemas, testes Playwright)
• Claude para debug de problemas complexos — explicar o contexto, receber hipóteses, testar
• ChatGPT para rascunhar documentação técnica e coding guidelines

Resultado prático: estimei 30-40% mais velocidade em tarefas de scaffolding e boilerplate. O código criativo — a arquitetura, as decisões, o “isso funciona pra terapeutas” — continua sendo humano.

Padrões de qualidade para 20 devs

Este foi o trabalho menos “glamouroso” e mais impactante. Criei:

• Templates de PR padronizados
• Coding guidelines documentados
• Convenções de nomenclatura para todo o projeto
• Remoção de dead code com Knip e refatoração contínua de hooks e stores

Com 20 pessoas commitando, sem padrão = caos. Esses docs são o que mantém o projeto sustentável depois de ~2 anos.

Testes que importam

Não testamos tudo. Testamos o que não pode quebrar:

• Fluxo de registro de criança (E2E com Playwright)
• Avaliações clínicas
• Planos de intervenção
• Server Actions críticas (tipadas com Zod)

Se uma atualização quebra o registro de uma criança, o teste pega antes de ir pra produção.

Os números

Depois de quase 2 anos, estes são os fatos:

Métrica	Valor
Clínicas ativas	~100
Crianças por clínica	10-100
Commits pessoais	646
Features implementadas	108
Bugs corrigidos	134
Refatorações	128
Idiomas suportados	PT + EN
Downtime não planejado	Zero durante minha contribuição

646 commits não é vanity metric. É consistência. É estar presente quando o deploy dá errado às 22h de uma sexta-feira.

Os erros (e o que aprendi)

Se eu só mostrasse os números bonitos, você deveria desconfiar. Então vou ser honesto:

Erro 1: Over-engineering cedo demais

Nos primeiros meses, construí abstrações para cenários que nunca aconteceram. Hooks genéricos, componentes ultra-configuráveis. YAGNI existe por um motivo — não construa para requisitos que ninguém pediu.

O que mudei: Hoje, código entediante é o meu padrão. Se funciona e é simples, não mexo.

Erro 2: Não medir desde o início

Passamos meses sem métricas de uso. Não sabíamos quais fluxos eram mais lentos, onde usuários desistiam, quantos acessos diários tínhamos.

O que mudei: Sentry para erros, analytics para comportamento. Não dá pra melhorar o que não se mede.

Erro 3: Subestimar i18n

“É só traduzir uns textos” — essa é a maior mentira do desenvolvimento. i18n afeta formulários, validações, mensagens de erro, formatação de data, moeda, e até layout (textos em inglês são mais curtos que em português).

O que mudei: Tratamos i18n como feature de arquitetura, não como task de UI.

O que você pode tirar disso

Não importa se você está construindo um SaaS, uma LP, ou um site institucional. Esses princípios se aplicam:

1. Entenda o problema antes de codar. Eu faço 5 perguntas antes de escrever qualquer linha de código. A primeira: “Que problema estou resolvendo?” — não “que tecnologia uso”.

2. Código previsível > código inteligente. Seus usuários não se importam se você usou um design pattern elegante. Eles se importam se funciona quando precisam.

3. Testes são investimento, não custo. Cada bug que o Playwright pega antes de ir pra produção é uma clínica que não parou de funcionar.

4. Padrões escalam, talento individual não. Aqueles templates de PR e coding guidelines foram o melhor investimento de tempo que fiz no projeto.

5. Erros são trust signals. Se alguém diz que nunca erra, ou está mentindo ou nunca fez nada difícil.

Quer resultado similar?

Se você precisa de um site profissional, uma landing page que converte, ou um sistema web construído com a mesma disciplina e cuidado do ProABA:

Sites a partir de R$797 · LPs a partir de R$397 · Código 100% seu

Fale comigo no WhatsApp →

---

Marcos Souza — Full Stack Developer, Rio de Janeiro. Construo produtos e compartilho o que aprendo no caminho.