A Brief Account
I build things with AI.
I came to software through problems I wanted to solve. Most of them involved accessibility — tools that should have been better but weren't. I decided to make some that were.
Accessibility is not an add-on. It is where you begin.
I work from Canada. Mostly on AI-assisted tooling, accessibility infrastructure, and community software. I prefer learning in public.
I keep a written record of how each thing was made. The documentation is part of the deliverable, not an afterthought.
Right now: an accessibility map. A multi-agent system that ships real commits. A local-first prompt manager. A community mesh built for privacy. A command-line trainer. All of them open source.
Method
Three quiet steps, repeated carefully.
Describe the problem.
Use Claude Code as the primary building environment. Read the output. Course-correct when something is wrong.
Assemble the team.
For larger work, fifteen agents — each with a defined role, operating from a written constitution. Nothing is decided by accident.
Do not ship until you have used it.
Then write down what broke, what surprised you, and what the next person will need to know.
Principles
Accessibility. Privacy. No shortcuts.
WCAG 2.2 AA on every interface. Not because it is required. Because it is correct. AccessMap exists because disabled people deserve navigation tools designed for them, not adapted for them.
The user's data is theirs. Prompt Library stores everything locally — no backend, no account, no server. If the data is not necessary, do not collect it.
I would rather take longer and do it correctly than ship fast and apologise. This is not a principle from a book. It came from shipping things that were not ready.
Currently
Learning in public. Shipping on purpose.
I am not a trained software engineer. I came to coding through building — I had ideas I wanted to exist. That is still how this works.
Right now: TypeScript, React Native, multi-agent systems that stay safe unsupervised. Each project teaches something the last one did not.
I am looking for collaborators and clients who read the documentation, ask good questions, and care how things turn out. Write to me if that sounds like you.
The Work