What I build

Purpose-built AI that handles a specific job, with a defined failure mode.

Most AI projects fail on evaluation, not on the model. I build agents the way you would build anything else that has to be trusted: a stated requirement, a measure, a golden set, logged failure modes, and an escalation path for the cases it should not handle alone.

• Anthropic and OpenAI API integration; agentic workflows with tool use
• Retrieval-grounded assistants over your own documents, with inline citations
• Evaluation harnesses - golden references, regression suites, graded outputs
• Brand-voice and policy constraints enforced, not suggested
• Escalation and fallback logic so the agent hands off instead of guessing

Pipelines built so a wrong answer is caught before it ships, not after.

I built and operate a private in-house ML platform end to end, which is where this discipline comes from: strictly time-ordered splits, a sealed test set, and a verification harness that refuses to promote a model whose live accuracy does not reproduce its test accuracy. Most ML work fails on evaluation long before it fails on modelling.

• Gradient-boosted ensembles - XGBoost, LightGBM, HistGradientBoosting
• Time-ordered train/validation/sealed-test splits; purged cross-validation
• Data-leakage detection and feature engineering with honest attribution
• Verification before serving; versioned artifacts with one-step rollback
• Live ingestion over WebSocket with in-memory cache and REST fallback

Including the legacy platforms everyone else says cannot be automated.

The expensive manual work is usually trapped in a system with no API. I automate those: frame-aware browser control over the Chrome DevTools Protocol, postback-safe waits on legacy ASP.NET platforms, error recovery, and a CSV audit trail so compliance can see exactly what ran.

• Browser automation via Playwright over the Chrome DevTools Protocol
• Legacy enterprise web apps - iframe-aware scraping, postback handling, recovery
• Desktop automation, clipboard tooling and global hotkeys (tkinter, pynput)
• Zapier and Make pipelines where a hosted tool is genuinely the right answer
• Audit logging, retry logic and straight-through processing with a paper trail

Client portals, dashboards and SaaS products, shipped to production.

Role-based web apps with real-time data, built on a stack I have taken all the way to paying-customer-ready more than once: Next.js on Vercel, Postgres with row-level security, Stripe billing, and a mobile client where it earns its keep.

• Role-based access control and multi-role dashboards
• Real-time updates over Postgres subscriptions
• Stripe billing, subscriptions and webhook handling with signature verification
• Admin tooling, audit logging and user management
• PWA and React Native mobile clients

Connecting the tools you already pay for, reliably.

Integration work is where most automation quietly breaks - a webhook with no signature check, a retry loop with no backoff, a rate limit nobody budgeted for. I build the unglamorous parts: idempotency, verification, backoff, structured logs.

• Stripe payments, subscriptions and webhook pipelines
• Twilio SMS/MMS, Resend transactional email, OneSignal push
• OAuth integrations and token lifecycle handling
• Webhook handlers with signature verification and replay safety
• Rate limiting, retry with backoff, and structured error reporting

Automation you do not have to babysit.

An automation that fails silently is worse than no automation, because you trust it. Everything I hand over is built to notice its own failures: atomic writes, heartbeats, watchdogs with restart-storm guards, and versioned artifacts you can roll back in one step.

• Atomic state writes - serialize, temp file, fsync, re-parse, replace
• Watchdogs detecting process death, heartbeat stalls and stale output
• Restart-storm guards and single-instance locks
• Health checks, structured logging and scheduled-job supervision
• Versioned artifacts with documented one-step rollback

A domain I already have the context for, so the requirement does not need translating.

Most of the production tooling on this site was built for a clinical utilization-management workflow, which means the regulated-environment constraints are familiar: PHI handling, audit trails, de-identified design, and tooling that supports a reviewer’s decision rather than making one. I hold a PharmD and work in that workflow, which is how the domain access happened — the engineering is the service being offered.

• Decision-support tooling that attaches to a live case-review workflow
• Criteria, step-therapy and question-set logic rendered as something a reviewer can read
• Retrieval-grounded clinical assistants that answer with citations, not recall
• Evaluation rubrics for probabilistic systems in regulated settings
• De-identified by design; audit trails where compliance needs them