I build useful software and weird little games.

The ideaI spent ten years working nights in hospitality. Workwear brands sell to the day shift. This one is built around the hours the rest of us are asleep.

The buildThe punch clock is the navigation, with a live hand on the current time. Each hour opens one short screen for one garment, then a lookbook and product pages. Short pages instead of one long scroll.

An honest noteThe label is fictional. I designed the brand, wrote the copy and directed the garments and photography, which were generated with AI. The site says so in its footer.

The buildA long-form article with real, credited photographs, then the newsletter built as Mailchimp-ready email HTML: table layout, inline styles, and a button that still works in Outlook.

Technical decisionsOne set of type and color tokens drives both, so the article and the email read as the same publication.

The problemRepair shops book work over the phone and track it on paper tags. The customer finds out what it costs at the counter, and the shop copies the same details onto three different pieces of paper.

The buildCustomer side: service selection, availability that only offers slots the shop has open, bike intake with a photo, and estimate authorization before any work starts. Booking done, you get a printable work tag. Shop side: flip to the shop demo and your booking is on the schedule board with your bike's details.

Technical decisionsOne dataset drives both views, so the customer flow and the shop board can never disagree about a booking. Work orders carry the authorized estimate with them, because "who approved this" is the question that starts arguments at real counters.

Built withOne HTML file, zero dependencies. Invented shop, and the page says so.

The problemAn agent can write a quote in seconds. Somebody still has to check the math and decide who is allowed to approve it.

The buildYou type the deal. The agent drafts the quote. A check that shares no code with the agent recalculates every line, and anything outside the rules is held for the right person. Every step lands on a trail you can read.

An honest noteA working concept. The company and the prices are made up, and the page says so.

The problemThe first version of that reel was one long hand-written script. Changing a single shot meant editing code and waiting for the whole film to render again.

The buildA Windows app. You set up a product, record the real thing running, arrange shots on a storyboard, snap the cuts to the music's beats, leave review comments, keep versions, and export in landscape, portrait and square.

Working with AIIt has a connector, so Claude can read a project, make an edit and render a draft while I review. Every change it makes is logged, and I can undo it.

ProofMore than 2,200 automated tests. The rebuilt reel matches the hand-made one on every cut.

Why it is privateI use it for my own work and for clients. The app and its code are not public.

Built withElectron, React and TypeScript.

The problemMost site audits produce a checklist without knowing which failures matter. A broken footer link and a broken booking button both show up as "broken link," but only one of them costs the business money.

The buildA planner selects deterministic inspection tools, gathers evidence from real page fetches, traces the critical flow end to end in a sandboxed copy of the page, and prioritizes findings by severity times business impact. There's also a Break the Site mode: sabotage a sandboxed copy yourself, then watch the same tools find the faults without being told what you broke.

What makes it agenticThe loop, not the tools: it identifies what needs investigation, chooses a tool, examines the output, updates its state, forms hypotheses, runs further tests to confirm or kill them, verifies candidate fixes in the sandbox, and stops when the work runs out or it hits an honest iteration cap.

Failure behaviorWhatever it could not test is reported as an uncertainty instead of invented certainty: external links it won't follow, contrast over background images it can't resolve, work left in the queue when the cap hits.

An honest noteNo language model runs in the browser demo. The planner is a deterministic policy engine occupying the seat a model takes in production, and every measurement comes from a tool either way. The page says all of this itself.

Built withPlain JavaScript, same-origin fetch plus DOMParser, sandboxed iframe instrumentation. Zero dependencies, no backend.

Why I built itTo show clients what a real document-grounded assistant looks like without hand-waving. The page IS the demo.

The buildSixteen policy chunks embedded in the page; your question is scored against them client-side; the best chunks become the answer, with the source document cited under every reply.

Failure behavior, by designAsk something outside the documents and it says "I don't have that in my documents, so I won't guess" and gives you the office contact instead. An assistant that guesses is worse than no assistant.

Built withOne HTML file, no libraries, no API. The production version of this pattern runs on an LLM with the same retrieval discipline.

The problemRecurring business data arrives messy. At Ninth Hill, the invented roaster here, a week of order emails gets retyped into a spreadsheet every Monday: three hours of work, the same coffee spelled three ways, and a totals row that doesn't add up. The report costs more than it tells.

The workflowRAW ROWS → VALIDATE / AGGREGATE → KPIS → CHARTS. In this demo the whole pipeline runs in the page: 567 raw wholesale rows are aggregated, recomputed and rendered live at load, nothing precomputed. The messy-spreadsheet ingestion story the page tells is the depicted production shape (a script cleans recurring exports into one dataset). No scheduler exists in the demo, so none is claimed.

Technical decisionsNo chart library. Every number on screen is derived from the visible dataset, and the claimed insight (a seasonal blend overtaking decaf) is genuinely in the data, checked to the week.

Built withOne HTML file, nothing to install, the awful spreadsheet included.

The problemAI agents rarely do the same thing twice. That makes them hard to trust with anything that costs money or touches real data. The run that worked in testing is not the one you get in production.

Why I built itI run agents across my own projects every day. I wanted a harness that stops a run cold instead of letting it wander, and that shows me how much its behavior actually varies instead of me assuming it's stable.

The buildThree stages. A planner turns the goal into an ordered plan that can only name tools I registered. An executor validates every argument and checks the cost, time and step budget before each move. A separate checker model decides whether the result satisfies the goal. Runs halt when they hit a limit instead of warning and continuing, and every decision lands in structured JSON logs.

Technical decisionsAn eval command runs the same goal several times and reports how much the answers diverge, so nondeterminism gets measured instead of assumed. Failed runs propose lessons, but a lesson only reaches the planner after I approve it by hand. Nothing it learns gets reused without a person in the loop.

Built withPython and the Anthropic API. Tests run against mocked calls, so the suite stays fast and deterministic.