I’m Josh. Here’s how I got here.

I got tired of re-explaining who I am at the start of every session, so I built a linked knowledge base with a documented retrieval policy: every note describes itself, and one command returns the whole map. Every AI session I run reads it first, on my laptop, in the cloud, and on my phone. I tested it cold once and it answered six of ten questions from the notes alone, citing where each answer came from — and the four it missed were things I had genuinely never written down.

• ReadI stopped re-explaining myself to my AI— the whole story, including the cold-start score
• CodeThe instruction file that runs this site— the same idea, applied to a codebase instead of a life (opens in a new tab)

I turned a research method Stanford published into a tool I can invoke. It runs fourteen agents on one question — five perspectives interviewing each other against live search, then eight fact-checkers — and I pointed it at company earnings. Every report on the Market Storm section came out of it, and each one prints how many of its own claims survived checking.

• LiveMarket Storm— five reports, all produced by the pipeline
• LiveA report, with its verification ledger— confirmed / partly true / corrected, counted on the page

A model asked to check its own work agrees with itself, so the instruction has to be to refute, and the agents have to be different ones. On the Microsoft report it changed the headline rather than adding a caveat: the widely repeated line was that capex doubled while free cash flow stayed positive, and free cash flow had actually fallen. I have also run it on my own finished research and lost — seven of eight load-bearing claims came back corrected, and I shipped the corrections.

• LiveThe report whose headline the check rewrote
• ReadA pipeline with no server— how the automated half of this fits together

I asked for ten image templates and kept four. What settled it was rendering both versions side by side rather than arguing about them, and measuring an instinct instead of acting on it — I thought the type would look wrong on a phone, and measuring showed a card renders at 341 pixels there, where 69% of the words were unreadable. The six I cut had each cleared a quality bar the AI wrote for itself.

• CodeThe image generator and its four templates— including the written reasoning for the cut (opens in a new tab)
• LiveThe images, in both themes

For VOLTIC, an energy drink that does not exist, every visual was generated: the hero can, the splash photography, a turntable video. The spend had a hard ceiling written into the code, so the pipeline stops before the budget does. And when no video model would render the tiny print on the back of the can, I stopped fighting it — the can became a real 3D model wearing a label typed in the site’s own fonts, so every angle is correct because it is built, not painted.

• LiveVOLTIC— the launch page, every image generated (opens in a new tab)
• LiveThe write-up— what is built into it, in plain language

I run scheduled agents with names and job descriptions — one tidies the knowledge base nightly, one sweeps it weekly, one drafts the day's writing before I wake up. The ceiling is deliberate. Making that last step automatic would be easy and I do not want it, because judgment is the part I keep.

• ReadI built my own dashboard, then took it apart— why the thing that watches cannot live inside the thing it watches
• ReadWhat my AI handed back— where the line between us actually falls

Most of what is in the gallery is this: a restaurant platform with a menu, a cart and a checkout; a journalling app wired to a language model; a focus timer with session analytics, a twelve-week heatmap and an achievement system. Different problems, same loop.

• AppSamurai Kitchen— Next.js · React · TypeScript
• AppAI Diary— Next.js · React · TypeScript
• AppPomodoro Timer— Next.js · React · TypeScript

I built ordering for a friend's food truck against his real Square catalogue rather than a copy in the codebase, because his kiosk already runs on it and any second copy is one that goes stale. That meant full support for his customisations — twenty-two modifier lists, with the prices resolved on the server so the browser cannot name its own. It went live with real money at the end of August 2026. The menu, the prices, the opening hours and what has sold out all come from his till now, refreshed every minute, so when he marks a dish sold out on the truck it greys out on the site before the next customer can order it. Two things I had been telling him were true turned out not to be until I tested them on the live site — the sold-out flag was never being read, and the menu was cached for hours — and both are fixed because I checked rather than assumed.

• AppSamurai Kitchen— Next.js · React · TypeScript
• LiveThe live ordering page— menu, prices and sold-outs straight from the till (opens in a new tab)
• ReadI built my friend's food truck site with AI— what actually happened, including what I did not ship

