Case studies · 2026

Applied AI systems, built end to end.

I designed and built every project below. Each one shows the problem, what I built, a simple architecture and the stack.

Status labels are literal: one anonymized case study built from real sales conversations; the rest are demos, prototypes and tools I use myself.

01Anonymized case studyPrivacy-first

Sales-process audit — eye clinic, Lima (anonymized case study).

Started from the clinic’s real sales conversations across WhatsApp, Instagram and Facebook, anonymized and extrapolated them into a 450-conversation dataset to protect patient privacy, and ran the full audit: 7-stage operations diagram, per-stage drop-off, Pareto analysis (5 causes ≈ 82% of lost sales), loss estimated in money per cause (PEN 395K–575K/yr on the modeled volume), and remediation options per cause.

450
conversations in the anonymized dataset
7
stages in the operations diagram
≈82%
of lost sales explained by 5 causes
395–575K
PEN / yr estimated loss, modeled volume

Patient privacy by design

Healthcare conversations can’t be handled like ordinary sales data. The real chats were anonymized, then extrapolated into a modeled 450-conversation dataset that keeps the sales patterns and leaves the patients out. The same approach gives any clinic a full audit without exposing a single patient.

Problem

An eye clinic in Lima knew patients were dropping off in chat, but not at which stage, why, or what it was costing.

Approach

Each conversation was classified by an LLM against an analysis rubric I designed, grounded in sales-process and data-analysis frameworks from my curated knowledge base.

Outcome

Five causes ranked by impact, each with a money estimate and remediation options across process, people, technology and commercial. The figures are modeled estimates of loss, not revenue recovered.

Architecture

Real chats are anonymized and extrapolated, classified by an LLM against a rubric, mapped to a 7-stage funnel, ranked with Pareto and priced into a report.Real chatsWhatsApp · IG · FBAnonymize+ extrapolate to 450LLM classifiermy analysis rubricFunnel model7-stage drop-offPareto5 causes ≈ 82%ReportPEN + remediation
  • LLM classification
  • rubric design
  • Pareto analysis
  • Python
Code available on request
02Demo · fictional restaurant

Restaurant ordering: from chat to kitchen to rider, on one order code.

Problem

At peak hours a chicken-and-grill place gets orders by chat faster than anyone can type them. Kitchen and delivery coordinate by shouting, and nobody knows what sold best last week.

What I built

A conversational ordering agent that takes the order against the real menu and emits a structured JSON order once the customer confirms. Orders land on a live kanban panel with five states. The kitchen group gets Start / Ready buttons and riders get Take. A weekly report shows top items, peak hour and average ticket, plus a rules-based operations coach.

Design decision

The panel owns the database and exposes an API; the orchestrator calls the API instead of writing to Postgres. The panel runs and is tested on its own, without the agent.

Architecture

Customer chat goes to an n8n workflow with an LLM that emits a JSON order, posted to a FastAPI orders API, which feeds the kitchen and rider groups and a live panel.Customer chatTelegram demon8n + LLMmenu → JSON orderOrders APIFastAPI · PostgresKitchen · ridersbutton callbacksLive panelkanban · report

The demo runs on Telegram; a real deployment would run the same flow on WhatsApp.

  • structured outputs
  • LLM agents
  • Python
  • FastAPI
  • Postgres
  • n8n
  • Telegram Bot API
  • webhooks
03In production · arnailab.com since Aug 2026

Ar: a website assistant that answers, qualifies and captures leads.

Problem

Visitors land on arnailab.com after hours with questions about services and process. A contact form loses most of them.

What I built

A chat assistant served from its own FastAPI service. A curated corpus goes whole into the system prompt, a short tool-use loop registers leads, and history is rebuilt from Postgres on every request because serverless memory can’t be trusted. A 15-message cap per session keeps cost bounded, and a password-protected dashboard shows sessions and leads.

Design decision

