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, 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. It's 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 launch: embeddable widget, authenticated dashboard, billing and marketing site. Pricing lands at Free, $7 Starter and $15 Pro. Live at trustglow.co.

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 static assets plus PHP/MySQL because the numbers did not justify the stack: a game platform is overwhelmingly static files 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. The front end is now served straight off a CDN and the PHP/MySQL layer sits behind it, so the marginal cost of the next game is close to zero. A deliberate downshift, chosen for the deployment economics.

2. 02

   Vanilla JS on the Canvas API instead of a game engine

   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

   A separately hosted PHP/MySQL layer holds the game registry, users, admin panel and analytics, while the games and shell are served as static assets from a CDN. 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
• Netlify

A live platform with multiple original games, split between a CDN-served front end and a PHP/MySQL control layer, sized for the catalogue to keep growing. Adding a title is a content operation rather than an engineering one.

IDP's Drive holds thousands of field photos across multiple countries and nested project folders, and a single photo often documents more than one thing at once: an Imam standing at a borehole is simultaneously a photo of that Imam and of that borehole. Folder-based organisation forces a choice between the two, or duplicate copies to cover both. Finding "photos of Imam X" or "our borehole photos" meant browsing folders by eye. The real task underneath is many-to-many classification, not filing.

1. 01

   Drive shortcuts instead of duplicating images

   key call

   The tool never copies a photo into more than one place. When an image is classified into several categories (a person, a masjid, a borehole), every category after the first gets a Google Drive shortcut pointing back to the one original file, not a duplicate. A photo showing an Imam beside a borehole shows up in both the Imam's folder and the borehole collection without existing twice on disk. That's what makes many-to-many classification viable at archive scale instead of forcing one folder per photo or multiplying storage with copies.

2. 02

   Local computer vision instead of a paid cloud API

   Face detection and recognition run locally on an InsightFace/ArcFace-style pipeline rather than sending organisational photographs, many containing identifiable individuals, through a third-party vision API. At thousands of images the per-image cost of a hosted API adds up, and keeping the pipeline local means the photos never leave the machine. Apple Silicon makes local inference fast enough to be practical.

3. 03

   Persistent processing state instead of full rescans

   A local SQLite database tracks every file the tool has seen, fingerprinted against four states (new, processed, duplicate, failed), so a run over a Drive with thousands of images can pause, resume, or pick up an interrupted job without re-scanning what's already been classified. A dashboard sits over this for choosing source and destination folders and watching progress.

• Python
• SQLite
• Google Drive API
• Google OAuth
• InsightFace / ArcFace
• Apple Silicon

Designed to process an archive of 10,000+ field photos, replacing folder-by-folder browsing with automated indexing by person and by subject. Built and working; a full run across the archive, with real throughput and classification numbers, is still ahead.