About
How I work, what I believe, and what I’m good for.
I’m a Design Engineer with a product-design heritage. Over 10 years designing enterprise SaaS, fintech, and consumer products. For the last three, building them end to end too. That combination is rare: most engineers don’t come from design, and most designers don’t ship production code.
I care more about the stuff below the interface than the stuff on it. The interesting problems at senior level aren’t “how does this screen look.” They’re “what is the right product to build, and how do the systems underneath support it.” Design thinking is the lens; engineering is the way I get to ship the answer.
Design and code, not design or code
The gap between designed and shipped used to be weeks. A spec, a handoff, a slow loop of reviews. The compromises stacked up on both sides. The design drifted, the implementation drifted, and the thing that actually shipped was a third, worse thing. I got tired of it.
Now I close the loop myself. I design in Figma when structure needs thinking through, and I build in TypeScript when the real answer is in the interaction. Some problems only become visible in code: the latency of a state change, the feel of a transition, the way a form field fails. Those are design decisions, and they’re easier to make while writing the code that renders them.
Accessibility as a default, not an audit
At Peak I led the first accessibility playbook (WCAG 2.1) and a colour-vision-deficient data-visualisation framework. At IBM’s Weather Channel I ran the design QA and accessibility audits for products at 100M+ MAU. The lesson from both: accessibility is a design-system problem, not a ticket-tracker problem. The patterns that make a chart or a form accessible for one user make it more resilient for every user. Screenshots, projectors, eye fatigue at 4pm, the subtle ways interfaces fail.
My rule of thumb is the same everywhere: colour alone is never sufficient. Every piece of information carried by one channel should be carried by at least one more.
AI agents as leverage, not replacement
I use Claude Code, Windsurf, and ChatGPT daily. They’re the reason I can ship a multi-tenant SaaS in 11 days as a sole developer (Nexus Portal), or a hybrid-search job-matching bot in a few weeks (Text Ari), or an AI code reviewer I can actually use on my own repos (CodeLens).
What the agents don’t do is taste, strategy, or judgement. They can write a data model; they can’t tell you which data model is right for a product that hasn’t been built yet. They can implement a flow; they can’t tell you what the flow should look like for a user who hasn’t used the thing before. I do those parts. The agents do the typing.
The result isn’t cheaper design or faster coding. It’s a tighter loop between deciding what to build and having it running in front of a user. That loop is where good products come from.
What I’m good for
Teams I’ve done my best work with have three things in common:
- A complex product domain. Data-heavy dashboards, AI-assisted workflows, identity verification, forecasting. The kind of products where the hard part isn’t the UI. It’s figuring out what the UI should say.
- High-velocity shipping culture. I work fast and I work end-to-end. Long handoff loops kill the thing that makes me useful.
- A willingness to let design lead the technical call occasionally. Some product decisions get made by the person drawing the flow, not the person designing the database. I’m that person.
If that’s you (Senior Product Design or Design Engineering role, ideally with product ownership and system-level autonomy) I’d like to hear from you.