No vector database. The corpus is small enough to fit in context, so retrieval would add failure modes with no gain. The LLM provider (OpenAI or Anthropic) is swappable by environment variable.

Architecture

The site widget calls a FastAPI chat endpoint, which prompts an LLM with the full corpus, can call a lead-registration tool, and stores history and leads in Postgres.Site widgetNext.jsChat APIFastAPI /chatLLM + corpuswhole corpus in promptLead toolregister_leadPostgreshistory + dashboard
  • LLM agents with tool use
  • RAG / grounded assistants
  • guardrails
  • OpenAI / Claude APIs
  • Python
  • FastAPI
  • Postgres (Supabase)
  • Next.js
  • TypeScript
  • Vercel
Try it liveCode available on request
04Prototype · tested with a real user

FIS.IO: a voice coach for lower-back pain where safety runs before the model.

Built for and tested with a real user with chronic lower-back pain. Typing on a phone was hard, so voice is the main input. In a health context, a wrong answer to an urgent symptom is the one failure that can’t happen.

Safety before the LLM

Red flags are detected by regex before any LLM call. If one matches, the user gets a fixed message written by a human: the model never improvises on an urgent symptom. Every red flag has its own tests, including false positives that must not fire.

What I built

Voice notes are transcribed with Whisper. A second model call extracts a persistent clinical profile from spoken language, stored per phone number. A stage machine controls what the agent may do and which sections of a McGill-method corpus it receives.

Design decision

Not a RAG. A ~15K-token corpus fits in context, so retrieval would only add ways to fetch the wrong passage. The corpus is trimmed by stage to keep cost and token rate in check.

Architecture

A voice note is transcribed, then checked by regex red-flag triage. Urgent matches return a fixed human-written message; otherwise the profile and stage select the corpus for the LLM.Voice noteWhisper transcriptionRed-flag triageregex · before LLMProfile + stagePostgres, per phoneLLMstage-scoped corpusText replyvoice in, text outFixed messagehuman-written, if urgent

Not a medical device. It does not diagnose; urgent symptoms are routed to emergency care with a fixed message.

  • guardrails & deterministic triage
  • RAG / grounded assistants
  • OpenAI APIs
  • Whisper
  • Python
  • FastAPI
  • Postgres
  • Vercel
Code available on request
05Prototype · discontinuedNo public demo

Government-plan RAG: answers only what the plan actually says.

Prototype built for a prospective client, a municipal election campaign. The plan promised AI-powered public services but had no execution path. The opportunity didn’t move forward; the infrastructure below is what was built.

Guardrails for the public sector

The assistant answers only from the curated plan. If a question falls outside municipal competence, it says so. If the plan has no figure (a budget, a target), it answers “the plan doesn’t specify this yet” instead of inventing one. Every section carries evidence-strength metadata (high, medium, low), so the model knows when it can be precise and when the plan is generic.

What I built

A FastAPI backend with the curated government plan injected into the system prompt, a web chat for citizens, and an analytics dashboard: each conversation gets its topic classified by the model on the fly, so a team can see what people ask about without reading every chat. Dashboard indicators used simulated data, clearly labeled.

Design decision

No vector database: about a dozen plan sections fit in context. The criterion for switching to retrieval was written down up front: more sources, WhatsApp at scale and long reference material. Web first, so the demo didn’t depend on WhatsApp Business approval for a political number.

Architecture

A citizen question goes to an LLM grounded in the plan corpus with evidence-strength tags and guardrails; each conversation is topic-classified, stored in SQLite and shown in a dashboard.Citizen questionweb chatPlan corpusevidence-strength tagsLLM + guardrailsplan-only answersTopic classifierper conversationSQLiteconversationsDashboardtopics · indicators
  • RAG / grounded assistants
  • guardrails
  • LLM classification
  • OpenAI / Claude APIs
  • Python
  • FastAPI
  • SQLite
Code available on request
06In daily personal use since Aug 2026

