A personal side project, developed from scratch: design, architecture and code. Released in 2021 and still growing, it is the oldest project in this list that I actively maintain, and the root of everything chess I have built since.
Motivation
There is something special about combining software with real world objects. Playing chess virtually is just different. You cannot feel the pieces, smell the wood, hear the satisfying sound when you move a piece. These things make chess special. WhitePawn combines both worlds: it brings a digital chess experience to your real board.
The project also let me go deep on Flutter, and it is where I wrote my first driver for a physical device.
Talking to real boards
An electronic chess board is a grid of sensors with some LEDs and a radio. Every vendor invented their own protocol on top of that, and their own transport too: some boards speak Bluetooth Low Energy, some classic Bluetooth, some want a USB cable. WhitePawn supports boards from Millennium, Certabo, DGT (including the Pegasus), Chessnut, ChessUp, Square Off, iChess and Blichess, which means the app contains a driver for each of these dialects: code that decodes the byte stream coming from the board and encodes commands going back, like lighting LEDs to show the opponent’s move.
I built the drivers as standalone packages with no dependency on the app, so any Flutter developer can build their own board-connected apps on top of them. They are published on pub.dev, the package repository of Dart and Flutter: chesslinkdriver for Millennium boards, dgtdriver, certabodriver and chessnutdriver, with the newer drivers developed openly on GitHub. Each driver separates the protocol parser from the transport behind a small communication interface, so the same Certabo driver runs over a serial cable or a wireless link without changing a line of protocol code.
One board out of many
Supporting eight vendors is not eight times the work of supporting one, but only if the differences stop at the driver boundary. And the differences run deeper than protocol: every board is different hardware. Some have LEDs, some none. The Chessnut Move physically moves its own pieces. The DGT can show moves on its attached clock. Some report battery, some sense only whether a square is occupied. Above the drivers sits a normalization layer that turns every vendor’s view of the world into one common currency: a board position mapping squares to pieces, and a BoardUpdate describing what changed between two states. Each hardware ability hides behind a small capability interface, so the app asks “can this board show a move?” instead of “is this a DGT?”. The rest of the app never knows which board is connected.
The interesting problems live in the middle. Raw board states pass through a pipeline of transformers before they reach the app. One detects whether the board is physically flipped, from how the pieces cluster at the start. One suppresses duplicate states, because hardware loves to repeat itself. The hardest one deals with piece identity: several boards only report that a square is occupied, not which piece stands there. For those, the layer tracks every position the game could legally be in and prunes candidates as more moves arrive, until reality is unambiguous again.
Playing the world from a wooden board
Local engines are half the story. The other half is moving a real piece and having it arrive on a server across the world. For that I built open_chess_platform_api, a small package that hides online chess platforms behind one interface: authenticate, manage challenges, watch a game as a stream of events. Currently it has one implementation, Lichess, but nothing in the app knows that.
The Lichess connection covers the full loop. OAuth runs through the system browser and returns into the app via deep link, token refresh goes through my Node.js backend, and games run over the Lichess Board API: the app streams game events (initial state, every move with clock times, chat lines) and posts the moves you make on your physical board. Your opponent’s replies come back as LED patterns on the wood in front of you. Inside the app, an online game, an engine game and a puzzle are the same thing: one game abstraction emitting one stream of snapshots, so screens do not care where the moves come from.
Streaming
Once a real board is digital, its games are worth broadcasting. That is PawnTown, the streaming side of this project: WhitePawn feeds it the live position from the physical board, and it renders a stream-ready view with board, clocks and engine evaluation that organizers drop straight into their broadcast layout.
The South African Open Championship 2026 broadcast its blitz rounds this way, with the PawnTown board and move list beside the players:
Chess clubs run their tournament broadcasts on it too. Schachunion Ebersberg-Grafing has used the board and clock widget across several seasons of rapid and blitz, credited in every broadcast:
Watching strangers build their broadcasts on something that started as “I want to play on wood again” is the part of this project I am most fond of. And the thread continues: the board drivers, the platform layer and the broadcast idea all grew up and moved into WhitePawn Web.