Mi Nutricionista Mobile App
Patient-facing nutrition app that turns daily food tracking, chat, plans, appointments, and AI meal estimates into one mobile workflow.
Timeline: Built and captured through mobile QA flows in June 2026.
Team: Solo builder/operator.
Stack: React Native, Expo, TypeScript, Supabase architecture, AI meal estimation, mobile QA
Problem: Nutrition apps often split coaching, food logging, appointments, and progress across separate tools. The product needed a mobile surface where a patient can see goals, chat with a nutritionist, log meals, estimate macros, track progress, and keep the relationship active.
What I built:
- Built a mobile patient experience with home dashboard, nutritionist chat, profile, plan, appointments, food diary, meal categories, and progress surfaces.
- Implemented meal logging flows for text, photo, barcode-style entry points, manual macro review, and local AI nutrition estimates before save.
- Designed the app around real patient behavior: daily goals, remaining calories, macro progress, check-ins, reminders, and low-friction actions.
- Captured verified mobile screenshots from QA flows so the portfolio can show product proof without exposing production health data.
Architecture: Mobile app -> patient workflow screens -> nutrition coaching/chat surface -> meal diary and AI estimate flow -> private backend/product layer.
Reliability: Screenshots come from QA capture flows; private patient data, production credentials, and backend logs are not exposed.
Tradeoffs: Public proof shows product surfaces and flows instead of production data or private clinical workflows.
Impact: Adds a concrete mobile product proof point: not just SaaS dashboards, but a patient app with daily use loops and AI-assisted nutrition tracking.
Evidence: Mobile screenshot set: home, chat, dashboard, plan, appointments, diary, and AI estimate flows.
Agent Bubble
Public AI agent interaction surface built to feel like a product, not a prompt box.
Timeline: Prototype-to-public demo sprint; current public surface is live.
Team: Solo builder.
Stack: Next.js, TypeScript, Vercel, AI workflow architecture
Problem: Agent demos often look like internal tools. The project needed a public surface that could communicate AI workflow value quickly to recruiters, clients, and collaborators.
What I built:
- Built a public agent/chat product surface with responsive UI and production deployment.
- Structured the experience around product proof instead of a generic chat interface.
- Kept private agent actions, credentials, and production logs out of the public surface.
Architecture: Browser UI -> Next.js app -> private AI workflow/backend layer -> deployment on Vercel.
Reliability: Public route smoke-tested after deploy; private actions and credentials are intentionally not exposed.
Tradeoffs: Kept the public demo lightweight instead of exposing private backend controls or logs.
Impact: Provides a live AI-workflow proof link aligned with the portfolio positioning.
Evidence: Live demo + screenshot evidence page.
Titan Agent Fleet
Distributed AI operating environment across Windows, Linux, macOS, and GPU infrastructure.
Timeline: Built iteratively as the operating layer for real agent work across multiple machines.
Team: Solo builder/operator.
Stack: OpenClaw, LiteLLM, vLLM, Docker, systemd, Caddy, Tailscale, GPG vaults, Windows, Linux, macOS
Problem: AI work was fragmented across chats, tools, machines, credentials, codebases, browser tasks, and deployment environments. The system needed persistent memory, task delegation, model fallback, browser access, and production-grade execution discipline.
What I built:
- Designed a multi-host agent operating model with memory/wiki context, tool permissions, sub-agent delegation, scheduled jobs, and verification rules.
- Routed workloads by host capability: local coordination, GPU/model serving, media/video processing, browser automation, and infrastructure operations.
- Integrated cloud model usage with local fallback through LiteLLM/vLLM and OpenAI-compatible endpoints.
- Created SOPs for build checks, smoke tests, browser checks, endpoint validation, and incident-aware execution.
- Used the fleet as a real execution team: briefing tasks, assigning workflows, reviewing output, correcting direction, testing results, and shipping artifacts.
Architecture: Telegram/user request -> OpenClaw orchestration -> tools/sub-agents -> local/cloud models -> verification gates -> deploy/report.
Reliability: Uses permissioned tools, vault-based secrets, build/lint/smoke gates, deployment checks, and explicit blocker reporting.
Tradeoffs: Private by design: host access, credentials, logs, and customer/business data cannot be public proof artifacts.
Impact: Reusable internal AI operations platform for building, debugging, deploying, and auditing software/business systems faster.
Evidence: Architecture notes + this case study + repeated deploy/build validation logs.
WhatsApp Business Agent
CRM and follow-up automation architecture for inbound business conversations.
Timeline: Built as CRM and follow-up automation inside a broader business operations stack.
Team: Solo builder/operator.
Stack: Next.js, Supabase, webhooks, WhatsApp architecture, Vercel, TypeScript
Problem: Manual WhatsApp follow-up creates missed leads, weak context, and repeated operator work. The system needed structured capture, classification, logging, and follow-up scheduling.
What I built:
- Implemented inbound classification, contact/profile upsert, conversation logging, message logging, and follow-up scheduling.
- Built webhook routes, inbox UI, simulated outbound fallback, cache fixes, local build checks, smoke tests, and production endpoint validation.
- Kept private contact data, conversations, credentials, and business logs out of public proof surfaces.
Architecture: Inbound WhatsApp/webhook event -> classification -> Supabase contact/profile upsert -> conversation/message log -> follow-up schedule -> inbox UI.
Reliability: Local build checks, smoke tests, endpoint validation, no-store cache headers, and private-data boundaries.
Tradeoffs: Public case study describes architecture and scope without exposing real customers, phone numbers, private messages, or credentials.
Impact: Turns repeated WhatsApp follow-up into a trackable CRM workflow with clearer ownership, history, and next actions.
Evidence: Scoped case-study details + deployment/process validation notes.
nutricionista.ai
AI-enabled SaaS platform for nutrition professionals and patients.
Timeline: Multi-phase SaaS build with public surface and private role-based workflows.
Team: Founder-led / solo full-stack implementation.
Stack: Next.js, React, TypeScript, Supabase, Postgres, Vercel, Stripe architecture, shadcn/ui
Problem: Nutrition professionals need patient management, CRM, AI productivity, billing architecture, onboarding, and patient portal workflows in one system.
What I built:
- Built admin dashboard, CRM, leads, patient workflows, appointments, resources, onboarding, integrations, and role-based surfaces.
- Built patient portal PWA and SEO directory for nutritionist discovery.
- Added AI feature foundations for meal planning, recipes, lab interpretation, growth, and progress analysis.
- Implemented Supabase data layer and Vercel deployment workflows.
- Shipped 35+ routes and 80+ components across admin, CRM, leads, patients, appointments, team roles, onboarding, resources, integrations, and patient portal surfaces.
Architecture: Next.js app -> Supabase/Postgres -> role-based surfaces -> Vercel deployment -> public marketing/SEO surface.
Reliability: Private health/patient workflows are not public; public surface is live. Claims are limited to route/component scope instead of unverified user/revenue metrics.
Tradeoffs: Public proof avoids exposing health data, admin workflows, billing internals, or private AI workflows.
Impact: Large SaaS surface with 35+ routes, 80+ components, multiple role-based workflows, patient portal, admin tooling, and AI feature foundations.
Evidence: Live public surface + screenshot evidence page + scoped case-study details.