Two decades of infrastructure. A new decade of building.

The problem

Any vendor or reseller selling infrastructure into a state agency wants to know three things: what does this department already own, when does it come up for renewal, and who currently sells to them. California publishes the data that answers all three, and none of it is usable as shipped. Two incompatible export formats arrive under the same file extension. There is no product taxonomy. Contract terms are buried in free-text line descriptions. The same supplier is spelled three different ways in one file.

What I built

A pipeline and web application that ingests the raw state exports, reconciles them into one schema with full provenance, classifies every purchase into a product taxonomy, overlays contract-renewal timing and statewide reseller authorizations, and generates client-ready account briefs. Currently 202,232 purchase orders, 761,000+ line items, and $40.8B in spend across 160 California departments — scaled from a nine-department, $17.2B pilot to statewide coverage without a schema rewrite, and now shipped as an independent business at goldenstatesignal.com.

It is not built for one territory or one manufacturer. The taxonomy, the lifecycle overlay, and the brief generation all generalize — every state, county, and large municipality publishes procurement data with exactly the same characteristics.

The decision that mattered

I ran an LLM pass to improve product descriptions, then measured it instead of assuming it helped. 7,575 enriched rows carried only 681 distinct texts, and 74% of rows had dropped a model number or SKU that was in the original. I killed the approach, salvaged the one component that worked, and documented the negative result so it would not be tried again.

That set the architectural rule the whole system runs on: the pipeline works with zero AI calls. Ingest, normalization, joins, ranking, and aggregation are ordinary deterministic code. The model is confined to turning already-correct structured output into prose. The brief generator makes two model calls and neither one produces a number.

What scaling actually tested

Going from nine departments to 160 was the real audit of the design. It ran without a schema rewrite, but it surfaced two data-quality defects that a smaller dataset had been hiding. A mislabeled duplicate export would have double-counted $439.5M. A fuzzy-matching rule misattributed $517M of dark-fiber spend to the wrong manufacturer. Both were caught before anything reached a client, and both were fixed at the methodology level rather than patched case by case.

Scale also forced an entity-classification layer. A supplier name on a California purchase order is usually a reseller, but not always — sometimes it is a manufacturer selling direct, a consultancy, or one state agency billing another. Separating those cut the unattributable bucket from 39% to 18.5% of enterprise-relevant spend, which is the difference between a competitive map you can act on and one you have to caveat.

Where it came from, and where it goes

Version one was a 450-record HTML dashboard I built for my own territory. This is what it became once the question changed from what do I need to what would a vendor pay for. It now runs as its own business under the name Golden State Signal, with a public site, a live read-only demo, and a sample strategy document, each carrying a chat assistant scoped to what it is allowed to answer from. Next is multi-tenancy, once paying clients need it. The architecture has been built toward that migration without paying for it early.

Read the full engineering breakdown →
The four-source demand chain, where the model is and deliberately isn't, cost engineering, and the honest limits.

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

The trip ended in April. The photos went where all family photos go, into a camera roll nobody scrolls back through. Nine days across three states, six places worth remembering, and the whole thing was about to dissolve into a thousand unsorted images.

I wanted something my kids would actually open in twenty years. Not an album. A story, with the route, the places, the photos, and a voice to read it.

What I built

A narrated travelogue at roadtrip.jayleone.ai/memories. Six chapters following the real route, from the departure through Paso Robles, Sedona, the Grand Canyon, Zion, and Dana's birthday on Pismo Beach. Each chapter carries its own written story, the photos from that specific place, a set of theme tags, and a full audio narration generated with ElevenLabs so the whole thing can be listened to, not just read. It opens on an illustrated route map and closes with a highlights grid of the moments nobody wanted to forget.

The interesting part, and why this one matters most

This is not one app. It is a chain of tools composed into a pipeline. The raw material did not come from a camera roll. It came from the road trip app I had already built with Claude, the one that ran live GPS, collected photos from five different phones, and logged the schedule as we went. That app captured structured data while we traveled.

After we got home, I took that same data, the route, the stops, the photos, the timeline, and worked with Claude to write the story and ElevenLabs to give it a voice. Build the system. Capture the data. Compose the data into something nobody had to assemble by hand.

The AI-native piece

The skill on display here is not "I used an AI tool." It is composition. Claude built the app. The app captured and structured the data. Then Claude and ElevenLabs turned that data into a narrated, chaptered artifact that did not exist before. AI writes code, AI structures data, AI generates media, and the value shows up when you string those together into a workflow with a real output at the end.

That is the capability enterprises are scrambling to find right now. Not operators of a single tool, but people who can chain several into a pipeline that produces something new. A pile of vacation photos became a permanent family document. The same instinct applies to a pile of customer data, or a quarter of deal activity, or a backlog of support tickets.

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.

The problem

Leaving town for a weekend sounds simple until you try to hand off the details of a multi-animal household. In our case: Rocket, a Staffordshire Terrier; Lola, a pug; Tater Tot, the axolotl; and Queso, the bearded dragon — each with their own feeding schedule and care quirks.

None of it is complicated. But it's exactly the kind of thing that gets scattered across text messages, forgotten in a note, or followed up with anxious "Did this get done?" messages while you're three states away.

What I built

A mobile-first web app for a single pet-sitting workflow. Individual animal profiles with photos, care notes, and feeding instructions. A weekend checklist organized by day and time of day. When the sitter checks off a task, the update writes to Supabase and appears on the owner's device in real time.

The first version was fully static — HTML, CSS, JavaScript, and localStorage. From there I added Supabase for real-time sync and separate owner and sitter passcodes. Completed tasks are immutable, so they can't be accidentally unchecked, and the owner can reset the checklist for a future trip. No app store, no install, no account required.

The product decision worth noting

I initially built a proper authentication flow using Supabase magic links. It worked, and it was wrong. Email delays, rate limits, and redirect behavior introduced too much uncertainty for a neighbor who just needs to check in on the animals.

So I backed out of the "more correct" solution and replaced it with a simple passcode gate. Owner passcode opens owner mode. Sitter passcode opens sitter mode. That isn't enterprise-grade auth, and it's not pretending to be. It's the right trust model for a private link shared with a known person. Product quality often comes from removing sophistication, not adding it.

The AI-native piece

Built through conversational iteration in Codex. Describe the household, add the animals, upload the photos, refine the checklist, test the real-time behavior, adjust the auth, simplify the UX. The magic-link reversal — implement, test, find it wrong, replace it — took an afternoon. In traditional development, that kind of reversal feels expensive. In an AI-native workflow, it's just product discovery.