I turn complex product problems into software systems.

Optimization engine

The queue-backed CP-SAT meal-planning engine solves real coaching constraints across macros, meal slots, recipe availability, allergens, diet rules, and regeneration scope. Immutable plan versions let the product poll progress, explain failures, and regenerate safely.

Domain and database architecture

I modeled the coaching domain in Prisma/Postgres around coaches, clients, immutable plan versions, recipes, collections, ingredients, unit conversions, adherence, training, and Stripe-backed billing. I kept tenancy, solver history, and admin workflows in one data model.

Full-stack product architecture

I built the product as a pnpm/Turborepo monorepo across a Next.js web app, Fastify API, Expo mobile app, BullMQ worker runtime, and shared contracts, database, solver, telemetry, and UI packages. I kept product rules and API contracts aligned across every surface.

AI-assisted workflows

The in-app assistant generates meal plans, regenerates meals, adjusts macros, inspects client progress, and exports plans through a validated internal tool pack.

Other workflows use AI inference for constrained classification and decision steps, with outputs limited to explicit enums before product logic acts on them. I routed tool calls and inference outputs through the same tenant-scoped API and RBAC model as the product, so automation stayed inside real permissions and workflows.

Observability and incident debugging

I wired OpenTelemetry, Prometheus, Loki, Tempo, Grafana, and a dedicated private observability runtime. I added a Tailscale-backed private network and a read-only MCP layer for debugging API failures, queue health, solver runs, and frontend issues without exposing internal tooling publicly.