NutriX — Plataforma de saúde adaptativa em produção
- 35+
- Rotas
- 32
- Migrations
- 8
- Módulos
Cliente
NutriX
Setor
HealthTech — Nutrição e performance B2C
Linha do tempo
8 fases · 2026
Produto ao vivo
Usar agoraResultados
Resultados reportados pelo cliente durante o rollout
Baseline: mapa de rotas Phase 8
Fonte: docs/ROUTES.md
Baseline: schema versionado
Fonte: migrations/
Baseline: fases entregues
Fonte: docs/
Baseline: engines, API, privacidade
Fonte: docs/
Dados reportados pelo cliente
O desafio
O desafio
NutriX é uma plataforma completa de saúde adaptativa em produção. O usuário faz um diagnóstico, recebe plano de nutrição e programa de treino calculados por motores determinísticos, executa dia a dia e o sistema adapta — com coach de IA, análise de refeição por foto e acompanhamento profissional opcional.
Apps de dieta entregam PDF estático que ignora a rotina real. O cliente precisava de uma plataforma que calculasse plano de nutrição e treino de forma determinística, adaptasse semanalmente conforme execução, e escalasse para um modelo de negócio com assinaturas, afiliados e acompanhamento profissional — tudo com privacidade de dados de saúde.
A abordagem
A abordagem
Estruturamos em fases de produto, cada uma entregando um loop real: fundação técnica, nutrição, treino + inteligência, visão computacional, commerce, afiliados, cuidado profissional e integrações de saúde. Motores determinísticos primeiro — IA só entra onde agrega, nunca onde decide sozinha.
A solução
A solução
O produto cobre o ciclo completo de saúde do usuário:
- Onboarding resumível: objetivo, rotina, preferências e restrições em poucos minutos
- Motor de nutrição determinístico: Mifflin-St Jeor, targets versionados, plano semanal de 7 dias gerado do catálogo TACO/USDA
- Motor de treino versionado com sessão ao vivo: logging de séries, timer de descanso e feedback
- Today: state machine de próxima ação que guia o dia do usuário
- Luna: coach contextual com intent determinístico, safety layer e respostas honestas
- NutriX Vision: foto da refeição via token de uso único, estimativa com bandas de confiança e revisão obrigatória do usuário
- Commerce: assinaturas provider-agnostic com adapter Mercado Pago, checkout e gestão de billing
- Afiliados: dashboard com links, métricas, comissões e payouts
- Portal profissional: nutricionistas e treinadores verificados com escopos de acesso revogáveis pelo usuário
Linha do tempo
Como o projeto foi conduzido, do mapeamento ao deploy. How the project was conducted, from mapping to deploy.
Fases 1–2
Fundação
- React + Vite + Workers + D1
- Auth, onboarding resumível
- Motor de nutrição + plano semanal
Fases 3–4
Inteligência
- Motor de treino + sessão ao vivo
- Luna (coach contextual)
- NutriX Vision + camada de IA
Fases 5–8
Negócio
- Commerce Mercado Pago + afiliados
- Portal de profissionais com escopos
- Health integrations + legal
Metodologia
Como o projeto foi conduzido, do mapeamento ao deploy. How the project was conducted, from mapping to deploy.
Fases de produto com loop real entregue em cada uma — nada de scaffold sem função
Motores determinísticos com targets e programas versionados para auditoria
Camada de IA com registry de modelos, roteamento por tarefa, timeout e fallback controlado
Privacidade por design: tokens de uso único, magic bytes, escopos revogáveis
Documentação por domínio: ROUTES, API, engines, privacidade e design system
Arquitetura
- → SPA React servida pelo Worker — assets estáticos e API no mesmo runtime
- → API Hono /api/v1 com guards de auth, role e escopo por rota
- → D1: 32 migrações versionadas — planos, targets, programas e logs versionados
- → R2: mídia privada com tokens de uso único e magic-byte validation
- → Motores determinísticos isolados: nutrição, treino, adaptação
- → Gateway de IA: registry → routing por tarefa → timeout → fallback → cost ledger
- → Commerce: adapters provider-agnostic com webhooks assinados e deduplicados
Diagrama conceitual — não reflete implementação real
Stack tecnológica
Escolhas técnicas e o que ficou para fora.
Frontend
Por quê: SPA rápida com code-splitting por rota — vision e affiliate são chunks lazy.
Alternativa rejeitada: Next.js (rejeitado — SSR desnecessário, Worker já serve tudo)
Por quê: 35+ rotas com guards de auth e role por rota.
Alternativa rejeitada: TanStack Router (rejeitado — maturidade do ecossistema)
API e Edge
Por quê: API e assets no mesmo runtime edge — um deploy, latência mínima.
Alternativa rejeitada: Express/VPS (rejeitado — custo fixo e região única)
Por quê: Validação de schema em toda borda da API.
Alternativa rejeitada: Validação manual (rejeitado — divergência garantida)
Dados
Por quê: SQLite distribuído com 32 migrações versionadas.
Alternativa rejeitada: Supabase (rejeitado — D1 cobre com menos peças móveis)
Por quê: Mídia privada com tokens de uso único para fotos de refeição.
Alternativa rejeitada: S3 (rejeitado — egress e complexidade)
IA
Por quê: Registry de modelos, roteamento por tarefa, timeouts, fallback controlado e ledger de custo.
Alternativa rejeitada: Chamada direta a um provider (rejeitado — lock-in e zero controle de custo)
Commerce
Por quê: Provider-agnostic: MP em produção, Mock em dev/CI, webhooks assinados.
Alternativa rejeitada: Stripe-only (rejeitado — Pix via MP é essencial no Brasil)
Decision log
O que escolhi, o que rejeitei e por quê.
Motores determinísticos antes da IA
Por que: Plano alimentar e de treino precisam ser auditáveis, reproduzíveis e defensáveis. A IA (Luna) opera como camada contextual read-only com safety checks — ela explica e orienta, não prescreve.
Alternativas rejeitadas: IA gerando planos direto (rejeitado — alucinação em contexto de saúde é inaceitável); regras hardcoded sem versionamento (rejeitado — impossível auditar mudanças).
Workers + D1 na edge
Por que: SPA servida globalmente com latência mínima e custo próximo de zero em escala inicial. API Hono no mesmo Worker, D1 com 32 migrações versionadas, R2 para mídia privada.
Alternativas rejeitadas: VPS/Node tradicional (rejeitado — custo fixo e latência regional); Supabase (rejeitado — D1 já atendia com menos peças móveis).
Visão com revisão obrigatória
Por que: Estimativa de refeição por foto é probabilística — o sistema entrega estimativa com banda de confiança e exige confirmação do usuário antes de logar. Upload privado via token de uso único, validação por magic bytes.
Alternativas rejeitadas: Log automático sem revisão (rejeitado — erros de estimativa virariam dados de saúde falsos); upload público (rejeitado — privacidade).
Commerce provider-agnostic
Por que: Adapter pattern para pagamentos: Mercado Pago em produção, Mock em dev/CI, troca de provider sem reescrever assinaturas, webhooks assinados e deduplicados.
Alternativas rejeitadas: Acoplamento direto ao Mercado Pago (rejeitado — migração de provider viraria rewrite); Stripe-only (rejeitado — mercado-alvo é Brasil, Pix via MP é essencial).
Assistente de IA
Luna — pipeline do coach contextual
Contexto mínimo: apenas o estado relevante do usuário entra no prompt
Intent determinístico: classificação da pergunta antes de qualquer modelo
Safety layer: bloqueio de prescrição, dosagem e aconselhamento médico
Ferramentas read-only: Luna lê plano e progresso, nunca escreve
Resposta honesta: admite limitação e redireciona para profissional quando cabe
Progressão e aderência
Anel do dia
Today mostra progresso "1/6" do dia com refeições, peso e treino marcados.
Aderência
Logs de execução alimentam /nutrition/adherence e a revisão semanal.
Revisão semanal
Check-in NutriX: corpo mudou, rotina mudou — plano reajusta.
Planos versionados
v1 → v2 → v3: cada adaptação gera nova versão auditável do plano.
Segurança e acesso
Privacidade e segurança de dados de saúde
-
CSP restritiva com frame-ancestors 'none' e headers de hardening
-
Upload de fotos via token de uso único + validação por magic bytes
-
Escopos de acesso revogáveis para profissionais de saúde
-
Webhooks de pagamento assinados e deduplicados
-
bcrypt para credenciais, validação Zod em toda borda da API
Lições aprendidas
Nem tudo saiu como planejado.
— Em produto de saúde, a confiança é o feature. Cada decisão — IA read-only, revisão obrigatória de estimativas, escopos revogáveis para profissionais — existe porque dado de saúde errado não é bug, é dano.
Veja também outros produtos
Nexus IA Nexus IA — Plataforma de IA
Plataforma de IA com 620+ endpoints REST, Nexus Auto com roteamento automático entre 20+ modelos, workspace com agente autônomo, multimodal e 6 planos comerciais.
Ver case →
TigreBet TigreBet
Produto de jogos online onde o jogador entra, aposta via PIX e sobe de nivel VIP. 11 jogos, provably fair e saques com KYC.
Ver case →
VulnStrike VulnStrike
Scanner de vulnerabilidades SaaS: digite um domínio e receba nota de segurança A+–F com achados explicados e correção passo a passo — scan grátis sem cadastro.
Ver case →Quer um produto como esse?
Posso fazer o mesmo para o seu negócio. Vamos conversar.