Projects

The data governance team's quality scores were full of noise. Rules they already knew were not meaningful, test rules, rules that always warn or always fail. I built the workflow that lets them retire that noise deliberately, as governed records carrying a validity window and a stated reason, so suppressing a rule is an auditable decision rather than a silent deletion.

• ›Built a governed exception workflow for data quality rules, then reused the same pattern for a second domain
• ›Every exception is a governed record with a validity window, a stated reason, and full audit fields. Scores recalculate to exclude suppressed rules, and a toggle shows the unfiltered scores
• ›In use. Users have retired a double digit number of rules that were not actionable, and a partner team bulk loaded tens of thousands of known exceptions at launch

Pipeline and query work across the platform's warehouse layer, from the validation framework underneath a custom pipeline builder to the queries behind the dashboards and the alerting that tells teams when their data is late or wrong.

• ›Introduced Pydantic into a custom pipeline builder library, took it through design review with my tech lead, and replaced hundreds of lines of hand written validation with models that reject bad configuration before a pipeline runs
• ›Found that pipeline failure notifications had been silently missing every data source onboarded after a legacy lookup table went stale, so teams might not know their data was broken. Rebuilt the notification queries and checked that the fix added the missing sources without dropping any
• ›Rewrote 33 queries and 6 dependent views to cover every data domain on the platform, and built three reusable query templates, so onboarding a new domain means filling in a template instead of days of development
• ›Roughly halved execution time on the busiest queries, cut data scanned from about 50MB to 28MB, and removed disk spill

The identity service every app on the platform delegates sign in to, plus the hosted login and consent UI in front of it, so they all share one account. It gives the apps single sign on (SSO) and single logout. Signing in to one app starts a session at the login page, and while that session lasts the other apps sign me in without asking for my password again. Signing out of any app signs me out of every app. Each app still gets its own token, and the other apps refuse it. It implements the authorization code flow with PKCE, rotating refresh tokens, argon2id password hashing, account lockout, signing key rotation, and a login audit log. The UI is a backend for frontend that keeps the service key on the server, so browsers talk to the UI rather than to the identity service directly.

• ›Single sign on and single logout across the apps, and each app gets its own token that the others refuse
• ›Authorization code flow with PKCE, rotating refresh tokens, argon2id password hashing, and account lockout
• ›Apps check tokens locally against its published signing keys, with no call to the identity provider on each request

A boutique storefront I am building for my sister, where she will sell curated clothing, books, handmade crafts, art, and accessories. Customers will be able to browse and search the catalog, keep a cart saved to their account, and see their past orders. Checkout takes two steps, first reserving the items and then paying. An admin dashboard will let her manage products, variants, images, and orders. The server works out every price, total, and stock count itself rather than trusting the browser. The reservation runs in one database transaction that locks the items it holds, and a repeated request returns the original order instead of creating a second one. Payments will go through Stripe, which is set up on the server and switched off until the shop opens.

• ›The server works out every price, total, and stock count itself rather than trusting the browser
• ›Checkout reserves the items in one database transaction that locks them, then takes payment, and a repeated request returns the original order
• ›An admin dashboard for products, variants, images, and orders

A simple food and nutrition tracker for casual users and beginners. It covers logging meals, setting daily calorie and macro goals, and looking back at daily calorie totals for the past week or month. Its food database includes about a thousand foods from USDA data, and each food can hold up to 43 nutrition fields. New foods and meals are added through step by step forms. The daily log saves in the background, and the server recomputes daily totals from what was logged, ignoring any totals the browser sends. It was the first app built on the platform, and it is deployed and in use while I keep building it.

• ›A food database with about a thousand foods from USDA data, plus custom foods and meals added through step by step forms
• ›Daily totals are recomputed on the server, so totals sent by the browser are ignored
• ›Next on the roadmap are recipes, a nutrition label scanner, and progress charts

The shared Python library every app backend installs, so the code they have in common is written once instead of in each app. At its core it checks the identity provider's tokens against the provider's published signing keys, with no database lookup. It also includes a FastAPI application factory, auth dependencies, ownership checks, pagination, rate limiting, request ids and health checks, SQLModel database setup, blob storage, email, and log injection sanitization. Each backend pins a tagged release, so a new version reaches them one at a time rather than all at once.

• ›Checks tokens against the identity provider's published signing keys, with no database lookup per request
• ›A FastAPI foundation with auth, pagination, rate limiting, database setup, storage, and email, so each backend does not write its own

A Python formatter and linter built only on the standard library, mainly its ast and tokenize modules, with no runtime dependencies. It formats and checks the platform's Python code to one house style, including sectioned module preambles, aligned assignment runs, Google style docstrings, and wrapping at 120 columns. Each rule either fixes the code, reports an error, or reports a warning, and a project can turn a rule off or change its tier in TOML. It is the style check in CI for the platform's Python repositories, where existing findings are kept in a baseline and only new ones fail the check.

• ›Stdlib only at runtime, no third party dependencies to audit or pin
• ›A written spec defines the style, and golden test fixtures pin the output

A searchable game catalog planned as a future app on the platform, for browsing and filtering titles by genre, platform, and rating. Like the other apps, it will sign in through the identity provider and run its own backend on the shared SDK.