NutrinAI: a nutrition coach on Telegram that reads the day’s data, not a template.

Problem

My food log lived in notes on the computer, so days away from it went unrecorded. The first version only parsed and confirmed entries, so patterns surfaced in a weekly review, too late to act on.

What I built

A Telegram coach. Meals and weigh-ins written in plain language are parsed into JSON with macros and stored in Postgres. The reply comes from an LLM grounded in a distilled nutrition corpus and applied to that day’s numbers. Deterministic red-flag triage runs before the model.

Design decision

The same pattern as FIS.IO, reused on purpose: triage, then corpus in the prompt, then the LLM. What changes turn to turn is the state of the data (today’s macros, the weight trend), not a profile.

Architecture

A Telegram message passes red-flag triage, is parsed into JSON macros, stored in Postgres, and answered by an LLM coach using the corpus plus the day's totals.Telegrammeal or weigh-inTriagered flags · rulesParsertext → JSON macrosPostgresday + week totalsLLM coachcorpus + today’s data
  • guardrails & deterministic triage
  • structured outputs
  • RAG / grounded assistants
  • Python
  • FastAPI
  • Postgres
  • Telegram Bot API
  • webhooks
  • VPS (Easypanel)
Code available on request
07Internal tool

editor-io: the tool I use to turn my own long videos into publish-ready short clips.

Problem

Cutting long recordings into reels meant hours of scrubbing for the good moments, reframing for 9:16 and captioning by hand.

What I built

One command: Whisper runs locally on GPU with word-level timestamps, an LLM ranks hook moments and explains why, face-aware framing picks talking-head, split-screen or letterbox per clip, silences are cut, subtitles are burned in, and clips upload to YouTube from a manifest that checks the target channel first.

Design decision

Transcribe once, reuse everywhere: subtitles come from the same transcript, and intermediate JSON lets a human review the timestamps before anything renders.

Architecture

Video is transcribed locally with Whisper, highlights are ranked by Gemini, each clip is framed by face size, cut and captioned, then uploaded to YouTube.Whisperlocal GPU · word timingHighlightsGemini ranks hooksFramingface · split · letterboxCut + captionssilences removedYouTube uploadmanifest · channel check
  • Whisper (local GPU)
  • face detection
  • structured outputs
  • Gemini API
  • Python
  • FFmpeg
  • YouTube Data API
Code available on request
08Internal tool

My AI dev system: Claude Code with my own skills and MCP servers.

What it is

The environment I build everything else with. Claude Code, extended with skills I wrote for my own repeatable workflows, and connected to MCP servers that let the agent operate DaVinci Resolve (video) and Reaper (audio) directly.

Why it matters

Each repository carries versioned instructions, so every session starts with that codebase’s rules: brand, copy, deploy pitfalls, what not to touch. This site was built that way.

Architecture

I give intent and review; Claude Code reads per-repo instructions, runs my skills and calls MCP servers that control DaVinci Resolve and Reaper.Meintent + reviewClaude Codeper-repo instructionsMy skillsrepeatable workflowsMCP serverstool accessResolve · Reapervideo + audio
  • Claude Code + MCP
  • LLM agents with tool use

How I build

Three principles behind every system on this page.

  1. 01

    Safety before the LLM

    Anything that must never go wrong runs as deterministic code before the model is called: red-flag triage, message caps, explicit confirmations. The model handles language, not risk.

  2. 02

    Grounded answers only

    Assistants answer from a curated corpus or the business’s own data (menu, prices, schedule) and hand off what they don’t know instead of guessing.

  3. 03

    I scope it before I build it

    Every build starts with scope, success criteria and risks written down. PMP discipline applied to AI work: fewer surprises and honest timelines.

Open to roles

AI Implementation · Forward Deployed · AI Product.

I bring project-management discipline (PMP) to the messy part of AI: scoping with the business, building the system and staying until it works in production. Remote, from Lima (UTC−5).