Chess Fish is what happens when I own the whole software problem.

I built a study experience, not just an engine screen

The idea behind Chess Fish is to treat a position as a landscape of choices. Instead of reducing the experience to “the engine says play this,” it helps a player compare candidates and understand what each move is trying to do.

The product combines Stockfish’s objective analysis with human-likelihood signals from Maia-3, then puts opening context, candidate scores and visual guidance around the board. Players can review games, explore variations, annotate and draw plans, import or export PGN, study openings, solve puzzles, save positions and work together in rooms.

What I had to make work underneath

I built the React client, the TypeScript and Node.js application services, the Postgres data layer and the connections between them. A player can change the position while analysis is running, open a variation, start another request, reconnect, or have several people look at the same room. The interface and services have to keep those states understandable instead of letting old results leak into the current position.

Analysis is long-running application work, not a single request and response. Chess Fish coordinates shared jobs, cached results, progress updates, streamed results, cancellation and per-account limits. The product can show useful information as analysis develops, while keeping the board, move tree and explanations tied to the position the player is actually viewing.

I also built the product around real use

Chess Fish has Google sign-in, saved user data and Stripe subscriptions. I connected subscription changes and payment webhooks to access decisions, and built free-tier limits alongside deeper paid analysis. That is the less visible work that turns a prototype into a product someone can actually sign into and use over time.

I built a separate private administration application and service to help operate it. It gives me visibility into system health, logs, accounts, subscriptions and usage so the player-facing application is not the only place I can look when something needs investigation.

The engine work is part of the product, not the whole story

Chess Fish uses Stockfish, the open-source chess engine. I extended Stockfish 18 in C++ with a Chess Fish-specific analysis mode that looks across the legal choices in a position, allocates work where additional evidence is useful, and sends structured results back to the application.

The Stockfish project deserves credit for the underlying engine. My work is the product-specific analysis behavior and the engineering that connects native code, server-side processing and the player-facing experience.

Why this matters to someone hiring me

Chess Fish is a concrete example of the kind of responsibility I can take on when a software problem does not fit inside one box. I have had to think about the person using the interface, the data model, background work, live updates, permissions, billing, native code and the tools needed to understand the system after it is running.

That is relevant when an application is slow or confusing, when two systems are no longer behaving together, when a background process quietly stops, or when a business needs someone who can follow a problem from the screen down to the service or integration behind it.

Chess Fish is my own product, not a client case study. I would not pretend that every business needs a chess engine. What it shows is that I can understand a complicated product as a whole, make the complexity useful to the person on the other side, and stay with the problem across technical boundaries.