AI-first developer who ships full products solo — from architecture to production.

Cloud assistants can hold a conversation but cannot touch your machine, and the ones that can are usually thin shells around a terminal. I wanted one process that could do both — talk properly, and actually operate macOS — while staying usable when the network or the cloud provider fails. Everything runs on my own hardware.

1. 01

   Deterministic intent routing instead of LLM tool-calling

   key call

   System commands never reach the model. A routing engine resolves natural language against 60+ prioritised regex patterns to 34 concrete actions first; only genuinely open-ended input falls through to an LLM. Asking a model whether to open an app costs a network round-trip and can pick the wrong action from a plausible-looking set — neither is acceptable for something you say out loud and expect to happen. Routing is O(patterns), runs locally, and is testable without a model in the loop.

2. 02

   Hybrid cloud/local model routing with automatic fallback

   Gemini 2.0 Flash handles the primary conversational path; a failed cloud call fails over to local Ollama rather than surfacing an error. Model selection is task-specialised — a coder model for code generation, a vision model for local image understanding — so quality does not get traded away for a single general endpoint. The assistant degrades rather than stops.

3. 03

   SSE for token streaming, not WebSockets

   Once a prompt is submitted the traffic is one-directional, server to client. SSE is a plain HTTP response with built-in reconnection, so there is no second protocol to run, proxy, or keep alive. Tokens stream as they are produced.

4. 04

   Two-tier persistent user modelling

   Hard facts are pulled synchronously by regex the moment they appear — cheap and instant. A second asynchronous LLM pass runs off the critical path to mine personality, preferences and mood. Both feed a system prompt composed fresh per conversation, so the profile keeps deepening without adding latency to any single reply.

5. 05

   AppleScript as the OS control surface

   App launching, volume and brightness, media transport, Spotlight file search, Calendar, Mail and notifications all go through AppleScript — the sanctioned automation path on macOS, which keeps the permission model honest and the action layer readable.

6. 06

   Multimodal ingestion and a generation studio alongside the chat

   PDF, DOCX, XLSX, CSV and images are ingested into the conversation. A generation studio covers text-to-image, text-to-video and neural TTS. A separate news-intelligence dashboard aggregates five RSS feeds and plots geo-tagged articles on an interactive world map.

• Node.js
• Express 5
• React 19
• SSE streaming
• Gemini API
• Ollama
• AppleScript
• Web Speech API

Runs as a daily driver on one machine. It is deliberately a single-user localhost tool — there is no multi-tenancy, no hosted deployment and no auth layer, because none of those were the point. What it demonstrates is the routing, fallback and user-modelling architecture holding up under real daily use.

A business can have hundreds of genuine Google reviews and no way to put them on its own site. The options are copying testimonials by hand — stale, unverifiable, and worth nothing as proof — or bolting on a heavy third-party widget that fights the host page. TrustGlow pulls the real reviews and renders them on the customer site without either compromise.

1. 01

   Cross-origin embed isolated in a shadow DOM

   key call

   The whole widget ships as one script tag that a client drops on any domain. Rendering inside a shadow root means the host page cannot leak styles in and the widget cannot leak styles out — no reset stylesheet arms race, no iframe sizing workarounds. This was the hardest part of the build: it has to survive arbitrary CSS, arbitrary layout and arbitrary framework on the host, and it is verified working on live external client domains.

2. 02

   Two review sources behind one internal shape

   Google Places API drives the live pipeline today. A Google Business Profile OAuth pipeline is built and waiting on Google approval. Both normalise to a single internal review model, so the dashboard and the widget never learn which source a review came from and the second pipeline can be switched on without touching them.

3. 03

   LemonSqueezy for billing, because Stripe is not an option here

   Stripe does not serve South African businesses, which rules out the default answer. LemonSqueezy acts as merchant of record and handles cross-border tax, which is the right trade for a solo operator selling internationally — a real constraint of where the product is built from, resolved rather than worked around.

4. 04

   Supabase as the single backend dependency

   Auth and Postgres come from one managed service. For a product built and run solo, cutting the number of systems that can page you at 2am is worth more than assembling a best-of-breed stack.

• Next.js
• React
• TypeScript
• Supabase (Auth + Postgres)
• LemonSqueezy
• Google Places API
• Shadow DOM

Built solo and AI-assisted from first commit to pre-launch: embeddable widget, authenticated dashboard, billing and marketing site. Pricing lands at Free, $7 Starter and $15 Pro. Currently in the final UI/UX design sprint before launch.

Hosting a growing catalogue of original browser games cheaply, where each new game is a deploy-and-forget addition rather than an engineering project, and the whole platform stays controllable from one admin panel.

1. 01

   Re-architected off Next.js onto PHP/MySQL and vanilla JS

   key call

   The first working prototype was Next.js, React and Tailwind. I moved it to PHP/MySQL with vanilla JS because the numbers did not justify the stack: a game platform is overwhelmingly static assets plus a thin CRUD layer, and a Node runtime and build pipeline were buying nothing per request while adding hosting cost and deploy friction at the exact point where the catalogue is meant to grow. On commodity hosting behind Cloudflare the marginal cost of the next game is close to zero. A deliberate downshift, chosen for the deployment economics.

2. 02

   No game engine — vanilla JS on the Canvas API

   Physics, collision detection, particle effects and procedural environments are hand-written per game: Chicken Run, Meow Run, Ocean Drift. Each game is a couple of files that load instantly instead of a multi-megabyte engine runtime that mobile players pay for before the first frame.

3. 03

   Browser-native input beyond the keyboard

   Voice, camera and recording APIs drive microphone- and camera-controlled gameplay directly in the browser, with no install and no native shell.

4. 04

   The backend is the source of truth for the platform, not the games

   PHP/MySQL holds the game registry, users, admin panel and analytics. Any game can be toggled platform-wide from the admin panel, so publishing, pulling or A/B-ing a title is an operational action rather than a deploy. Monetization is architected around a Game Pass tier and ads.

• HTML5
• CSS3
• Vanilla JS
• Canvas API
• PHP
• MySQL
• Cloudflare

A live platform with multiple original games running on infrastructure sized for the catalogue to keep growing, where adding a title is a content operation rather than an engineering one.