Engineered Proof of Work
// work
What Outer Orbit builds.
Volunteer Hub
Sports associations were managing volunteer hour reconciliation in Excel. Late nights before board meetings. Manual cross-referencing against rosters. Nobody had fixed it because nobody really owned it.
Concept to live platform in eight weeks. The speed isn't the story.
Building without traditional developer instincts forces a different kind of discipline. Every AI agent that opens a codebase is a capable contractor who just walked in with no context. They write confident, well-intentioned code that compiles, runs, and can silently write to the wrong column in the database. You'd never catch it until a family complained their hours were missing.
So the architecture was designed around that constraint from the start: rigid layer rules, enforced guardrails, a test suite that acts as surrogate expertise. A codebase built to constrain and guide its own contributors.
Now it runs a reconciliation engine that matches volunteer submissions against member records and flags compliance gaps automatically. The Volunteer Coordinator checks in weekly to confirm the numbers look right. That's the whole job now.
Impact
“300+ members. 1,000+ volunteer activities tracked. One coordinator. Zero weekend reconciliation sessions.”
ChatGPT Foundations
I spent a long time learning ChatGPT the inefficient way. Lots of trial and error, a few rabbit holes, occasional revelations. Eventually the patterns became clear enough to explain.
That's where this came from. The rule I used to build it: if I can explain something to someone who isn't technical, I probably understand it. If I can't, I don't.
Aimed at people who want to actually use AI to get things done, not just follow along.
Impact
“If you can explain it simply, you understand it. That's the only test I used to build this.”
Sales Enablement
Six years in full-cycle B2B field sales. Oil & gas, mining, construction, forestry, logistics. Sitting across from real buyers, running real demos, watching where the materials landed and where they didn't.
When I moved into enablement, I didn't start with a framework. I started with the list of things I'd wished existed when I was carrying a bag.
First year: a custom AI sales assistant deployed to the entire global team. A Custom GPT used across daily workflows. A Solution Assembly Guide that pulled the full product portfolio into one field-ready reference. A global rep performance scorecard. A Tactical Team Playbook for the North America sales team. A platform-selection GPT to cut down the time reps spent going down the wrong path.
None of it came from a playbook. It came from having sat in the chair and known exactly what was missing.
Impact
“Ramp time cut by 6+ months. Built by someone who lived the problem first.”
// process
I learn it, build it, then explain it.
That loop is how most of my best work has come together. No methodology. Just a pattern I keep coming back to.
01
Absorb fast, get the mental model right.
The first step isn't building. It's figuring out what's actually broken — who's dealing with it, what they've already tried, and why the obvious fix hasn't stuck. I do most of this by starting to build. Prototypes tell me things that conversations don't.
02
Build before it's fully designed.
I tend to start building while I'm still learning. That's not recklessness, it's how the design gets tested. Most good ideas fall apart somewhere between theory and a working system. I'd rather find that at 30% than at 90%.
03
Explain it until it's simple.
If I can't explain something clearly to someone outside the room, I don't fully understand it yet. Explaining it out loud is how I know if I actually got it. It's also what makes the work useful to someone else.
The measurement step tends to show up after the solution is already running. Still working on fixing that.
// about
I've never picked a lane. That turned out to be the point.
Sales. Marketing. Technical operations. AI. There's usually a wall between them.
I've spent my career sitting between rooms that don't talk to each other. Design and engineering. Marketing and sales. Technical teams and the field. Each group has its own language, its own assumptions. They rarely agree on what the problem even is.
I learned to translate.
Technically literate, not a traditional developer. Close enough to build alongside AI, evaluate what will scale, and connect commercial instinct to what actually ships.
The pattern keeps repeating: whatever's manual becomes a system, whatever's disconnected gets integrated, whatever's in my head eventually has to work for someone else.
Outer Orbit is where I get to apply all of that without asking permission.
Not a portfolio. Everything here is running and solving a real problem for real people.
3
Active builds
~0
Lines written by hand
100%
Execution focus
Before 'UX' was a job title, I was designing the UI for one of Canada's first cloud-based dental platforms. Collaborating with developers, solving for clinical workflows, and producing investor assets in the same week.
Not a developer, but something more useful in the room. Enough hands-on production experience to PM creative agencies without getting taken. I knew what things actually cost, how long they took, and when a scope was ballooning for no reason. That same pattern carries across O&G, mining, construction, and general technology. Drop me into a technical conversation in any of those and I stay with it. Engineering curiosity is just how I'm wired.
Full-cycle B2B across oil & gas, mining, construction, logistics. Sat across from real prospects. Know firsthand where marketing material lands and where it crashes. That feedback loop is something most marketers never close.
The pattern is consistent across every role: manual work becomes process. Process becomes tool. Tool becomes scalable. That's not a framework. It's just what keeps happening.
© 2026 Outer Orbit · Engineered Proof of Work