Two decades of infrastructure. A new decade of building.

The problem

California publishes state-agency procurement data, but it lives scattered across separate spreadsheets — one per vendor, with inconsistent schemas, mixed statuses, and no way to see the same department's buying pattern across competitors. For a seller working that territory, the data was technically public and practically unusable.

What I built

A single-page dashboard that ingests four competitor spreadsheets, normalizes them into a unified JSON dataset, and renders a live filterable view of the combined market. Keyword search across items, suppliers, buyers, departments, and POs. Faceted filters for source, status, department, and supplier. Live summary metrics for spend, deal size, and active/closed mix. Rollup panels for top suppliers, top departments, and source distribution.

The interesting part

The dashboard was the easy half. The harder problem was turning data into action — so I layered an intelligence engine on top: a curated lifecycle dataset of product SKUs with end-of-support dates, confidence tiers, and source URLs. Past-EOS hardware now surfaces automatically as the top prospecting angle, with specific model names, PO counts, and dates — and the tool exports a ready-to-use briefing document in Markdown or styled HTML that feeds directly into Claude for draft emails, partner briefs, and account strategy.

The AI-native piece

This is where the tool stops being a dashboard and starts being a genuine force multiplier. The brief export is designed as a prompt payload — structured so I can paste it into Claude with one line of intent ("draft a prospecting email to this buyer") and get a useful first draft in seconds. The whole workflow — data → filter → brief → email — collapses from hours to minutes.

The problem

Existing fitness apps don't track the specific style of high-intensity training I follow — minimal sets, maximal effort, careful tracking of progressive overload across a four-day split. I also didn't want another account, another subscription, another app store dependency. I wanted something I could open on my phone in the gym and trust to remember everything.

What I built

A mobile-first Progressive Web App that runs entirely in the browser — no backend, no app store, no account. It installs to the Android home screen from a GitHub Pages URL and behaves like a native app. The full product includes a four-day split tracker pre-loaded with specific exercises, a rest timer, a workout history log, and an AI-powered insights engine — all in a single self-contained HTML file with zero dependencies and zero build step.

The interesting technical challenges

Mobile storage reliability. The first version, opened from a file manager, caused Android Chrome to treat each session as a new origin — wiping localStorage every time. The fix was hosting at a stable URL. A seemingly trivial problem that required understanding how mobile browsers actually scope storage.

Autosave and crash recovery. I kept losing workouts by forgetting to tap "Finish." The fix was a dual-key storage architecture: completed sessions write to one key, while an in-progress session continuously autosaves to a second key on every input event. On page load, the app checks for orphaned autosaves, de-dupes against completed sessions, and offers a one-tap recovery prompt if unfinished work is found.

Last-session pre-population. Rather than starting blank, every workout pre-fills with the most recent session's exact weights, reps, and notes for the same split — with the prior notes flagged in orange so they're impossible to miss (visible in the Workout screenshot above). Required a clean history data model keyed by split and exercise name.

The AI-native piece

The Insights engine runs entirely client-side with no API calls — detecting personal records, flagging stalls, calculating volume trends, surfacing contextual coaching tips. A separate "Analyze with Claude" button formats the full workout history into a structured prompt, copies it to the clipboard, and opens Claude.ai — giving deep on-demand analysis without requiring an API key in the app itself. Cheap, simple, and surprisingly powerful.

The problem

Planning a 9-day family road trip across California, Arizona, and Utah meant juggling itinerary, reservations, drive times, kids' attention spans, photo coordination across five phones, and a partner who reasonably wanted to know where the Sprinter van was at any given moment. Existing tools handled parts of that — but nothing handled the whole job for a specific family on a specific trip with specific quirks.

What I built

