I turn operational complexity into dependable software, with a current focus on applied AI.
Architecture · applied AI · AI-enabled delivery · legacy-to-modern · Vancouver, BC, Canada
Most people meet Cursor as an IDE and drive it by prompting: describe, review, correct, repeat. Working one level down, against the SDK, the constraint looks different — the limit is not how well any single prompt is written, it is that a person has to stand in the gap between every step. Better prompts and skills shorten the steps; they do not remove the gaps. So I took the problem apart from the bottom: the prompt, then the context each role is given, then the harness it runs inside, and finally the loop that connects them — who hands to whom, what must travel with the handoff, and what each role is forbidden to do. The last layer was where the leverage was, and it is the one nobody was building.
IMPACT Built TaskFlow on that idea — an internal tool where a stated goal moves through spec, implementation, test and review on its own, and I am asked for a decision rather than for the next prompt.
The web product is the next generation of a desktop system that has been running in the field for decades, and the easy version of that project is a port: rebuild each Windows screen in a browser and ship it. That produces something users recognise and nobody is excited by. I joined with no prior time in the product, and within six months had designed and shipped a map-first live operations dashboard and then led the design and build of a new dispatch planning module — neither of which existed on the desktop in that form. The judgment that mattered was which capabilities deserve to be carried forward, which habits are worth breaking, and where new technology genuinely changes what a screen can be.
IMPACT The dashboard reached a feature-complete production candidate and the planning module closed a visible gap quickly enough to put in front of customers — neither of them a replica of the screen it replaced. The AI introduced alongside them is the starting point the product’s later AI work builds from.
Invoice review was slow and uneven because the rules lived in prose and in people’s heads rather than in any rule engine. Instead of opening with a specification, I built something that ran — assembled on the APIs the shipped release already exposed — and put it in front of the people doing the work. Arguing with a running system is far more productive than reviewing a document: requirements arrived as corrections to actual output. And because it stood on shipped APIs rather than scaffolding, the distance from that prototype to a first production version was short. That is the part I care about — a prototype nobody can productize is just a demo.
IMPACT Reviews an order in 3–5 seconds, more than 95% faster than manual review; capstone score 98%. Just as important, almost nothing had to be thrown away between the prototype and a version fit to ship.
I have entered the company hackathon every year it has run. Most people enter as a team, which is the sensible way to do it — I enter alone on purpose — not because I prefer working alone, but because the hackathon is the one place I can test my own judgment end to end. Splitting the work would make the deadline easier and teach me less. Going solo means the idea, the architecture, the build, the deck, the demo video and the presentation are all mine to get right, which compresses the full arc of a product — from choosing a problem worth solving to showing it working — into a few days. It is the fastest honest feedback I get on my own judgment, and the one setting where nothing can be delegated away.
IMPACT Three years, three working prototypes, each finished and presented on schedule — and each one a rehearsal of the same loop the day job runs on: find a real pain point, build something that actually runs, put it in front of the people who have the problem.
Most of this product predates me: Windows desktop applications, DB2 stored procedures, integrations written when SOAP was current. The reflex with software like that is either to leave it alone or to propose replacing it, and both are usually wrong. What has worked for twelve years is narrower — find the one place where the old system is actually costing someone time, and put something modern exactly there, leaving the rest untouched. A system does not have to be rewritten to get better. It has to be understood well enough that you know where the new part fits.
IMPACT Twelve years on one product without ever proposing a rewrite. Each of these left the surrounding system intact and still removed work people had accepted as permanent — and the most recent put AI on the part of the stack that was supposed to be untouchable.
I was pulled off my own team to help another one build a cloud accounting integration, in an ecosystem I knew nothing about. There is no useful version of that where you stay a visitor. I had four months, seven systems across four architectural layers, and people in several groups who each owned one piece and none of the whole. So the first job was becoming someone they could argue with — learning their domain well enough to design, not just implement. The last job mattered more: handing ownership back completely enough that the team could carry it without me.
IMPACT From no domain knowledge to a production-ready pipeline and a completed handover in about four months — and the team that owns it now did not inherit a dependency on me.
IntelliNord was not a single WMS application. Working directly with the owner, I translated warehouse, customer, compliance, and billing workflows into one connected product suite operating across very different environments. I owned the architecture and implementation from user interfaces and business logic through databases, integrations, server deployment, and long-term production support.
IMPACT Created the shared technology foundation connecting warehouse-floor execution, customer visibility, automated integrations, compliance, billing, and finance.
The warehouse never operated alone: billing, finance, and corporate reporting each lived in a different large external system, each with its own data model, protocol, and failure modes. I designed and maintained the integrations that kept IntelliNord and these platforms consistent, so information entered once on the warehouse floor arrived everywhere it was needed.
IMPACT Operations, billing, finance, and corporate reporting stayed in step without manual re-entry between systems.
Years of transaction history were sitting in the legacy database, doing two jobs badly: audits meant slow scans over live tables, and the only backup was the database itself. Instead of touching the core, I extended it upward: archived transaction data flows into AWS DynamoDB — a deliberate choice of a key-value store over a relational one, because archive lookups are key-shaped and never need joins — and an AWS API layer serves it back on demand. The warehouse system never noticed; the cloud simply grew around it.
IMPACT Historical data became safe, offloaded, and queryable at once — and the live database, freed of years of history, stayed small and fast. Audits stopped competing with live operations, and the legacy core kept running exactly as before.
Vehicle tracking then mostly meant recovery after theft: you phoned a service and they worked with the police to find the car. Nobody offered the ordinary thing — letting an owner simply look at where their vehicles were, right now, without asking permission. That is what we built: a live map in a browser, on Google’s mapping API at a time when embedding a moving map in a business application was still a novelty. I was the founding technical member, and everything under that map was mine to build.
IMPACT The company’s product was in effect this technology: the devices we had proven, the platform they reported into, the map customers logged in to, and the billing that invoiced them — all built in-house from nothing.
When mobile data services were still emerging, I helped build a WAP booking application backed by Java APIs connected directly to the real-time airline reservation system. Its simple mobile interface let travelers check availability and complete a booking from a phone, while the live integration delivered the speed and accuracy the service required.
IMPACT The service rolled out quickly and became a preferred mobile booking option for many business travelers at the time.
Architected and developed the ETC online booking and inquiry interface, connecting flight availability, schedules, and reservations across the web experience. Also supported release planning, technical estimates, and developer mentoring.
IMPACT Established a practical foundation for online travel booking as the domestic internet market was taking shape.
I noticed that report, passbook, and certificate printing depended heavily on manual positioning and adjustment. I built a template-based printing tool so teams could define layouts once and generate documents consistently instead of reworking placement by hand.
IMPACT Made printing faster and more accurate, while reducing repeated manual setup for banking reports and customer documents.
Worked across client-side banking functions, server-side services, and reporting modules on Unix terminals and HP-UX servers with Informix databases.
IMPACT Built a foundation in reliable, detail-oriented software for high-consequence business workflows.
Much of this work is internal. I share the architectural approach and outcomes, without exposing product screens or customer data.
An internal tool that turns one developer’s AI coding session into a small software team. You state a goal; TaskFlow plans the work and stands up a roster — product spec, development, QA, code review — each a full agent session with its own model, its own AI-written prompt, and its own isolated context. They hand work to each other along a delivery loop: spec locked, implementation ready, tests pass, review approved, pull request opened. When one of them needs a decision it asks out loud, and you answer by voice. In the recorded walkthrough, one ticket goes from goal to open pull request in about seven minutes.
Independent software projects, published here as they become ready to use.
It started from a bill: I pay for more than one AI coding agent, and I was still using them one at a time. AgentMux runs them together — Cursor Agent, Codex CLI, and Claude Code, each in its own tmux session on the same project directory — and streams every terminal into one browser page. Give three agents the same task and watch how differently they think, or split the work and let them run in parallel while you watch from a phone. Fully open source.
A trading workbench running on my own server, built around one rule: the model reasons, but it never decides. When a bar closes, TradeLab captures three timeframes, assembles the numeric context — volatility, regime, volume profile, multi-timeframe trend — and asks two independent AI models to write a thesis against a fixed strategy. What comes back is never an order. It is a proposal, and it has to clear a series of deterministic checks before any code is permitted to place it. Each thesis is recorded before the outcome is known, then scored against what price actually did. Self-hosted and single-user: the journals, the account connection and the strategy live on my own hardware rather than inside someone else’s product.
Most ideas die in the gap between "I can describe it" and "I can show it". chatPOC closes that gap: the site is the front door — you describe the idea and answer the questions the AI asks back — and behind it a pipeline drives multiple AI tools to produce a requirements document and a running prototype. Free, no account required. What the pipeline turns out is published on the open-source account below.
One account, kept deliberately: everything I publish lands here, and it is maintained for the long term rather than left to rot after a burst of activity. Today it holds the chatPOC tool, nineteen pipeline-built prototypes, and AgentMux — the first of my personal projects to move here, with more to follow as each is ready.
Many older adults keep a physical binder — medical cards, insurance, key contacts — so family can act if they are suddenly hospitalized. But a paper binder grows heavy, is neither fireproof nor waterproof, and stays at home. Emergency Binder moves it onto the phone that is already in their pocket: photograph or dictate the important things, and the app keeps them encrypted, organized, and ready to hand to family when it matters.
One camera cannot tell the whole story of a hockey game: follow the play and you lose the goal, stay on the goal and you miss the build-up. Dual Cams records two iPhone cameras at once — wide on the play, telephoto locked on the net — and when something happens, one tap on the phone or the watch saves the last moments from both angles as finished clips. The whole rig: an iPhone on a gimbal on a tripod.