How to read this page
These are case notes, not thumbnails.
Each project opens into a short note on the problem, what was built, and what changed. The page is meant to stay easy to scan before it asks for more attention.
Featured work
The fastest way to understand how I work.
Start here for the clearest read on the problems I take on and the kind of systems I tend to leave behind.
Professional work · GTM data · Attribution · Warehouse
Customer 360 and Revenue Attribution
Pulled customer, product, billing, and support records into one account view for the GTM team.
This is a good example of the work I do most often: take scattered records and turn them into something people can actually use.
Open project note
Different teams were working from different customer records, so even simple reporting questions kept turning into reconciliation work.
What changed
- Stitched CRM, GA4, product, billing, and support records into one account-level model.
- Defined shared identity, touchpoint, conversion, and revenue logic so teams were not reconciling the same customer in different ways.
- Added dashboards, lineage, and ownership rules so the model stayed useful after handoff.
Why it helped
The value was not a prettier report. The value was giving GTM teams one version of the customer so planning and budget decisions stopped breaking on record mismatch.
Snowflake · dbt · SQL · Salesforce · GA4
Professional work · dbt · Airflow · Reliability
ELT Reliability and Monitoring
Built a steadier data foundation with tests, monitoring, and clearer pipeline ownership.
It shows the production side of the work: make sure the system still works after the first launch.
Open project note
The pipeline worked just enough to be relied on, but not enough to be trusted.
What changed
- Built a layered ELT flow with staging models, curated marts, and reusable onboarding patterns for new sources.
- Added dbt tests, freshness checks, lineage docs, and monitoring so reliability could be checked directly instead of guessed at.
- Used CI workflows and data contracts to catch bad changes before they reached dashboards or leadership reporting.
Why it helped
Once the pipeline had tests, runbooks, and visible ownership, analysts could stop treating every table like a special case.
Python · SQL · dbt · Airflow · GitHub Actions
Professional work · Experimentation · Funnel analysis · Product analytics
Onboarding Funnel and Experiment Readouts
Built cleaner event tracking and experiment readouts so product teams could see where onboarding was breaking.
It shows product analytics being used as a decision tool, not just a reporting layer.
Open project note
Changes were shipping faster than the team could agree on what was working.
What changed
- Standardized event taxonomy, exposure logging, and reusable funnel models across onboarding and checkout flows.
- Built experiment readout templates with guardrail metrics so results were easier to compare from one launch to the next.
- Added cohort and decision-tracking views that connected analysis back to the change a team actually made.
Why it helped
The project mattered because it turned experiments into a repeatable workflow. Teams could see the change, read the result, and make the next call faster.
Snowflake · SQL · Python · Experimentation · Dashboarding
Independent project · Fairness · Transportation · ML
FlightPriceBias
Used airfare data to study prediction quality and fairness risk at the same time.
It combines model work with a question I care about: how a system can look useful while still producing uneven outcomes.
Open project note
The question was simple: can a fare model look strong while still hiding fairness problems?
What changed
- Built repeatable preprocessing over DOT DB1B-style fare tables, including joins, route aggregation, and fare-per-mile features.
- Benchmarked baseline classifiers alongside fairness-aware mitigation approaches using scikit-learn and AIF360.
- Compared predictive performance with fairness metrics so the trade-offs stayed visible.
Why it helped
The point was not to claim the model was fixed forever. It was to make the trade-offs clear enough for someone to make a better decision.
Python · scikit-learn · AIF360 · pandas · Fairness metrics
Research · Urban planning · GIS · Transportation
Transit Hub Access Study
Used maps and planning analysis to compare access, safety, and network fit around transit hubs.
It shows the public-systems side of my work in a form that is still easy to read.
Open project note
The project needed to explain transit trade-offs, not just show a map.
What changed
- Analyzed hub access and surrounding conditions with a GIS workflow designed to compare several planning factors at once.
- Used layered maps, planning criteria, and short narrative framing to show why a hub can look strong on one measure and weak on another.
- Turned a planning question into a case study that someone outside a GIS classroom could still follow.
Why it helped
This is one of the clearest public examples of the broader context that keeps showing up in my work, even when the tools change.
ArcGIS · GeoPandas · Spatial analysis · Planning research
More builds
More systems and smaller builds that show the same preference for useful outputs and clear handoffs.
Professional work · KPI governance · Semantic layer · BI
Shared KPI Layer for Product and Ops
Built a KPI layer that gave product, ops, and finance teams one shared reporting language.
It shows that good reporting starts before the chart, at the definition and ownership layer.
Open project note
Leadership meetings kept stalling because each team had its own version of the same KPI.
What changed
- Unified event, warehouse, and reporting logic behind a governed metric layer instead of dashboard-specific calculations.
- Added QA checks, ownership metadata, and freshness monitoring so executive metrics behaved like maintained products.
- Supported drill-down workflows for operators and leaders instead of a single static dashboard.
Why it helped
The dashboard only became useful once the definitions settled down. After that, the meeting could move from reconciliation to decision.
SQL · dbt · Power BI · Azure SQL · QA monitoring
Professional work · BizOps · Executive reporting · Prioritization
BizOps Control Tower
Built a leadership view that pulled blockers, priorities, and weekly operating signals into one place.
It shows analytics helping leaders decide what to do next, not just summarize what already happened.
Open project note
Important updates were spread across decks, sheets, and team dashboards, so blockers stayed hidden too long.
What changed
- Combined initiative tracking, KPI monitoring, and bottleneck views into one reporting surface.
- Built drill-down views and weekly review packs so leadership could move from status collection to prioritization.
- Made trade-offs explicit by tying project health back to shared business measures instead of isolated team updates.
Why it helped
The key shift was simple: the review stopped being a recap and started acting like a working control room.
SQL · Power BI · Excel · Operational reporting · KPI design
Professional work · Retention · ML · Intervention design
Churn and Retention Early Warning
Turned product, billing, and support signals into a workflow that helped teams spot retention risk earlier.
It shows model work being used inside a real operating loop instead of ending at a score.
Open project note
A churn score by itself was not useful enough. The team still needed a clear order of action and a way to know when the model had gone stale.
What changed
- Combined behavioral, billing, and support features into a ranked risk model for at-risk accounts.
- Focused evaluation on actionability with calibration checks and intervention-aware thresholds.
- Added CRM integration, drift checks, and outcome feedback so the model stayed useful after launch.
Why it helped
The model only became valuable once it helped a team decide who to contact first and when the scoring needed another look.
Python · SQL · scikit-learn · Snowflake · Monitoring
Professional work · Compliance · SLA monitoring · Operational analytics
Compliance Review Operations
Turned compliance intake, backlog, and review status into a workflow leaders could actually manage.
It shows operations work in a high-stakes setting where the queue itself has to be easy to inspect.
Open project note
The review queue was hard to read, which made delays and audit follow-up harder than they needed to be.
What changed
- Centralized intake, inventory, review status, and evidence tracking into one operating view.
- Added structured status language, aging logic, and escalation alerts so SLA risk became visible earlier.
- Organized artifacts into a searchable repository that made audits and follow-up easier.
Why it helped
The project worked because it made the queue easy to read. Once the workflow had clear status language and a shared structure, leadership could manage risk with less guesswork.
SQL · Power BI · Workflow tooling · Documentation · Reporting
Professional work · Pricing · Simulation · Revenue analytics
Pricing Scenario Workbench
Built a pricing workbench that let teams compare trade-offs before making a pricing move.
It treats pricing as a decision process, not a single answer from a model.
Open project note
The team needed a better way to compare pricing paths without arguing from instinct alone.
What changed
- Modeled historical price-demand behavior with business-rule constraints such as margin floors and segment-level trade-offs.
- Built a scenario engine and dashboard that let operators compare candidate prices instead of accepting one opaque answer.
- Tracked realized versus predicted lift so the model could earn trust over time.
Why it helped
The useful part was transparency. People could see the assumptions, compare paths, and check whether the recommendation held up after rollout.
Python · SQL · Optimization logic · Power BI · Scenario modeling
Independent build · Analytics · Data product · Education
craveforcapes
Turned UC San Diego CAPE data into a live course-selection tool.
It is a smaller project, but it shows the same habit of turning raw data into something directly useful.
Open project note
Course evaluation data is only useful if people can compare it quickly enough to make a decision.
What changed
- Pulled and structured CAPE data into a usable exploration surface.
- Focused the interface on direct comparison and decision support instead of a raw table dump.
- Kept the project lightweight enough to feel more like a tool than an analysis artifact.
Why it helped
It is a small project, but it makes the same point as the bigger ones: information becomes more valuable when someone can act on it quickly.
JavaScript · Data wrangling · UI implementation
Independent build · GTFS · Transit · Tooling
GTFS Explorer
Built a GTFS tool that makes route and stop analysis easier to search and explore.
It connects transit systems work with a tool that feels closer to something an operator could actually use.
Open project note
The goal was to build something closer to an operator tool than a notebook: responsive enough for schedule exploration, but still capable of search-based planning.
What changed
- Normalized GTFS tables for stops, routes, trips, stop times, and calendars so the data could support interactive use.
- Added cached indexing and fast timetable lookup patterns to keep the interface usable on larger feeds.
- Implemented coverage-guided adaptive beam search so multi-stop planning stayed feasible under real compute limits.
Why it helped
This sits in a part of the work I enjoy a lot: technical logic that still has to become a usable tool for another person.
Python · Streamlit · NumPy · pandas · Search heuristics
Utility · Automation · iOS · Personal tooling
Morning and Night Automation
Built a lightweight iOS shortcut workflow that turns a repetitive personal task into a simple automation.
It is a small example of the same instinct toward removing manual overhead with a direct solution.
Open project note
The problem was deliberately ordinary: if a task repeats often enough, it deserves a workflow instead of another reminder.
What changed
- Built a small automation that removed a recurring manual step.
- Kept the flow simple enough that using it never became its own maintenance burden.
Why it helped
It is a tiny project, but it follows the same instinct as the bigger work: remove friction and leave behind a simpler process.
Transportation and planning
Work that shows the wider context behind the rest of the portfolio.
Research · Economics · Planning · Policy
UC San Diego Debt and Planning Analysis
Looked at long-term debt and campus planning trade-offs at UC San Diego through a business and policy lens.
It adds institutional analysis and economic reasoning to the broader systems perspective running through the rest of the portfolio.
Open project note
The project asked whether capital decisions and parking strategy were being framed too narrowly in a campus planning context.
What changed
- Combined institutional finance, planning constraints, and narrative analysis.
- Used the project to reason about incentives instead of isolated infrastructure choices.
Why it helped
It is a quieter project, but it helps explain why incentives and public-system design keep showing up in how I frame technical work.
Research · Sustainability · Transportation · Writing
Greenhouse Gas Reduction Essay
Wrote a transportation planning essay on how mode access and community design affect emissions outcomes.
It shows how transportation and policy questions continue to shape the way I think about system-level outcomes.
Open project note
The essay tried to connect emissions outcomes back to planning choices instead of treating them as a purely technical problem.
What changed
- Framed emissions through access, mode choice, and urban form.
- Used policy writing to make systems trade-offs clear without a technical stack.
Why it helped
It belongs here because the portfolio would feel incomplete without the public-systems questions that keep shaping my technical taste.
Archive and shelved work
Older work that still says something useful about judgment, constraints, or where a project stopped.
Archive · Archive · Reflection · Process
Archived and Shelved Work
An archive of projects that stalled, what they aimed to do, and what they still taught me.
I keep this here because abandoned work can still say something useful about judgment, constraints, and how a project was evaluated.
Open project note
Some work is useful mainly because it clarifies what was not worth continuing.
What changed
- Captured project intent, stopping conditions, and the lesson that still carried forward.
Why it helped
The archive stays because good judgment includes knowing when to stop and being honest about why.