A custom single-page web application — roadtrip.jayleone.ai — designed to plan, navigate, and capture the trip as it happened. Five tabs: Schedule (day-by-day itinerary with drive times, stops, reservations), Live Map (real-time GPS tracking of the van pushed from my phone), Overview (trip stats and big-picture context), Checklist (packing and pre-departure tasks), and Photos (on-the-road uploads from everyone's phones, pinned to locations). Designed to work seamlessly from the passenger seat of a moving vehicle on spotty rural cell signal.

The interesting technical challenges

Live GPS tracking in a browser. Browsers aggressively sleep the Geolocation API when a tab backgrounds or signal drops. After evaluating heavier self-hosted solutions, I built a purpose-made gps.html page that stays foregrounded, polls location on an interval, and writes coordinates directly to Supabase. The Live Map tab renders the result with a moving van icon — so my wife and kids could watch the van's progress in real time from the back seat.

Photo uploads under real conditions. Uploading from a moving vehicle on bad 3G is its own discipline. I used direct-to-Supabase Storage uploads with client-side compression and graceful retry behavior. Added per-photo delete controls using event delegation on data attributes — critical after one family member uploaded forty near-duplicates of the same canyon.

The auto-refresh bug that wiped uploads in progress. Early Photos tab refreshed every 30 seconds to pull new images. Unfortunately, that also wiped the in-progress file picker state mid-upload. Disabled auto-refresh on that tab specifically and added a manual button. Small bug, large UX impact.

Offline-ish operation. Much of the route had no signal — Grand Canyon rim, Zion back roads, long stretches of Utah. The app degrades gracefully: cached itinerary, checklist works without backend, photos queue locally until reconnection.

Schedule reflow when delayed. If we left a stop late, the app recalculated the day — surfacing how much time we'd lost, which downstream stops were at risk, and what we might want to drop or shorten (the "Running late? Tap to recalculate" control is visible in the Schedule screenshot above).

The AI-native piece

The whole app — frontend, backend integration, real-time sync, geolocation handling, deployment scripts — was built through natural-language conversation with Claude. What's noteworthy isn't that AI wrote the code. It's that the architecture decisions (Supabase over self-hosting, dedicated GPS page over service workers, no auth over a login system) all came from real tradeoffs I could reason about and Claude could implement. The build felt less like coding and more like leading a very fast, very competent contractor.

The problem

Three kids and twenty years of accumulated stuff — clothes worn once, toys loved to death, school projects nobody could quite throw away. My wife didn't want to let go of any of it. Not because of the things, but because of what the things represented: first steps, first day of school, the random Tuesday that turned out to be a moment worth keeping. Storage has limits. The purge was coming. The question was how to make it feel okay.

A photo of a onesie is just a photo of a onesie. Without the story attached, it's inventory. So the goal became: for every item we let go, capture not just the object — but the memory. The item, paired with a real photo of the kid actually using it. A few sentences about why it mattered. A quote if we had one. A timestamp. A name. That's what this app does.

What I built

A static archive site — clean HTML, CSS, and vanilla JavaScript with no framework, no build step, no server. Memory data lives in a single structured memories.js file, separated from the presentation layer so the site stays maintainable by anyone, not just a developer. Hosted on GitHub Pages so it's free, versioned, and accessible to the whole family from any device. Adding a memory is one object appended to an array — and one git commit.

The interesting part — and why this one is different

The site is the easy half. The hard half — and the part that makes this project a different category from the others on this page — is that the photos of the kids actually using the items live in Google Photos, which has no public API for programmatic search and download. The only way in is through the browser, as a logged-in user.

That's exactly how this works. Claude takes direct control of the local Chrome browser, navigates to Google Photos, and runs intelligent searches — not just keyword lookups, but contextual queries calibrated to the item, the child, and the approximate time period. It evaluates the visual results the same way a human would, and selects the photo that actually matches the memory.

When the right moment is buried inside a video clip — which happens constantly, because parents capture a lot of video — Claude injects JavaScript directly into the page to locate the authenticated image frame Google Photos is already rendering, fetches it with full session credentials, and triggers a download as a JPEG. No API key. No OAuth flow. No third-party integration. Just the live, logged-in browser session doing what a human would do — at a speed and consistency a human couldn't sustain across hundreds of items.

The AI-native piece

This is the project where the boundary between "AI as coding tool" and "AI as operator" disappears. The other apps in this portfolio were built with Claude writing code I asked for. This one is built with Claude doing the work — operating a real browser, evaluating real search results, making judgment calls about which photo matches which memory, downloading the right frame from a video, writing the description, and updating the data file. The whole pipeline runs on natural-language instruction, not custom integration code.

And that scale is the actual reason this needed to exist. Manually searching Google Photos for every donated item is feasible for ten things. It is not feasible for hundreds. You'd give up, and the memories would go with the items. Automation is what makes the project completable — and what turns a good idea into something that ships.

Why it has to run locally

This isn't a cloud app and can't be. Taking control of an authenticated browser session requires local execution — Claude Cowork runs on my own machine, with access to my local Chrome instance and my already-logged-in Google account. No credentials are ever handed to a remote service. The photos never leave my environment until I choose to publish them.

That architecture is also why this is genuinely replicable. Anyone running Claude Cowork on their own PC could run this exact workflow for their own family. The website template is portable. The data format is simple. The automation logic is driven by natural language, not custom code that has to be maintained. It's a shippable pattern, not a one-off project.