Personal summary
I write software that engineers can understand, trust, and change, without losing sight of the experience it exists to support.
I work close to the product: understanding what the team is optimizing for, tracing the constraints in the code, helping shape the technical direction, and then writing the code in a way that works for the product and team.
I do my best work on small to mid-size product teams where product, design, and engineering can talk directly and make thoughtful tradeoffs.
View my resuméWhat I work on
Software where visual behavior is an integral part of the product.
Visual correctness, interaction quality, accessibility, rendering performance, and product architecture all affect the same user experience, so the technical choices have to be considered together.
Interactive products that customers primarily access through a web browser.
Workflows, state, permissions, data flow, product constraints, and interaction details all shape whether the software stays performant and understandable as it grows.
Products where people outside the core team need to configure, customize, or build on top of the system.
Backwards compatibility, developer tooling, documentation, versioning, and clear configuration contracts decide whether the platform can keep evolving.
The tools, checks, migrations, and workflows that help teams change product software with confidence.
Small gaps in validation, release process, documentation, or development workflow can turn into repeated bugs and cautious patching around problems nobody fully understands.
How to work with me
Most engagements start with a focused 2-4 week orientation around a product or engineering problem.
I use that time to work in the code, trace the relevant context, talk with the people closest to the details, and help the team decide what should happen next. Discovery and implementation happen together because working systems reveal tradeoffs that diagrams and planning conversations often miss.
This also gives both sides a practical way to evaluate fit before committing to a longer collaboration.
The best first conversation is about the problem in front of you: what you are building, who uses it, what feels hard to change or decide, and where technical direction is starting to matter.
About me
I want the code to explain why it exists. Every abstraction, dependency, pattern, and shortcut should be carrying its weight. I do not get much value from software that looks sophisticated but is hard to change. The better version is usually plainer: a system another engineer can understand, question, and safely reshape.
Technical depth matters when it changes what the product can do or makes the next change less risky. The right architecture depends on the shape of the work around it: who uses the product, who maintains it, what has to keep working, and what the existing code already makes easy or hard.
I trust implementation as a way of thinking. Diagrams and discussions are useful, but working inside the system exposes the details that decide whether an idea holds up. Sometimes the important thing is not visible until the code has to run, migrate, fail, or fit next to everything else.
I like learning tools well enough to know what kind of judgment they require. AI belongs in that category. I use it to explore directions, draft rough material, search through context, prototype, and automate small pieces of work. I do not use it to decide whether the result is correct, maintainable, or useful.
Software is one of the ways I learn. The code teaches you about the product, the constraints, and the people who will live with the decisions after you make them. I am usually trying to leave behind something a little easier to reason about than what I found.
Outside of work, I play trombone in a local concert band, tinker with home automation with HomeAssistant, cross country ski in the winter, bike around my city in the summer, tend to my perennial flower garden, and grow a few vegetables on the side.
Occasionally I'll take a week long camping trip into the Boundary Waters Canoe Area Wilderness, bike across various midwestern states on multi-day supported bike rides like RAGBRAI and Ride Across Wisconsin, or go for an adventure vacation wherever there's good hiking.
Prior to moving to the midwest, I spent a few years traveling around the United States and around the world as a digital nomad, learning to cook local dishes wherever I went. I've ended up with quite a few travel stories.
I also occasionaly write on my personal blog. It contains a mix of technical and travel content, but isn't updated very regularly.
Visit my personal blogIt helps to include what you are building, who it serves, what stage the product is in, and what kind of collaboration you are looking for.