Until launch the site ran on an access key carried by hand from Rob's Square dashboard to mine, and replacing it needed both of us on a call. So I built the connect flow: he tapped one link, approved on Square's own page, and the site switched over to his connection while I watched. No key was typed, copied or texted by anyone. The tokens sit encrypted at rest in a small Postgres database, a daily job renews them before they expire, and if the connection ever fails the code falls back to the old key, so no single dependency can take ordering down. Two of my own mistakes got caught before they mattered: a different encryption key per environment against one shared database, which would have made anything saved from a preview unreadable in production, and a job endpoint that only checked for a secret if one had been set — it had not, so it failed open. A second business can now connect without a line of code changing, which is the part I built it for.

• AppSamurai Kitchen— Next.js · React · TypeScript
• Livesamuraikitchencatering.com— every item on it arrives through that connection (opens in a new tab)

A customer could have paid at three in the morning on a Sunday and the order would have sat unseen, so checkout reads Rob's opening hours from his own Square account and locks outside them. He edits his hours in his dashboard; a week off is just a week set to closed, which fails safe. Hours are harder than they look — overnight spans, the week wrapping, midnight in the wrong time zone — and twenty-two tests cover them. The rest came out of real use. Last orders stop thirty minutes before close, because a katsu takes time to fry. The footer once said Monday: Closed while checkout was happily taking Monday orders, because two parts of the site had two ideas of the hours; now there is one. And an order scheduled for six o'clock was landing on his terminal at noon, because Square treats a scheduled order with no prep time exactly like an immediate one — nothing in the documentation's labels said so, only its behaviour. I placed one order for later and watched it arrive under Upcoming instead of Active, which is the receipt.

• AppSamurai Kitchen— Next.js · React · TypeScript
• LiveThe ordering page, outside opening hours— says when it closes today, and when it reopens (opens in a new tab)

Before publishing an article about my own tools I stopped and asked whether they could be attacked, and found my live task list — forty-three items — being served to anyone with the URL. I closed it in about sixty seconds with a reversible fix, then built the proper gate, and only restored the data after watching production actually deny the request. On the restaurant checkout, an audit nobody asked for found the server taking the charge amount from the browser. After that site went live I went looking again, on the live site rather than in the code: a scheduled endpoint was answering anyone with the owner's merchant details, because its check only ran if a secret existed and none did — it read as correct on the page and failed open in production. The same pass found no browser security headers at all, no rate limit on the two routes that move money, and a status page that told strangers whether the business was connected. All closed, then verified live: a ten-shot burst at checkout drew a 429.

• AppSamurai Kitchen— Next.js · React · TypeScript
• ReadI found my own task list on the open internet
• ReadI tried to break my friend's AI-built site— and deleted the hole instead of patching it

An order total read $0.00 on the deployed build and was correct locally every time. My machine runs one long-lived process; the deployed one does not share memory between requests, and the mock state was sitting in it. Same category as a ten-minute build hang that turned out to be pages calling a live API while they were being built. The one that mattered most came after launch: the live card form was loading Square's test-mode script, so every test card had passed and no real card could — a hard-coded address that nothing in the build could catch. It took a real card at a real truck to find it, which is why the launch test was a real order and not a checklist.

• AppSamurai Kitchen— Next.js · React · TypeScript
• ReadMy dashboard said published. The URL said 404.— the same lesson in a different disguise

Teaching a scheduler to publish without me took six failures, and five of them reported success. The worst flipped an article halfway, failed, and then went invisible to every later run because it was no longer due — reporting "nothing to do" over a permanently stuck state. The fix was a reconcile pass. It now opens and merges its own pull request with nobody watching. The newest one answers a question the food-truck owner actually asked — how long does a katsu take? — by syncing every order from his till into a database: watermarked, progress saved per page, time-boxed so a ninety-day backfill finishes across runs, and safe to re-run, so a later Ready tap just updates the row.

• ReadFive of my six failures reported success
• ReadA pipeline with no server

At work this guards financial aid arithmetic — twenty-three assertions on every single change, because that is the part which is not allowed to be wrong. The same pattern runs on this site: a test refuses an article dated in the future, and another one refuses to ship a post with missing images, which immediately found two already-published posts with no social card. The food-truck site got the same fence after launch — checks on hours, encryption and pickup times, kept in the repository after the scratch copies quietly vanished — and one of them had been reading the wall clock and failing by time of day for weeks.

• CodeThe tests that guard this site (opens in a new tab)

