About

I've spent a decade building things on the web, almost entirely in environments where the consequences of getting it wrong are real: a bank customer can't complete a transaction, a fleet dispatcher can't see a bus, a financial advisor gives advice based on stale data. That context has shaped how I approach everything from component API design to CI pipeline choices.

My earlier years were generalist: JavaScript, some Rails, a lot of jQuery, the full arc of pre-React frontend. Around 2016 I went deep on React and haven't surfaced since. Not because it's the only option. It's where the hard problems I care about live: state management under real concurrency, design systems that actually scale, accessibility that isn't an afterthought.

I've worked at startups where I was the only frontend engineer and at banks where the frontend org had 80 people. Both extremes taught me things the other couldn't. I prefer the middle: a team with real engineers and real constraints, where architectural decisions have lasting consequences.

Design systems and component architecture. I've built or significantly shaped component libraries at two financial institutions. The technical work (tokens, Storybook, publishing pipelines) is the easy part. The hard part is the API design: how do you write a component that's easy to use correctly and hard to use incorrectly? I think about this a lot.

White-label and multi-tenant UIs. Shipping the same product to multiple clients with different brands and requirements is an underrated architectural challenge. Token-based theming, feature flags, and careful prop API design matter here in ways they don't in single-brand products.

Accessibility at the component level. Not "audit the site and fix the findings." Building accessibility into the component API so consumers can't easily ship inaccessible patterns. TypeScript-enforced ARIA relationships, keyboard navigation that actually works, announcements under streaming content.

Performance with real constraints. Lighthouse scores on a MacBook on wifi don't tell you much. I care about performance on the hardware and network conditions your actual users have. Map renders with 400 live vehicles. Streaming LLM content without layout shift. Bundle splits that matter in regulated environments where CDN caching is restricted.

Compliance in fintech and banking. Most frontend engineers treat compliance as someone else's problem. In financial services it isn't. I've worked under strict CSP policies that block third-party scripts, no-store cache directives from security teams, data residency rules that constrain how and where you fetch, and audit requirements that reach into the UI layer. The skill is translating a regulatory constraint into a concrete frontend decision, not routing every compliance question to the back end and waiting. WCAG isn't optional in financial services; neither is understanding why your bundle can't phone home to a CDN your security team hasn't approved.

A generalist who'll claim expertise in everything. I know the frontend stack deeply and I can hold my own in infrastructure conversations, but I'm not a DevOps engineer or a mobile developer. I've written backend Node.js but I wouldn't own a complex distributed system solo.

I'm not excited by greenfield work for its own sake. The interesting problems are usually in systems with constraints: legacy code, compliance requirements, performance budgets, real users. Blank-slate projects where anything goes produce mediocre software because the constraints that force good decisions are absent.

Senior or staff-level frontend roles where the work has real technical depth: design systems leadership, frontend architecture, or owning the UI layer of a complex product. I'm particularly drawn to fintech, regulated industries, and developer tooling.

Remote-first is ideal, but I'm open to Toronto hybrid and to relocation. I'm a Canadian citizen and can work in the US on a TN visa without employer sponsorship cost, which means the visa process is typically a same-day border crossing, not a 6-month petition. I'm also genuinely open to the UK, EU (particularly Germany, Netherlands, or Ireland), and Australia.