Selected engineering work / Case study

iOS application · TestFlight beta

Food Checker

From label photo to an accountable result, across the whole system.

An iOS app that reads the ingredients on a food label and flags the ones you choose to watch for. I built the whole path behind it: the camera workflow, OCR and configurable ingredient rules, a hardened FastAPI service, Supabase-backed account and data flows, automated AWS releases and private monitoring.

Join the TestFlight beta Privacy policy Support

Beta software; see the product boundary below.

Stack facts

Pre-release build

Mobile client
Expo / React Native
Analysis API
FastAPI + Tesseract OCR
Data and auth
Supabase / PostgreSQL
Delivery
GitHub Actions + ECR + SSM
Infrastructure
Terraform + Ansible

Informational only. Not medical, allergy or dietary advice.

What it is
An iOS ingredient-label scanner backed by a FastAPI OCR service on AWS. Pre-release, in TestFlight beta.
What I built
The whole path from photo to result: the API and OCR pipeline, AWS infrastructure, automated releases and monitoring, plus the mobile client.
Key engineering
Credential-light releases through GitHub Actions, OIDC and SSM, verified by a post-deploy health check and a real analysis request.
Evidence here
App screens, a June 2026 private-dashboard snapshot, CI and release checks, and the privacy, support and terms pages.

01 · Mobile workflowScan, review, correct the input.

The mobile client is the entry point, but not the whole system. It collects a label, presents structured results, and gives users control over the rules applied to each scan.

Food Checker iOS scan screen with ingredient label guidance and scan controls.
01Capture Scan or choose a label photo.
Food Checker iOS history screen showing structured scan results and risk states.
02Review Inspect structured warnings and scan history.
Food Checker iOS preferences screen showing selected ingredient rules.
03Configure Choose the ingredient rules applied to scans.

02 · Analysis pipelineA bounded path from image to result.

Each stage is explicit so failures can be validated, logged and explained instead of collapsing into a generic scan error.

  1. 01Label photoCamera or library input
  2. 02Validate + preprocessType, size, cleanup
  3. 03Tesseract OCRExtract ingredient text
  4. 04Normalize + apply rulesUser-selected concerns
  5. 05Structured resultRisk, summary, matches

03 · System boundariesPublic use, controlled delivery, private observation.

The architecture separates what the app needs publicly from what operators need privately, while keeping deployment access reviewable and short-lived.

Public

Application path

  1. 01Expo / React NativeiOS client
  2. 02Caddy HTTPSPublic reverse proxy
  3. 03FastAPILocalhost container
  4. 04SupabaseAuth and PostgreSQL
Deploy

Release path

  1. 01GitHub ActionsChecks + image build
  2. 02AWS OIDCShort-lived auth
  3. 03Amazon ECRVersioned image
  4. 04AWS SSMRun Command deploy
  5. 05EC2 ComposePull, restart, verify
Private

Observability path

  1. 01FastAPI metricsRequest and service signals
  2. 02PrometheusPrivate collection
  3. 03GrafanaPrivate tunnel access
Host and control plane

Terraform provisions AWS access and infrastructure. Ansible establishes the host baseline. Caddy and Docker Compose own the runtime boundary.

04 · API and release hardeningTrust behavior, not a green process light.

  1. Traceable requests

    X-Request-ID, method, path, status and duration make API failures easier to follow without exposing sensitive internals.

  2. Safer uploads

    MIME checks, size limits, temporary-file cleanup, OCR timeout handling and clear unreadable-label errors bound the scan path.

  3. Closed raw API access

    FastAPI binds to 127.0.0.1:8000. Public traffic reaches it through Caddy and HTTPS; the raw port is not exposed.

  4. Credential-light delivery

    GitHub Actions uses AWS OIDC and SSM rather than long-lived cloud keys or SSH as the default deploy path.

  5. Behavioral deploy check

    Releases verify both /health and a known POST /analyze request before the workflow treats deployment as successful.

  6. Capacity discovered through monitoring

    Disk pressure led to cleanup, shorter Prometheus retention, and expansion of the root volume from 8 GiB to 20 GiB.

05 · Operational evidencePrivate monitoring, public explanation.

Grafana itself remains off the public internet. This snapshot documents the signals used to understand service state, request behavior, target health and host capacity.

Private Food Checker Grafana dashboard showing API availability, target health, request activity, latency, CPU, memory and disk usage.
Private dashboard snapshot, June 2026. API status, Prometheus targets, request and analyze activity, latency, CPU, memory and root-disk usage. Monitoring ports remain private.

06 · Release confidenceChecks at each delivery boundary.

Backend CI
FastAPI import and pytest across analyzer, auth, OCR, upload and API smoke behavior.
Mobile CI
npm ci, Expo public config validation, TypeScript typecheck and lint.
Runtime image
Production dependencies stay separate from test tooling before the image is pushed to ECR.
Post-deploy
Health plus a synthetic ingredient-analysis request verify the deployed behavior.

Stable product linksApp Store and beta metadata.

These URLs remain stable for App Store Connect and TestFlight.

Technical index

Expo · React Native · iOS · TypeScript · FastAPI · Tesseract OCR · Pillow · Supabase · PostgreSQL · Docker · ECR · Terraform · Ansible · GitHub Actions OIDC · AWS SSM · EC2 · Caddy · Prometheus · Grafana

That is the selected work. Back to the beginning, or get in touch.

Contact Back to selected engineering work