Projects
These are not generic summaries. Each flagship project below is grounded in the code and plan documents that already exist in this workspace. Planned work is labeled as planned. Paused work is labeled as paused. Unfinished work is labeled unfinished.
Jump to a flagship
A local-first multi-agent coding pipeline I am still building: six model stages that plan, test, implement, review, and judge a task, running by default entirely against local Ollama models on my own hardware. It does not reliably finish real tasks yet, and the most useful file in the repo is the debrief explaining why.
Problem
I wanted to know how much of a coding workflow could actually run on hardware I own, with no hosted API in the loop. Not as a demo, but as something that could take a task off a backlog and come back with a branch. The interesting question was never whether a local model can write code. It was where a chain of small models breaks down, and whether the system around them can absorb that.
Build
The runner orchestrates six stages, decomposer through judge, across pluggable backends: Ollama, any OpenAI-compatible endpoint, the Claude CLI, and the Codex CLI. Every stage defaults to a local gpt-oss:20b model, and the frontier flags are explicit escape hatches rather than the default path. Each run gets its own git branch, a JSONL runtime log, and a written debrief when it cannot finish cleanly. A newer loop layer drains a markdown backlog one task at a time and installs as a Linux cron job so it can run unattended.
AI usage
The whole project is AI orchestration, but the part I actually learned from is operational: prompt-size budgets, why a six-link planning chain fails when the weakest link is a 20B model, and how to fail fast instead of letting a loop burn twelve attempts on a plan that cannot converge. I also read other open-source coding agents, aider and opencode, and wrote down which of their patterns to adapt: test-centric incrementalism, fallback edit strategies, and a did-we-get-closer heuristic for detecting a stuck loop.
Tradeoffs
This one is not finished and I am not going to present it as if it were. It is mechanically solid now, no hangs, no parser starvation, hallucinated dependencies get dropped, but it still does not reliably drive a non-trivial task to green on local models alone. After four consecutive failed days on the same task I wrote a debrief instead of adding another rule, concluded the marginal rule had gone net-negative, and rebuilt around blocking pre-flight plan checks and a small library of vetted stack templates. It is the clearest example here of me learning something by failing at it repeatedly and keeping the record.
A scheduled reporting app that turns ad-platform performance data into readable, AI-generated insight reports with web, email, and PDF delivery paths.
Problem
The challenge was not just to fetch metrics. It was to make the output useful to a person reading the report, which meant turning noisy numbers into a clear summary without losing the selected context.
Build
I built the project in Next.js with typed report configuration, scheduling, report generation, HTML and PDF output, and a reporting flow that supports both manual runs and recurring delivery.
AI usage
This is the most direct product-facing AI example in the portfolio. The app collects selected metrics and raw report data, builds a constrained prompt, sends it through the OpenAI API, and returns an AI summary that is then sanitized and embedded into the finished report output.
Tradeoffs
The reporting flow keeps working even if the AI step fails. The code falls back to a deterministic basic summary so AI improves the output, but does not block the product from delivering a report.
An internal transportation operations app that now runs the whole loop: trip entry, invoicing, payments, PO batching, an audit trail, a public client request portal, and a serverless deployment path.
Problem
The underlying workflow was fragmented across spreadsheets and role-specific handoffs. The goal was to move invoicing, accounting, trip tracking, and approvals into a single application instead of scattered operational memory.
Build
Node, Express, MongoDB, and Electron behind a role-aware UI, plus a serverless entrypoint so the same backend deploys to Vercel. Two brand variants ship from one codebase through a brand-apply script, and 56 test files run under the built-in Node test runner.
AI usage
AI is how I keep a growing internal product traceable. Every significant change lands as a dated plan document that states the request, the full implementation plan, and what was verified. The public request portal, the audit trail, grouped PO invoicing, and multi-stop trip legs each have one. That record is what lets a new session pick the product back up without me re-explaining it.
Tradeoffs
Most of what this page used to list as planned has shipped. Public intake is live, and the deployment answer turned out to be serverless on Vercel rather than the on-prem path I originally scoped. I would rather update the story to match the repo than leave a roadmap standing in for a result, and the work that is still unfinished stays labeled that way.
A Linux desktop configuration repo that evolved into a reproducible restore kit with custom Waybar modules, popup tooling, and scoped backup management.
Problem
I wanted more than a personalized Linux desktop. I wanted a setup I could understand deeply, customize aggressively, and still restore on a fresh machine without starting over from scratch.
Build
The repo tracks Hyprland, Waybar, GTK, autostart entries, custom Python and shell helpers, and a CachyOS bootstrap flow that restores packages, config targets, and selected editor and shell assets.
AI usage
This repo also reflects how I blend AI into systems work. It includes a Waybar AI-usage monitor for Claude and Codex usage, extensive plan records, and tooling that treats AI workflows as something observable and operational instead of vague magic.
Tradeoffs
The restore flow is intentionally selective. Secrets, browser profiles, auth tokens, and heavyweight machine-local data are excluded so the Git-backed bootstrap stays reproducible without becoming reckless.
A private AI voice assistant built on local models, now with a containerized backend, two documented Proxmox deployment paths, native shell clients on three desktops, and a SwiftUI iOS push-to-talk app.
Problem
The real problem was making a local-first voice assistant feel useful in real time. That meant wake-word detection, microphone capture, transcription, response generation, speech output, and device access all had to work together without pushing every interaction through a hosted API.
Build
I separated the voice-focused code into AI_Voice_Assistant, preserving the Docker backend and the native runtime together: FastAPI, Ollama, Redis, SearXNG, Whisper, Piper, wake-word tooling, and Windows, macOS, and Linux shell clients that stream audio into a shared assistant service. Deployment grew into two documented paths: a Docker Swarm stack and a native Proxmox LXC install with systemd units and a smoke test that has to pass before the deploy proceeds.
AI usage
AI is the product here. Ollama handles the local language models, Whisper handles authoritative speech-to-text, Piper handles text-to-speech, and the runtime coordinates wake detection, streaming voice turns, interruption handling, and the decision of when local AI should speak versus act.
Tradeoffs
The biggest lesson was that privacy and local inference are not enough on their own. The assistant only matters if it responds quickly, so the design leans on warm model management, streaming audio, concise spoken replies, and targeted latency reduction instead of treating local LLM usage as the finish line. Deploys are gated on a head-node smoke test, because a voice assistant that is down is worse than one that is slow.
Other builds / workflow systems
These are intentionally lighter than the flagship stories. They are here to show range: one is a paused local AI-coder experiment, one is the bootstrapper I use to shape AI around my workflow, and one is a smaller business-software proof point.
A local AI coding assistant experiment with multi-model candidate generation, judge synthesis, planner and executor flows, and a browser-facing control surface.
Why it belongs here
I intentionally paused this because the project started demanding more than implementation alone. To make it truly strong, it needed deeper benchmarking, evaluation, and training work, and I chose to prioritize other products and systems projects instead. The thread did not actually die. The same questions came back as Agent Pipeline, rebuilt around a staged pipeline, per-run git branches, and written debriefs.
Evidence
A portable repo scaffold that fine-tunes AI assistance around my process by giving agents shared rules, append-only plans, and implementation history.
Why it belongs here
It adds light process overhead, but the trade is worth it on bigger projects because the extra structure reduces context loss and makes AI help more consistent over time.
Evidence
An Electron and Node.js maintenance-tracking app for bus repair workflows, costs, and shared operational visibility.
Why it belongs here
This is a lighter portfolio entry because the repo evidence is smaller and the strongest narrative value is breadth rather than a deep architecture story.
Evidence