Inspired By Frustration01 · The proof
↳ Products, client work, and internal infrastructure — each with a live destination, a named role, and a case study you can read.
No mock-ups, no invented logos. What follows is the ledger of what I designed, built, and still operate.
~30
parallel agents
directed by one accountable operator
55
PRs per day
30-day measured average
6
systems live
CMS status, counted on this page
02 · The evidence classes
↳ Live product, client work, internal infrastructure — the label tells you what kind of claim you are looking at.
A product I own is not the same evidence as a client outcome, and neither is the CI fleet that ships both. The ledger says which is which.
A product I own and operate — the claim is the running destination.
Built for someone else's business — the claim is scoped to what I was responsible for.
The fleet that ships everything else — inspectable, not a customer story.
03 · Flagship receipts
↳ Different products, one operating discipline: explicit outcomes, bounded systems, and proof you can inspect.
Each receipt shows the claim, the governing control, the outcome, my role, live status, and a working destination.
Turns a Lovable build into a production handoff someone can actually inspect.
One governed control plane for an MCP surface that keeps growing.
Captures the evidence a bug report usually forgets to include.
04 · The full ledger
↳ Smaller systems, client builds, and the studio platform itself — each with its status, evidence class, and case study.
Ordered as the CMS orders them. Nothing hidden behind a carousel.
A visual and product system for mapping the rhythm of a class into a playlist that supports flow, breath, and pacing.
The studio platform itself: marketing, API, CMS, auth, sitemap, project pages, and production deployment in one monorepo.
A content generation product with a Next.js dashboard, Hono API, Supabase backend, and structured brand/content workflows.
A concierge-style product experience for helping plant owners understand care, timing, and next best actions.
A local-service web experience built to connect a focused service offer with a measurable referral path back to the studio site.
Org-level GitHub Actions runner infrastructure with Fly.io pools, live status, cache systems, and queue enforcement.
05 · What I install
↳ Not a services menu — the four layers that show up when a fractional AI CTO engagement is working.
Agents on a board, governed MCP, CI that ships, and the ops that keep it honest.
Tickets humans and agents share — backlog → live, merge-aware.
One authenticated surface: discover, schema, invoke, audit.
Self-hosted runners, green-only merge, deploy in the same recipe.
Session logs, health, kill gates — so the system stays honest.
06 · How an engagement starts
↳ Diagnose where agents, CI, and product truth actually break; pilot one thin vertical; then ship and operate with kill gates.
The diagram is the real 4-week shape, rework loop included.
Where agents, CI, and product truth actually break.
One thin vertical that proves the stack on your repo.
Production path, kill gates, and a board you can run.
07 · The accountable close
↳ Bring the decision that keeps circling. I will turn it into a bounded plan, working proof, or a clear reason not to build.
No handoff maze. No junior layer. No claim that the agents are accountable when the operator is not.