Built through real operations work

I build software for real workflows.

Browser-native tools and operational systems that stay clear under repeated real use.

My path into software came through restaurants and hospitality, where better tools were needed long before there was time for elegant abstractions.

Local-first product systemsDense interface designOperational workflow software

Featured product

ChessIQ / Live

ChessIQ desktop analysis workspace showing the board, move list, and side panels

Import real games

PGN, Chess.com, and Lichess games flow into one review system.

Analyze locally

Stockfish runs in the browser, so analysis stays fast and private.

Train from mistakes

Mistakes become repeatable drills instead of one-off reviews.

At a glance

Real work first

Operator-to-builder path

03

Live products

07

Published notes

What the work is built around

  • Restaurants and hospitality Operational roots
  • Local-first product systems Built for repeated use
  • Browser-native tools Clear under real constraints

Featured work

ChessIQ shows how I like to build.

Local analysis, persistent study state, and a workflow meant to hold up in practice rather than just in a polished demo.

Why it matters

ChessIQ is the clearest example of the kind of product work I want more of: hard constraints, repeated use, and interface decisions that have to stay legible over time.

Full case study

Next.js + TypeScript

A maintainable product surface with clear boundaries and fast iteration.

Stockfish WASM

Engine analysis stays local instead of depending on backend compute.

IndexedDB persistence

Review state survives repeated sessions without losing context.

Responsive workflow UI

The same analysis flow works across desktop, tablet, and mobile.

Open to

Remote-friendly product engineering or frontend roles on teams that care about clarity, speed, and software that still makes sense once the edge cases arrive. The strongest fit is product work where real workflows, dense state, and trust in the interface actually matter.

How I work

Systems should stay legible.

Start from the real task

I design from the actual job, pressure point, or failure mode instead of an abstract feature list.

Keep the interface legible

Dense systems still need to scan quickly, explain themselves, and support fast correction.

Treat trust as product work

Runtime honesty, revision history, and repeated use all shape whether a tool actually earns confidence.