A Mars transfer simulation that models a real launch window, and a cloth simulator where every thread stretches, folds and tears. Both are hand-written with no game engine underneath, which is the only way I would have learned what the maths actually does. The newest rep is a 3D drink can rendered live in the browser, spun by scroll or by hand.

• AppSpaceX Mars Transfer Simulation— HTML5 Canvas · Vanilla JavaScript · CSS3
• GameCloth Simulator— HTML5 Canvas · Vanilla JavaScript · CSS3
• LiveThe VOLTIC can— live 3D, spun by scroll (opens in a new tab)

The arcade is six cabinets. The Pembroke File is the one I would point at first: a five-act mystery where every clue is an object you pick up and read, puzzle boards checked by a program that solves each one before shipping, wires that really swing, and a pencil-rubbing canvas where the answer is never drawn — only revealed by shading around it. The newest cabinet is a chore-tracker my family actually uses, chores as quests with gold and gear. Two of the cabinets are my son's.

• GameThe Pembroke File— HTML5 · Canvas · Vanilla JavaScript
• GameBroom & Blade— HTML5 · Vanilla JavaScript · CSS3
• GameAUREUM Snake— HTML5 · CSS3 · Vanilla JavaScript
• GameGrove— HTML5 · SVG · Vanilla JavaScript
• LiveThe arcade— all six, playable in the browser

This site runs on semantic tokens rather than colour values scattered through components, which is what makes dark mode a switch instead of a rewrite. The palette is deliberately warm charcoal rather than black, because cold black would throw away the identity the light theme has.

• CodeThe design system, written down— every rule that is a decision rather than a default (opens in a new tab)
• LiveThe site itself (opens in a new tab)

The arcade's bright red, yellow and blue fail contrast on a paper background, so every text use points at a darker ink. In dark mode those inks flip to the bright neon, which pops on the dark cabinet. A light-mode constraint turned into a dark-mode feature — the rule made it better rather than duller.

• CodeThe ink flip, and why it exists (opens in a new tab)
• LiveThe arcade, in both themes

The first sweep lit up with every generated tell I had reached for by instinct: coloured rails on cards, tinted sub-panels, cramped table frames. I reworked each into plain headings, dividers and coloured text. Where the tool was wrong I overruled it by name, in writing, scoped so the same pattern elsewhere still gets caught — no suppression without a reason, and "intentional" is not a reason.

• CodeHow the audit runs, and what I overruled (opens in a new tab)

I asked for my task board to be drag-reorderable and it already was. The real gap was different: card order lived only in each device's storage, so "make it draggable" and "set the order for me from somewhere else" were never the same feature, and only one of them was missing. Same instinct that turned "it flings when I drag slowly" into a diagnosis rather than a patch.

• ReadI put an app on my home screen in a day— the six prompts, and which three stood on earlier work

Robert has been a friend since high school and runs a Japanese catering business. Two calls on that job were mine rather than technical: I deleted a loyalty panel that promised points nothing awarded, and removed a review funnel that routed happy customers to Google and unhappy ones to a private form. Both were working features. Neither was honest. It went live with real payments at the end of August 2026. Then his first tap on Ready sent no text, because Square only texts orders its own products create — so rather than promise one, the success page now says to give your name at the window, and the text pipeline I built sits switched off until it is wired to a number. The calls since have been his, not mine: no menu photos, a classic list instead; last orders half an hour before close; take orders now, texts later.

• AppSamurai Kitchen— Next.js · React · TypeScript
• Livesamuraikitchencatering.com— his live site (opens in a new tab)

Fourteen articles so far, all about my own builds, and the ones people respond to are the ones where something broke. The rule I write to is receipts over claims: if I cannot point at the thing, I do not say it.

• LiveEverything I have written
• ReadYou don't get replaced for being slow

My son wanted to make a game. I could have built it for him, and instead I taught him the loop: describe it, get something playable, look at it, ask for the next thing. He built a kart racer — his features, drive-over powerups and coins that make you faster — and then a second game on his own, which is the part that shows it transferred. The hard bit is not taking the keyboard.

• GamePebble Kart— HTML5 · TypeScript · Canvas
• GameGrove— HTML5 · SVG · Vanilla JavaScript
• LiveHis cabinets in the arcade