I design, build, and run my own products: a game world that ran for nearly nine years, a booking platform with real bands on it, and tools that make hard things feel simple.
Ambitious ideas, simple systems · worlds, platforms, tools, and communities
I’m taking on new product design and full-stack work, so if you’ve got something ambitious, send it my way.
A border-wait planning product for northbound San Ysidro and Otay Mesa crossings. This case study covers the mobile app, and the service and operator tools behind it stay private.
Available on the App Store and Google Play.
Read case study brief · what i owned · key decisions · what shipped · evidence · implementation
The problem
A border wait isn’t one number. Travelers pick between crossings and lane types while the signal keeps changing, and the existing status checks make that comparison hard to read and harder to act on.
What I owned
I did the product engineering for the mobile workflows shown here: saved lanes, crossing and lane comparison, target alerts, crossing start, and commuter preferences.
Key decisions
Put every supported crossing and lane on one board, so travelers don’t have to check them one at a time.
Show a likely range, confidence, freshness, and trend next to the estimate, not a bare wait number on its own.
Turn watching the wait into something you can act on, with saved lanes, target alerts, crossing start, quiet hours, and optional GPS assistance.
What shipped
Planning guidance shown with a likely range, confidence, freshness, and trend.
Saved-lane status, six-way lane comparison, target alerts, crossing start, quiet hours, GPS assistance, and language preferences, all in one app.
Evidence
Product captures show the My Lane, lane-comparison Board, Alerts, and Settings workflows.
The Board compares General, Ready, and SENTRI lanes at both supported crossings and points out the fastest option right now.
Settings show primary-lane preferences, notification controls, quiet hours, GPS assistance, and a choice of English or Spanish.
Product architecture and full-stack engineering · 2026
A bilingual guide to U.S. green card pathways, backed by official sources, with pathway browsing, checklist flows, source tracking, admin review tools, and freshness checks.
Information only, not legal advice. Check any decision against the official sources.
Read case study brief · what i owned · key decisions · what shipped · evidence · result · implementation
The problem
Permanent-residency information is spread across pathway families, forms, evidence requirements, and official guidance that keeps changing. A useful guide has to make the next step clear without pretending to be legal advice.
What I owned
I did the product architecture, full-stack engineering, structured content system, public information design, and the workflow that keeps the content fresh.
Key decisions
Organize the product around exploring pathways and question-led process guides, not one eligibility quiz that tries to cover everyone.
Build source tracing, review, and freshness checks into the product itself, rather than treating the content as static marketing copy.
Say up front that it’s information, not advice, and send any decision that matters back to the official sources.
What shipped
Covers all 48 immigrant-visa pathways in English and Spanish, each with its own detail page.
Checklists for 17 supported combinations, printable results, a document library, an FAQ, a glossary, public feedback, and admin tools.
Built with Next.js App Router, React, TypeScript, OpenNext Cloudflare Workers, Cloudflare KV, Vitest, and Wrangler.
Evidence
The live bilingual site has pathway exploration, process guides, document-library routing, a glossary and FAQ, and printable checklists.
Captures show the home page, pathway explorer, document library, and process-guide entry pages.
Result
A large, structured immigration-information product, with checklist rules that always give the same answer and a trace back to official sources.
The deploy workflow runs launch validation, and a separate freshness worker runs on its own.
One booking platform running several live band brands.
Product architecture and full-stack engineering · 2026
A multi-tenant booking platform for tribute and cover bands: discovery, buyer intake, owner workflows, moderation, reviews, inquiries, content operations, analytics, imports, and billing readiness.
Deployments: MZTributeBands
The live tenants are the public reference, and the BandHub source stays private.
Read case study brief · what i owned · key decisions · what shipped · evidence · result · implementation
The problem
It started when a working band business needed its aging backend and public sites replaced. The catch was that each brand had to stay distinct, without redoing the catalog, funnel, and operations work for every storefront.
What I owned
I did the product architecture and full-stack engineering across the shared storefront, catalog, booking funnel, owner tools, administration, imports, and deployment operations.
Key decisions
Resolve each tenant by hostname into brand, content, and feature configuration stored in the database, so no brand needs its own fork of the app.
Keep an act’s identity separate from where it’s placed, and let shared catalog memberships handle the placement.
Roll out each tenant from a manifest: validate, apply, seed, verify.
Keep funnel, storefront, catalog, owner SaaS, and internal operations as explicit lanes, but ship them all as one deployable application on one database.
What shipped
One Next.js App Router codebase serves several public band-booking tenants, and site configuration plus hostname resolution decide which one you get.
It includes public directories and profiles, request flows that know about your shortlist, submit-act moderation, an owner dashboard, admin operations, an audit trail, and import tooling.
It runs on PostgreSQL and Drizzle ORM, with first-party magic-link auth, Resend email, Cloudflare Turnstile, local media storage and proxy, and optional Stripe billing.
Evidence
You can see it live: the MZ Tribute Bands production domain runs as its own BandHub storefront on the shared platform.
Captures from the MZ deployment show the homepage, search and filtering, branded collections, profiles, EPK downloads, and booking inquiries.
Imports and tenant rollouts are repeatable, and they bring over legacy catalogs, packages, posts, and reviews.
Result
One running application now serves several public booking brands, each with its own look.
Three focused HubSpot apps, and everything around them.
Studio/product platform · 2026
A public HubSpot product suite: DupliCat for repeatable record cloning, PressKit for Company-based press-kit publishing, and TabCalendar for year-view availability planning.
The site, app pages, documentation, pricing, trust pages, and direct installs are live. A HubSpot Marketplace listing is planned, and PressKit and TabCalendar run with controlled access.
Read case study brief · key decisions · what shipped · evidence · implementation
The problem
HubSpot teams still do several repeatable jobs with manual workarounds. Installing a third-party app to fix that takes trust, though: in its permissions, limits, support, pricing, and whether it will still be running years from now.
Key decisions
Keep the three workflow gaps as three products, each with its own install, scopes, pricing, and rollout path.
Publish the setup, permissions, limitations, changelogs, and trust material before asking a team to install anything.
Ship DupliCat as generally available, and run PressKit and TabCalendar in production with controlled access.
What shipped
DupliCat makes repeatable HubSpot record cloning consistent, with templates, defaults, associations, activity handling, and workflow actions.
PressKit keeps one Company-based electronic press kit current behind a stable public URL.
TabCalendar shows sold, held, and unavailable windows across a full year, pulled from Company and Deal records.
The suite publishes app-specific pages for setup, scopes, limitations, pricing, changelogs, support, security, privacy, DPA, subprocessors, status, and uptime.
Evidence
The public CleverCat catalog lists three production apps, each with its own install and documentation path.
Sanitized public captures show the DupliCat record card, the PressKit editor and public profile, and TabCalendar’s year and day views.
The public app matrix marks DupliCat as GA, and PressKit and TabCalendar as production with controlled access.
A local-first terminal app that turns the repositories on a machine into a deterministic pixel habitat, with rooms, journal entries, repo notes, recent commits, and optional GitHub discovery.
Source is public on GitHub, and the CLI installs from npm.
A live MMO, its community, and its tools, archived after it closed in 2023.
Engineering and operations · 2014–2023
A Renewal MMO that kept shipping game releases, with a whole product around it: accounts, an economy, competition, documentation, community, and support. The linked archive keeps its January 2023 public homepage.
It closed in July 2023 and no longer runs. The linked page is a rebuilt copy of the homepage you can look at but not use, with every login and service link turned off.
Read case study brief · what i owned · key decisions · what shipped · evidence · result · implementation
The problem
A game process on its own doesn’t keep a live community running. Players also needed releases, accounts, an economy, rankings, documentation, communication, and support they could count on, all around the world itself.
What I owned
NovaRO was my project from start to finish. I led it for nearly nine years, set its direction, and ran the engineering and operations for the live service and its web product, with a small team building alongside me.
Key decisions
Treat the service as a world plus everything that operates it (accounts, economy, rankings, documentation, communication, releases, and support), not as a server process alone.
Keep the final public homepage as an archive, with authentication and service routes switched off on purpose.
Show the January 2023 online count as a dated number from the homepage, and claim nothing past what the archive shows.
What shipped
A customized Renewal game service with custom content, utilities, and events, and public releases that kept coming.
A web product around the game, covering accounts, market and vending, rankings, WoE statistics, wiki, store, community, and support.
An archive with logins and outbound service links turned off on purpose.
Evidence
Opening and closing records put the service at October 2014 to July 2023, so nearly nine years of operation.
The preserved January 2023 homepage reported 3,425 players online, though the archive doesn’t record exactly what that counter counted.
The archive shows patch notes through #192, and updates kept shipping late in the service’s life.
Result
NovaRO ran for nearly nine years. It closed on July 4, 2023, under a settlement of a lawsuit brought by Gravity, the company that holds the rights to Ragnarok Online.
Searchable memory for a long-running tabletop campaign.
Product and tooling · 2026
Campaign memory for a long-running Pathfinder campaign. It reads in session logs and turns them into a force-directed relationship graph, a "catch-up" recap generator, a filterable timeline, a stats dashboard, an open-loop thread board, and full-text search.
A personal, non-commercial fan tool for a published Pathfinder adventure (an independent Paizo product). The public showcase shows only the tool’s own interface and data, and the adventure’s copyrighted art and maps stay off it. The in-app campaign Q&A stays behind a password.
Read case study brief · what i owned · key decisions · what shipped · evidence · result · implementation
The problem
After dozens of sessions, chronological notes stop being enough. Returning players need to find relationships, unresolved threads, recent context, and the source behind an answer, and none of that can expose the private capture material.
What I owned
I did the product design and tooling for the public campaign-memory interface. DungeonNotes stays behind it as the private capture side.
Key decisions
Model people, places, factions, sessions, and open threads as connected memory, not one long recap document.
Keep citations and searchable session context next to each generated recap, so the tool can show where an answer came from.
Keep the public interface and redacted data apart from private transcripts, table audio, player-only context, and licensed adventure art.
What shipped
A force-directed relationship graph of about 170 PCs, NPCs, factions, and locations.
Personalised "catch-up" recaps, a per-session timeline, and an open-loop board for unresolved threads.
A "campaign wrapped" stats dashboard with cited, searchable session memory.
Evidence
The live public site has the relationship graph, catch-up workflow, timeline, wrapped statistics, open-loop board, and search, and none of it needs access to the private capture material.
Interface captures show the graph, timeline, wrapped, and open-loop workflows.
Result
A campaign of 60-plus sessions is now something you can browse, and the capture and sensitive table context underneath it stay private.
Python
Campaign Memory
Search
Data Viz
live
Kingdom Come: Deliverance II mods
Worlds
Preview unavailableThe details below still apply.
Pull Hood Up - Down
Three Kingdom Come: Deliverance II mods, kept current with the game.
Side project · 2026
Pull Hood Up - Down, my take on plushie0039’s hood toggle, lets Henry raise and lower his hood with one key or a controller button, and a raised hood makes him a little less conspicuous. Realistic Armor Values is an update of Kaguya9’s plate armor overhaul, which had stopped working, so swords do less against armor again. Better Henry Beds raises the sleep and reading quality of the beds in Henry’s Forge by two tiers.
All three were updated for game version 1.5.6 on 2026-09-26: Pull Hood Up - Down 2.0.2, Realistic Armor Values 2.0.0, and Better Henry Beds 2.0.0. The current downloads are on Nexus Mods.
Kingdom Come: Deliverance II
Patched Table Files
Nexus Mods
teaser
SamsaraWebsite
Worlds
A private-first MMORPG interface and world-site teaser.
Interface design and engineering · 2026
A standalone React design-system playground for an MMORPG interface. It tries out compact windows, panels you can drag and resize, hotbars, chat, density and scale controls, fixture scenes, deep-link state, and accessibility checks.
React
Vite
Storybook
Zustand
Tailwind
1 project
Client work
live
MZTributeBands
Client work
Preview unavailableThe details below still apply.
Booking home
The first BandHub tenant, live for a working band group.
Tenant rollout and platform integration · 2026
The first BandHub tenant, for a California tribute-band and talent-booking agency. It has public discovery, act profiles, buyer-intent pages, request funnels, legacy URL handling, and structured SEO.
