About
I build software that has to make sense in real life.
Not from a traditional path, and not from a distance. The work came first. The tools followed.
Short biography
I came into software through work that needed better tools. I grew up around computers, built basic HTML sites as a kid, made StarCraft maps, learned Photoshop early, and built my first PC as a teenager. The interest was always there, but the serious systems work started later inside real operating environments.
Most of that early work happened in restaurants and hospitality. I worked across the floor and the back of house: line cook, busser, server, expeditor, manager, scheduler, order writer, hardware fixer, and general problem solver whenever a system stopped making sense. I started building practical Excel tools because that was what was available. They helped, but they were fragile, easy to break, and always needed somebody to keep them alive.
A genealogy site I built for my family became my first serious Next.js project and shifted something for me. It made it obvious that I could rebuild those operational tools properly instead of tolerating spreadsheet quirks. Since then I have been doing the most straightforward version of self-taught work: learn what is needed, build what is needed, and keep improving the systems until they hold up under real use.
Built from
The Comox Valley on Vancouver Island.
I lived in Melbourne for a time and once assumed I was more of a city person. What I missed was the Valley itself: space, weather, trees, coastline, and the feeling that the natural world is still close to the work.
Elsewhere
I tend to learn whatever is required to make things work. Outside software that spills into painting, writing, music production, photography, design, chess, hardware, and technical problem solving in general.
Why I build software
Clear systems are worth the effort.
I like software that starts simply, holds up under repeated use, and still behaves clearly when the real world gets uneven. Workflow fit matters more to me than polish without substance.
Start from the actual job
The real workflow usually matters more than the abstract feature list.
Keep the system legible
Good software should be easy to begin using and hard to misunderstand once the work gets messy.
Make it harder to break
Reliability comes from designing for awkward behavior, repetition, and ordinary human error.
Studio practice
Painting changed how I read what is in front of me.
I did not come to painting through formal art training. I started, very plainly, by learning through Bob Ross. Over the last several years it has become an important part of how I pay attention.
Painting sharpened my sense of light, composition, edges, and visual structure. It made me more aware of how people actually read what they are seeing, which carries back into interface work in a practical way.
Not separate from the work
I do not treat painting as branding or as a second profession. It matters because it changed my eye.
It made clarity feel less abstract. Composition, balance, contrast, pacing, and restraint are easier to notice once you spend enough time trying to paint what light is actually doing.
Current focus
Right now I am focused on product engineering work around browser-native tools, operational software, local-first systems, and interfaces that stay thoughtful under daily use.
Contact
The best fit is product work with real constraints, repeated use, and systems that need careful judgment rather than noise.
Get in touch