01 · Augmented solo operation
One person running a multi-product technology operation.
Between February and June 2026, a portfolio of products was built — a digital literacy programme, an apartment search tool, an AI job hunt toolkit, a business AI diagnostic, a personal consulting practice, and a full operational control layer — without employees, agency support, or venture funding. AI handles the build queue. The human handles strategy and judgement calls.
Overnight autonomous builds
A Windows Task Scheduler job runs nightly. It checks the sprint queue, pulls the next item, executes it end-to-end, files any required human actions to Notion, and logs the result — without waking anyone up.
A sprint backlog written to run cold
Every item in the backlog carries a priority level, effort estimate, return estimate, and a brief that can be executed cold — no context required from the person who filed it.
Sovereignty-first stack, exceptions named
The public sites are static HTML, CSS and JavaScript with no framework dependencies, hosted on GitHub Pages at $0, with a small Cloudflare Worker for the few server-side pieces. GitHub, Cloudflare, Notion and the AI models are third-party services, so each dependency is classified by how hard it is to leave, and the exceptions are written down rather than hidden.
Canadian sovereignty throughout
Products are built with Canadian privacy expectations (PIPEDA) in mind, in Canadian English, for Canadian users. The public sites collect no user data. The build tooling (GitHub, Notion, and AI engines such as Claude and Codex) is US-based and is classified in the sovereignty checklist rather than ignored.
02 · AI in real workflows — not demos
Automation that runs in production, not in a slide deck.
The tools listed below are not prototypes or proof-of-concepts. Each runs on a live product and has verifiable output. The commit history and log files are the receipts.
KevsCasa — daily automated listing refresh
A GitHub Actions workflow runs every morning. It scrapes London ON rental listings, normalizes the data, updates data/listings.json, and commits the result. No human trigger required. 144 automated refreshes had completed when last counted on 16 Aug 2026.
DCC — accessibility CI/CD on every push
Every push to the Digital Confidence Centre that changes HTML, CSS or JavaScript triggers an axe-core accessibility scan (WCAG 2.0 and 2.1 A/AA rules) via GitHub Actions. Critical violations fail the build; lower-severity findings are reported but do not block. It catches regressions between human reviews; it does not replace them.
Sprint queue automation
A Python script queries the Notion API, pulls the next highest-priority "Claude Code" sprint item, and routes it to one of the engines for execution. The human decides what goes into the queue; the system handles dispatch and sequencing.
Notion bidirectional sync
All human-required actions are filed to Notion programmatically — with a full brief, effort/return rating, and exact steps — by the same pipeline that files the build tasks. No copy-paste, no formatting by hand.
Session health check at startup
Every work session begins with an automated health report: overnight build status, CI/CD pass/fail, sprint queue depth, autonomy audit results, and changelog integrity — before any new work starts.
Pre-push content scanning
A git pre-push hook scans all staged content for sensitive markers and policy violations before any commit reaches GitHub. If the scan fails, the push is blocked and the issue is logged for review.
03 · Knowing when to stop
Documented failure modes, governance, and hard limits.
Most automation failures are predictable. The ones that aren't get documented so they don't happen twice. The governance layer below was built from real incidents, not theoretical risks.
Architecture Decision Records (ADRs)
Dozens of ADRs on file — each documenting a significant architectural choice, what was rejected and why, what the trade-off was, and what would trigger a revisit. Written at decision time, not reconstructed after.
Production deletion guard
A hard system rule — implemented after recognizing the risk of autonomous agents taking irreversible actions — blocks any DROP TABLE, force push, bulk delete, or cloud resource destruction without explicit human confirmation in the current session. Filed as a governance rule, not a suggestion.
Sovereignty tier system (L1–L4)
Every external dependency is classified before adoption: L1 (fully local), L2 (self-hosted), L3 (open-source hosted), L4 (third-party SaaS with export path). L4 tools require an exit plan before approval. The checklist runs before every new tool recommendation.
Autonomy audit loop
A nightly script scans the human-action queue for items that an AI agent can now execute autonomously. If found, they are pulled from the human queue and executed — preventing agent-doable work from consuming human time. The audit runs before every sprint session.
Token governance
A monitoring layer tracks tool call volume per session. It warns at configurable thresholds and logs anomalies — built after recognizing that unconstrained AI automation can generate costs faster than revenue. Volume ceiling: 200 calls triggers a warning; sensitive file access triggers a hard block.
Human action brief standard
Every task filed to the human queue must include: what it is in plain English, when and why it came up, why it matters and what gate it unlocks, exact numbered steps with URLs and phone numbers, time estimate in minutes, and what success looks like. Shorthand is banned — the brief must be cold-executable by someone returning after hours of absence.
04 · Prioritization as a system
15+ years of product strategy, applied to the operation itself.
Effort-benefit prioritization is not a philosophy here. It is a field in the database. Every task in the backlog has an effort rating and a return rating assigned at creation, not retrospectively. The sprint queue uses those fields to decide what runs next.
Effort × Return on every backlog item
The script that files tasks to Notion (file-aaron-action.py) requires --effort and --return parameters. Neither is optional. The fields are exposed in the sprint queue view so the highest-return, lowest-effort items run first.
Persona review panel
Before any sprint ships, it passes a structured review by a panel of relevant personas: founder, senior PM, accessibility specialist, privacy counsel, budget holder, and others depending on the work. Verdicts are filed to the session record. A REWORK verdict blocks the sprint.
Architecture status map — always current
A living document tracks every component in the stack: status (planned / built / wired / running / deprecated), what it connects to, and what changed in the last sprint. Updated on every push. The map is the source of truth for what the operation actually is.
Session state — continuous thread across sessions
Every work session begins by reading the previous session's state, ends by writing the current session's state. No context is lost between sessions. The record is the institutional memory of the operation — not a person.
Want to apply this to your business?
A 30-minute discovery call. You describe the problem. I ask questions. No pitch — just a useful conversation.
See consulting options →