Case study
ChessIQ
Browser-based chess review and training app that imports your games, analyzes them locally with Stockfish, surfaces mistakes, and turns them into personalized training puzzles.
This project shows how I approach technically dense interface work: start from the real workflow, keep the runtime truthful, and shape the underlying complexity into a tool people would actually want to use repeatedly.
At a glance
- Imports games from PGN, Chess.com, and Lichess into one local-first review workflow.
- Runs Stockfish in the browser through WebAssembly and worker-based orchestration for private, fast analysis.
- Turns mistakes from analyzed games into personalized training puzzles and repeatable study sessions.
What I was solving
Most chess products are optimized for playing, content, or platform lock-in. I wanted a review tool centered on the part that actually helps players improve: importing your own games, finding the critical mistakes, and understanding them while the positions still feel fresh.
What made it hard
Running a serious chess engine in the browser means dealing with startup uncertainty, threading differences, noisy intermediate output, storage limits, and dense interface requirements across desktop and mobile. The product had to stay fast and legible without pretending the runtime was simpler than it is.
What I chose
I built the review loop around local-first analysis, progressive deepening, and explicit runtime checks. That lets the interface surface useful feedback early while still preserving the difference between provisional output and deeper engine-backed conclusions.
How it feels to use
The interface is designed around a clear post-game workflow: import, review, inspect critical moments, and train on your own mistakes. The goal was to make a technically dense system feel focused enough for repeated real use, not just occasional demos.
What it shows
- Next.js and TypeScript application architecture for a dense, multi-surface product
- Stockfish in WebAssembly with worker-based orchestration for browser-native analysis
- IndexedDB and local persistence for saved games, repeat study, and offline-first behavior
- Responsive analysis UX spanning desktop review, tablet study, and compact mobile flows
What I learned
- A strong product story lands better than a long feature inventory.
- Runtime honesty is part of product quality, not just engineering hygiene.
- Local-first architecture gets more valuable when the interface explains uncertainty clearly and stays usable across devices.