05 / Current builds
Not everything here is finished
Most of my personal projects start because I run into a problem I want to solve. Some become finished tools. Some turn into experiments. Some teach me enough that I don't need to finish them.
Build.01ACTIVE
Multi-tenant SaaS platform
Four surfaces on one codebase.
A customer-facing storefront, an operator back-office, a field mobile app and a platform admin layer, all reading one data model. The hard part isn't the interface — it's tenancy: making sure one tenant's data cannot leak into another's under any query path, while three commerce systems each want to own the customer record.
Next.js · Supabase (RLS) · Medusa.js · Stripe Connect · Twilio · SendGrid · Vercel
Build.02ARCHIVED
Alpaca API stock analysis
Paused at phase ten, with the approval loop working end to end on paper trading.
A personal stock tracker on the Alpaca API: portfolio tracking, event alerts and AI-assisted research. Deliberately not autonomous — every order needed explicit human approval, routed through GitHub issues so it worked from a phone and left an audit trail. Real money sat behind safety rails and a fourteen-day clean paper run.
Python · Alpaca · Supabase · Anthropic · Finnhub
Build.03ACTIVE
Agent development team
Twelve specialists, one orchestrator, and constraints the agents cannot argue with.
A team of specialised coding agents — architecture, security, database, review, QA, docs — each with its own tool whitelist and model tier, and an orchestrator that is the only thing allowed to start them. The reviewers hold no write or edit tools, so the review step cannot quietly become an editing step. The rule I am proudest of is duller: acceptance tests are human-authored and committed before any agent writes the implementation, and a change that supplies both is rejected.
Claude Code subagents · Model tiering · Spec-driven · Human approval gates
Build.04ACTIVE
Installer onboarding pipeline
Five hundred applications a month is not a number you review by hand.
A national-retailer partnership means the network has to find, vet and approve far more independent installers than anyone can process by hand — the forecast is around five hundred applications a month. Two halves: the approval process that decides whether an applicant qualifies, and the onboarding wizard that carries the ones who do into the field-service platform. Intake, identity verification, background and motor-vehicle checks, insurance validation and e-signature each become an approval state rather than an email thread, with the downstream onboarding handed off over an API once somebody clears. The decisions that matter are not on the happy path: which vendor owns which check, who owns the data afterwards, and how much sensitive personal information the system should still be holding once a decision has been made. I am on the team building both halves.
Approval-state workflow · Identity & background verification · E-signature · API handoff
Build.05PROTOTYPE
Quorum
A watchlist is easy. Two people agreeing on one film is the actual problem.
Tracks what you have watched and suggests what to watch next, which is the easy half. The half worth building was group choice: each person accumulates their own profile, and a recommendation for two people is the overlap between their profiles rather than the average of them — averaging two tastes reliably produces a film neither person actually wants. Tracking and single-viewer recommendations ran; the multi-person intersection was the part still being built when it stopped.
Build.06PROTOTYPE
Pantry Planner
Recipes into a week, a week into one shopping list, without retyping anything.
The recipe form is not the interesting part. What happens between the plan and the list is: two recipes wanting onions on different nights should arrive as one line, a recipe scaled from four servings to six has to carry its quantities up with it, and units have to survive being added together at all. The whole loop ran end to end — plan a week, get a grouped list — it just never got past rough.