Systems · Analytics · Finance · Product · Operations

I build systems that make better decisions easier.

I’m a University of Washington Bothell Business Administration graduate working across product, operations, finance, data, and technical systems. My strongest work connects the layers: how information is captured, how assumptions become decisions, how products behave over time, and how the result is validated.

8-personcontracted intern workforce designed and managed
4–8h → ~40mquarterly reporting workflow improvement
12 × 10,000Monte Carlo scenarios × paths
34-tablenormalized PostgreSQL schema / ERD
Selected work

Projects where the reasoning matters as much as the output.

Each case study shows the problem, my role, the system or model I built, the tradeoffs I made, and how I validated the result.

Personal productKotlin MultiplatformLocal-first data

System: A Local-First Personal Analytics Platform

A private Android/Desktop application where I define product requirements, analytics behavior, local-first history/sync semantics, testing rules, and AI-assisted development workflows.

Read the full case study →
Professional operationsProcess redesign

From paper forms to a controlled reporting workflow

At United Indians, I digitized a recurring reporting process, added validation/correction controls, handled grant operations, and managed an eight-person intern program.

Read the experience case study →
How I work

Business context first. Technical depth when it matters.

I’m most useful when a problem crosses boundaries: operations + data, finance + modeling, product + testing, or customer research + execution.

01

Map the real workflow

Start with who does what, where information breaks, what decisions are delayed, and which constraints actually matter.

02

Evidence over position

I try not to become attached to “my side.” Bring the evidence, listen to the competing explanation, and update when better evidence wins.

03

Robust beats falsely precise

When information is incomplete, I prefer a solution that remains acceptable across plausible scenarios rather than one optimized for a fragile point forecast.

04

Trace the system

If something looks wrong, determine whether the cause is data, an assumption, documentation, implementation, or architecture before “fixing” it.

Writing

Ideas tested in the work.

Essays on model governance, product semantics, operations, valuation, strategy, and decision-making—grounded in the projects and experiences that produced them.

Automating orchestration without automating judgment

Why I built a GitHub-backed multi-worker AI relay, what it actually automates, and where I deliberately kept human review.

Read →

Digitizing a workflow is not the same as improving it

The difference between moving a paper form online and designing error controls, correction paths, and a usable reporting process.

Read →

Why dependence modeling became the hardest part of my Monte Carlo project

How empirical marginals, rank dependence, PSD repair, and validation changed the model from “random inputs” into a coherent joint system.

Read →