← ALL WORK

Client work · Health-tech architecture

ROOTS-AI

A client engaged me as the engineer for an AI-powered health assessment platform: users complete a structured assessment, an AI generates a personalized health report, and the system delivers it as a polished document. My job was to turn that vision into a build-ready technical program — and defend every decision in it.

  • Next.js
  • Vercel
  • Supabase
  • OpenAI
  • Puppeteer
Role
Engineering lead — architecture & planning
Client
ROOTS-AI™ (health-tech)
Delivered
Implementation plan v1.0 → v1.2
Review
13-item correction matrix, all closed

The problem

A vision that needed an engineering spine.

The client had a clear product idea and a hard question underneath it: how do you actually run AI-generated health reports in production — safely, repeatably, and on a budget a startup can carry? "Use AI" is not an architecture. The engagement was to produce one.

Assessment

AI report

PDF

The core flow: structured assessment → AI analysis → generated report, rendered to PDF server-side.

What I delivered

A blueprint the client could build from.

  • Full stack architecture: Next.js on Vercel for the product surface, Supabase for auth and data, OpenAI for report generation, and Puppeteer for server-side PDF rendering of the final report.
  • A client-facing implementation plan taken through three versions (v1.0 → v1.2) as scope and constraints sharpened.
  • A 13-item correction-response matrix (CR-01 through CR-13): every technical concern the client raised, tracked as its own numbered item with a written resolution — all thirteen closed.
  • Final delivery as a single combined document the client could hand to any engineer and start building from.

Hard parts

Engineering is also a communication problem.

Engineering highlight

The correction matrix

The most valuable artifact wasn't the architecture diagram — it was the CR matrix. Turning thirteen scattered client concerns ("what about X?", "is Y safe?") into numbered, tracked items with explicit resolutions converted an anxious review cycle into a checklist that reached zero. It's the same discipline as closing bugs, applied to trust.

Engineering highlight

PDF as a first-class output

Health reports get printed, emailed, and forwarded — so the PDF can't be an afterthought screenshot. Specifying Puppeteer rendering server-side means the report is real HTML/CSS with real typography, generated in an environment the product controls, identical for every user.

Outcome

Honest scope, cleanly delivered.

This engagement was architecture and implementation planning — not a shipped consumer product — and the deliverable reflects that: a build-ready technical program, versioned, reviewed, and accepted by the client with every raised concern resolved. It's the part of engineering that happens before the first commit, done properly.

Next case study

PULSE