NutriX — Adaptive health platform in production
- 35+
- Routes
- 32
- Migrations
- 8
- Modules
Client
NutriX
Sector
HealthTech — B2C nutrition and performance
Timeline
8 fases · 2026
Live product
Use nowResults
Client-reported results during rollout
Baseline: Phase 8 route map
Fonte: docs/ROUTES.md
Baseline: versioned schema
Fonte: migrations/
Baseline: delivered phases
Fonte: docs/
Baseline: engines, API, privacy
Fonte: docs/
Client-reported data
The challenge
The challenge
NutriX is a complete adaptive health platform in production. Users take a diagnostic, receive nutrition plans and training programs computed by deterministic engines, execute daily and the system adapts — with an AI coach, photo-based meal analysis and optional professional supervision.
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.
The approach
The approach
We structured it in product phases, each delivering a real loop: technical foundation, nutrition, training + intelligence, computer vision, commerce, affiliates, professional care and health integrations. Deterministic engines first — AI only enters where it adds value, never where it decides alone.
The solution
The solution
The product covers the user's complete health cycle:
- Resumable onboarding: goal, routine, preferences and restrictions in minutes
- Deterministic nutrition engine: Mifflin-St Jeor, versioned targets, 7-day meal plan generated from the TACO/USDA catalog
- Versioned training engine with live session: set logging, rest timer and feedback
- Today: next-action state machine guiding the user's day
- Luna: contextual coach with deterministic intent, safety layer and honest answers
- NutriX Vision: meal photo via single-use token, confidence-banded estimation and mandatory user review
- Commerce: provider-agnostic subscriptions with Mercado Pago adapter, checkout and billing management
- Affiliates: dashboard with links, metrics, commissions and payouts
- Professional portal: verified nutritionists and trainers with user-revocable access scopes
Timeline
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, resumable onboarding
- Nutrition engine + weekly plan
Fases 3–4
Inteligência
- Training engine + live session
- Luna (contextual coach)
- NutriX Vision + AI platform layer
Fases 5–8
Negócio
- Mercado Pago commerce + affiliates
- Professional portal with scopes
- Health integrations + legal
Methodology
Como o projeto foi conduzido, do mapeamento ao deploy. How the project was conducted, from mapping to deploy.
Product phases each delivering a real loop — no scaffold without function
Deterministic engines with versioned targets and programs for auditability
AI layer with model registry, per-task routing, timeouts and controlled fallback
Privacy by design: single-use tokens, magic bytes, revocable scopes
Per-domain documentation: ROUTES, API, engines, privacy and design system
Architecture
- → React SPA served by the Worker — static assets and API on the same runtime
- → Hono API /api/v1 with auth, role and scope guards per route
- → D1: 32 versioned migrations — versioned plans, targets, programs and logs
- → R2: private media with single-use tokens and magic-byte validation
- → Isolated deterministic engines: nutrition, training, adaptation
- → AI gateway: registry → per-task routing → timeout → fallback → cost ledger
- → Commerce: provider-agnostic adapters with signed, deduplicated webhooks
Conceptual diagram — does not reflect real implementation
Tech stack
Technical choices and what was left out.
Frontend
Why: Fast SPA with per-route code-splitting — vision and affiliate are lazy chunks.
Rejected alternative: Next.js (rejected — SSR unnecessary, Worker serves everything)
Why: 35+ routes with auth and role guards per route.
Rejected alternative: TanStack Router (rejected — ecosystem maturity)
API & Edge
Why: API and assets on the same edge runtime — one deploy, minimal latency.
Rejected alternative: Express/VPS (rejected — fixed cost, single region)
Why: Schema validation at every API boundary.
Rejected alternative: Manual validation (rejected — guaranteed divergence)
Data
Why: Distributed SQLite with 32 versioned migrations.
Rejected alternative: Supabase (rejected — D1 covers it with fewer moving parts)
Why: Private media with single-use tokens for meal photos.
Rejected alternative: S3 (rejected — egress costs and complexity)
AI
Why: Model registry, per-task routing, timeouts, controlled fallback and cost ledger.
Rejected alternative: Direct provider calls (rejected — lock-in, zero cost control)
Commerce
Why: Provider-agnostic: MP in production, Mock in dev/CI, signed webhooks.
Rejected alternative: Stripe-only (rejected — Pix via MP is essential in Brazil)
Decision log
What I chose, what I rejected, and why.
Deterministic engines before AI
Why: Nutrition and training plans must be auditable, reproducible and defensible. The AI (Luna) operates as a read-only contextual layer with safety checks — it explains and guides, never prescribes.
Rejected alternatives: AI generating plans directly (rejected — hallucination in a health context is unacceptable); hardcoded rules without versioning (rejected — impossible to audit changes).
Workers + D1 at the edge
Why: SPA served globally with minimal latency and near-zero cost at initial scale. Hono API on the same Worker, D1 with 32 versioned migrations, R2 for private media.
Rejected alternatives: Traditional VPS/Node (rejected — fixed cost and regional latency); Supabase (rejected — D1 covered the need with fewer moving parts).
Vision with mandatory review
Why: Photo-based meal estimation is probabilistic — the system returns a confidence-banded estimate and requires user confirmation before logging. Private upload via single-use token, magic-byte validation.
Rejected alternatives: Auto-logging without review (rejected — estimation errors would become false health data); public upload (rejected — privacy).
Provider-agnostic commerce
Why: Adapter pattern for payments: Mercado Pago in production, Mock in dev/CI, provider swap without rewriting subscriptions, signed and deduplicated webhooks.
Rejected alternatives: Direct Mercado Pago coupling (rejected — provider migration would be a rewrite); Stripe-only (rejected — target market is Brazil, Pix via MP is essential).
AI Assistant
Luna — contextual coach pipeline
Minimal context: only relevant user state enters the prompt
Deterministic intent: question classification before any model
Safety layer: blocks prescriptions, dosage and medical advice
Read-only tools: Luna reads plan and progress, never writes
Honest answers: admits limitation and refers to professionals when needed
Progression and adherence
Day ring
Today shows "1/6" daily progress with meals, weight and workout checked.
Adherence
Execution logs feed /nutrition/adherence and the weekly review.
Weekly review
NutriX check-in: body changed, routine changed — plan readjusts.
Versioned plans
v1 → v2 → v3: every adaptation generates a new auditable plan version.
Security and access
Health data privacy and security
-
Restrictive CSP with frame-ancestors 'none' and hardening headers
-
Photo upload via single-use token + magic-byte validation
-
Revocable access scopes for health professionals
-
Signed and deduplicated payment webhooks
-
bcrypt for credentials, Zod validation at every API boundary
Lessons learned
Not everything went as planned.
— In a health product, trust is the feature. Every decision — read-only AI, mandatory estimation review, revocable scopes for professionals — exists because wrong health data isn't a bug, it's harm.
See also other products
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.
View 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.
View 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.
View case →Want a product like this?
I can do the same for your business. Let's talk.