01 Understand the business problem
Before any technology decision, I want to know what is actually costing someone time, money or risk - and whether the problem is real enough to be worth solving. Every application on this site started as a problem I lived with, not a technology I wanted to try.
- Tourney
- A tournament pool ran on paper and spreadsheets for 15 years. Scoring by hand took hours after every round and errors crept in every year. The problem →
- Runway
- After a job elimination, "am I financially safe?" was not a generic question - it needed my accounts, my taxes and real market history, not a calculator's guess. The problem →
- GetSeen
- A real job search means finding the right companies, screening roles for fit, tailoring every application and tracking all of it - and almost nobody has time to do that well. The problem →
- TD Bank
- The data-governance office needed audit-ready evidence that data was retained and disposed of per the DRD Standard, and had no standard way to produce it. I specified the tool that closed that gap. Detail →
02 Define the requirements and the operating model
Requirements are not just features. They include who operates the system, what "done" means, what can never happen, and how the thing is paid for. I write those down before architecture, because the architecture has to serve them.
- Control Tower
- Four enumerated conditions under which a production release is refused - a missing check, a pending check, a failed check, or an environment out of alignment. The list came before the code. The rules →
- GetSeen
- A three-tier product and pricing model, researched against the competitors' worst-in-category reviews, so the product's honesty is a requirement rather than a hope. Product thinking →
- Runway
- "Correct, then pretty, then fast - deliberately in that order." A priority order is a requirement too; it decides every later tradeoff. The engine →
- TD Bank
- Product ownership of the bank's Data Retention and Disposition Catalogue and its evidencing tool: I specified the requirements and directed the development, the same role I now play for my own applications. Detail →
03 Decide what should be automated and what must stay human
This is the decision most people skip. Automation is only valuable where a wrong answer is cheap or catchable. Where a wrong answer is expensive - money, reputation, a regulator - a human stays in the loop by design, and the system makes that boundary impossible to bypass casually.
- Runway
- The AI advisor narrates results and answers questions. It is never allowed to compute a number - every figure comes from tested code. The boundary →
- GetSeen
- The AI finds, screens and tailors. It never submits an application - every one still requires my own click. The boundary →
- Control Tower
- Staging is automatic once the gates go green. Production is a deliberate, separate human trigger - never automatic, never skipped. When a release fails, the AIOps loop investigates and proposes a fix; I approve or dismiss it. The AIOps loop →
- TD Bank
- Intelligent-automation operations at 99% straight-through processing - and the 1% routed to people on purpose, through exception queues, not dropped. Detail →
04 Design the architecture
I design for the second application, not the first. Where the same problem will show up again - a login system, a queue for AI work, a way to answer questions from documents - it becomes a component every application shares. Where isolation matters, the boundary is structural, not a convention.
- Platform
- Three applications share the same login security, AI tool loop, AI worker boundary and document-answering pipeline instead of each rebuilding them. The map →
- Worker Boundary
- The GPU host that runs self-hosted models never accepts an inbound connection. A worker polls a job queue and pulls work on its own schedule, so the model host is never reachable from the internet. The design →
- Tourney
- Analytics run in a separate warehouse (DuckDB, galaxy schema) instead of against the production database - reporting can never slow down or corrupt live scoring. Architecture →
- TD Bank
- Architected NAMES, an anti-money-laundering workflow application, on a reusable object-oriented framework. Still in production 20+ years later. Detail →
05 Build - with AI agents and conventional engineering
I use AI agents as an engineering force multiplier, not as autocomplete. The division of labor is explicit, and it is the same one I used with a development team: I own the specification, the review and the outcome; the agents do the implementation. The full model is below →
- Control Tower
- Built the same way it enforces: its own code goes through the same five gates and the same human approval it imposes on every other application. How →
- Tourney
- Two AI recap systems - a frontier model over a real tool interface, and a self-hosted open-weight model on the company's own GPU - built, compared honestly, and both kept. The comparison →
06 Test and validate
AI-written code gets more scrutiny, not less. Tests run against real infrastructure, not mocks; correctness is checked against an independent reference where the numbers matter; and security review is a step, not an afterthought.
- Tourney
- 950+ automated tests, run against a real MySQL database in CI. Testing →
- Runway
- A deliberately slow, deterministic reference engine exists only to prove the fast vectorized engine gives the same answer. 324 backend and 73 frontend tests. The engine →
- GetSeen
- A cross-tenant data-leak bug was found in a security review before production, then closed comprehensively - not patched at the one spot it surfaced. The incident →
07 Deploy through controlled CI/CD
Nothing reaches a live environment without passing the same gates: a secrets scan, the full test suite, lint, security lint and a dependency audit. A commit that passes promotes itself to the integration environment. Production is a separate, human-triggered step, and the tool that triggers it refuses to proceed if any check is missing, pending or failed.
- Platform
- One reusable five-gate pipeline, shared gate for gate across the applications and this site. The pipeline →
- Control Tower
- Fail-closed on purpose: a missing check is a refusal, not a warning. Every deploy, promote and refusal is logged with the real user who did it, and nothing in the log can be edited afterward. The audit log →
- TD Bank
- Automated the daily verification checks for nine enterprise applications with Power Automate, cutting review time from hours to minutes. Detail →
08 Operate, measure and improve
Shipping is the midpoint. I run what I build, and the incidents are documented on this site because the rule each one produced is more useful than pretending it never happened.
- Tourney
- None of its process rules were designed up front - each was added after something went wrong, and the incident log says which. The incident log →
- Runway
- A silent $0 answer and a stale-data result, each traced to a root cause and each closed with a structural fix rather than a patch. The incidents →
- Control Tower
- AIOps: a failed production promotion investigates itself. The AI reads the failed run, diagnoses it, and proposes a fix as a pull request I approve or dismiss. AIOps →
- TD Bank
- Nine applications, 1.3M+ documents a month, incidents cut by 90%+ by re-engineering how the platform was operated - then 50+ automations and an 83% incident reduction across the intelligent-automation estate. Detail →
+ How I use AI agents
This is the part that is easy to misread, so I will be precise. I do not use AI to autocomplete code, and I do not hand a problem to an AI and accept what comes back. I run AI agents the way I ran a development team: with a written specification, a defined architecture, explicit constraints, and a review gate nothing skips. The agents do much of the implementation. I remain accountable for everything that ships.
I define
- The business problem
- Requirements and acceptance criteria
- The architecture
- Constraints and the security boundaries
- What must be tested, and how
AI agents perform
- Implementation
- Refactoring
- Test creation
- Investigation and debugging
- Documentation
I own
- Architecture
- Code review
- Testing
- Security
- Deployment and production behavior
The economics matter too. Self-hosted open-weight models on the company's own GPU hardware carry high-volume, cost-sensitive work at zero marginal cost; a frontier model is reserved for the work where its quality is worth paying for. Every workload was run through both before that call was made. How that is decided →