Case Studies

Delivery stories with architecture, constraints, and engineering decisions left visible

This page turns selected projects into readable technical narratives: what the problem was, what I built, how the system was shaped, and why the result mattered. The goal is a cleaner bridge between portfolio signal and technical judgment.

3 detailed stories
AI + backend + research
problem → architecture → outcome
How to read this page

Each story should move from context to system design to engineering consequence

These writeups are not meant to be long for the sake of being long. They should help a recruiter, founder, or engineer see the constraints, the design choices, and the quality of judgment behind the implementation.

AI product

ReX — turning model capability into usable career guidance

Overview

ReX was a user-facing AI assistant for career guidance. The challenge was not just generating responses, but producing outputs that felt specific, practical, and trustworthy enough to guide real user action.

The problem

Career guidance systems fail when the interaction becomes generic, inconsistent, or opaque. The product needed structure, personal context, and a response pattern that led users toward concrete next steps instead of vague advice.

What I built

I designed conversation flows, structured prompting, personalization logic, action-oriented outputs, feedback loops, and privacy-aware guardrails. I also added validation and anti-fraud layers so the system behaved more like a product surface than an isolated chat demo.

Key decisions

Separate intent capture from response drafting. Treat relevance and trust as product requirements. Keep the assistant oriented around actionable next steps. Make the quality loop visible enough that behavior can improve over time instead of drifting silently.

Outcome

The result was an AI experience shaped like a product, not a demo: stronger relevance, clearer responses, better consistency, and more trust in real-time interaction.

Production backend

Subscription & payout system — designing billing flows that stay correct under failure

Overview

This work focused on a SaaS billing and payout flow where money movement, entitlements, and user access all had to stay aligned even when events arrived out of order or failure paths appeared.

The problem

Billing systems become brittle when webhook events, retries, entitlements, and business rules drift apart. A clean happy path is not enough. The architecture has to be built around partial failure, repeat delivery, recovery, and traceability.

What I built

I designed backend workflows for subscriptions and payouts using Stripe, Node.js, and Firebase. The system handled webhook events, retries, reconciliation logic, state transitions, and idempotent processing while keeping payment state connected to product entitlements and user access.

Key decisions

Model the state transitions explicitly. Treat idempotency as a first-class concern. Add recovery and audit paths instead of assuming perfect event delivery. Keep the logic observable enough that engineers can reason about failures quickly.

Outcome

The result was a backend flow optimized for correctness, maintainability, and operational clarity rather than brittle automation built only around the happy path.

Research software

Research tooling & data workflows — translating study protocols into reproducible systems

Overview

This work turned research requirements into software workflows for sensitive biometric data. The challenge was to move from study protocol language to something repeatable, auditable, and useful in day-to-day research operations.

The problem

Research protocols often begin as instructions for people, not as systems. That creates friction around intake, cleaning, labeling, versioning, reporting, and privacy handling unless the workflow is deliberately structured.

What I built

I built tooling for biometric data collection, validation, dashboards, versioning, reproducible analysis, documentation, and technical reporting. The emphasis was on turning manual, research-heavy processes into a more legible operational system.

Key decisions

Translate protocol requirements into clear software steps. Keep the data flow reproducible and documented. Treat privacy-aware handling as a workflow concern, not a late-stage patch. Build reporting and dashboarding into the system so the work stays inspectable.

Outcome

The result was less manual handling, stronger reproducibility, clearer reporting, and a more auditable workflow for sensitive research data.

Queued writeups

Additional stories that round out the engineering profile

These projects already matter to the hiring story even before they are expanded into full-length narratives.

Robustness Testing: Adversarial Attacks on LLMs

A compact case study on perturbation-based evaluation, failure patterns, and how reliability questions show up before deployment.

Malicious URL Detection

An applied ML story about phishing classification, feature engineering, evaluation tradeoffs, and service-oriented design.

Related artifacts

Notes that support the strongest stories

These briefs and research notes are the fastest way to inspect the thinking behind the projects without leaving the portfolio context.

Technical brief

Reliability Patterns for GPT-5 Product Assistants

A portfolio note on structured prompting, feedback loops, trust boundaries, and why user-facing AI assistants need product discipline as much as model capability.

Open in library
Technical brief

Designing Billing State Machines for Subscription Platforms

A technical brief on subscription states, webhook handling, retries, entitlements, and why financial flows demand idempotent backend design.

Open in library
Research note

Adversarial Robustness Evaluation for Practical LLM Systems

A compact note connecting perturbation-based evaluation to real deployment questions around reliability, brittleness, and failure analysis.

Open in library
Best next step

Use the copilot to compare the stories by role fit or technical depth

The fastest way to evaluate the portfolio is to compare the case studies through a specific lens: AI systems, backend reliability, research engineering, or product execution.