days of continuous operation
6
products in production
1,696+
commits across 6 repositories
automated data refreshes
overnight autonomous builds

01 · Augmented solo operation

One person running a six-product technology operation.

Between February and June 2026, six production products were built and shipped — 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.

logs/automated-run-log.md · 24+ entries

133-item sprint backlog, fully queued

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.

Notion backlog · hal-stack/sprint-system/sprint-queue.md

Sovereign stack — no SaaS lock-in

Every product runs on self-hosted infrastructure: GitHub Pages, Cloudflare Pages, static HTML/CSS/JS with no framework dependencies. Zero monthly platform fees. Zero data handed to third parties.

hal-stack/architecture/decapitation-checklist.md · 5 ADRs on record

Canadian sovereignty throughout

All products built to Canadian privacy standards (PIPEDA), Canadian English, and designed for Canadian users. No cross-border data flows. No US-only tools in the critical path.

WCAG 2.2 AA · AODA compliant · Canadian English throughout
days running
6
products shipped
1
person
$0
platform fees / month

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, normalises the data, updates data/listings.json, and commits the result. No human trigger required. 70+ automated refreshes completed.

twobirds-kramerica/kevins-apartment-search · .github/workflows/ · 70+ runs

DCC — accessibility CI/CD on every push

Every push to the Digital Confidence Centre triggers an axe-core automated accessibility audit via GitHub Actions. Failures block the build. Zero manual test runs needed — WCAG 2.2 AA is enforced by the pipeline.

twobirds-kramerica/digital-confidence · .github/workflows/ · 555 commits tested

Sprint queue automation

A Python script queries the Notion API, pulls the next highest-priority "Claude Code" sprint item, and routes it for execution. The human decides what goes into the queue; the system handles dispatch and sequencing.

hal-stack/notion-sync/next-sprint.py · hal-stack/notion-sync/file-aaron-action.py

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.

hal-stack/notion-sync/SYNC-LOG.md · 132+ actions filed programmatically

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.

hal-stack/scripts/session-healthcheck.py · runs every session

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.

hal-stack/guardrails/pre-push-hook · token-guard-log.md
70+
automated data refreshes
24+
overnight build runs
58
automation scripts
132+
actions filed programmatically

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)

Five 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.

hal-stack/architecture/decisions/ · ADR-001 through ADR-005

Production deletion guard

A hard system rule — implemented after recognising 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.

CLAUDE.md · PRODUCTION DELETION GUARD · always on since 2026-06-09

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.

hal-stack/architecture/decapitation-checklist.md

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.

hal-stack/scripts/autonomy-audit.py · hal-stack/docs/autonomy-audit-latest.md

Token governance

A monitoring layer tracks tool call volume per session. It warns at configurable thresholds and logs anomalies — built after recognising that unconstrained AI automation can generate costs faster than revenue. Volume ceiling: 200 calls triggers a warning; sensitive file access triggers a hard block.

hal-stack/guardrails/token-guard-log.md · provider-agnostic design

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.

hal-stack/governance/rules.md · welcome-back-brief rule
5
ADRs on record
5
governance documents
L1–L4
sovereignty tiers
0
production data losses

04 · Prioritisation as a system

15+ years of product strategy, applied to the operation itself.

Effort-benefit prioritisation 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.

hal-stack/notion-sync/file-aaron-action.py --effort Low|Medium|High --return High|Medium|Low

Persona review panel — 42+ reviewers

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.

hal-stack/personas/ · hal-stack/founding-board/ · 42+ active personas

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.

hal-stack/docs/ARCHITECTURE-STATUS.md · updated every sprint

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.

SESSION-STATE.md · updated every sprint · never cleared
15+
years product strategy
133
queued sprint items
42+
active review personas
100%
tasks with effort/return rating