Rook Chess

On travaille les échecs de deux façons très différentes. Sur un téléphone, ce sont trois minutes dans une file d’attente : un exercice, une variante, et on range. Au bureau, c’est une heure avec l’échiquier ouvert, une partie reprise coup par coup et l’explication de chacun. La plupart des applications choisissent l’une des deux et traitent l’autre en passant : un site de bureau à l’étroit, ou une application qui n’est qu’un site dans un cadre.

Rook Chess devait faire les deux correctement. La voie évidente aurait été deux projets : une équipe application et une équipe web, deux backlogs, deux cycles de livraison et une base de données commune que personne ne possède. Cela coûte le double et, surtout, garantit que les deux divergent : une leçon ajoutée sur le web met des semaines à atteindre le téléphone, et la progression faite sur le téléphone arrive en retard au bureau.

Nous l’avons cadré comme un seul produit, avec un backend et deux interfaces. Leçons, positions, progression et planification des révisions n’existent qu’une fois, derrière une API. React Native porte le téléphone, Next.js le bureau, et chacun présente la même matière dans la forme que ce mode exige : sur le téléphone une carte et un grand échiquier, au bureau l’échiquier à côté du commentaire, parce que l’échiquier est le seul élément qui ne peut pas rétrécir.

Le périmètre était écrit avant qu’une ligne de code existe, y compris ce qui était délibérément exclu de la version une : pas d’analyse par moteur, pas de multijoueur, pas de comptes au-delà de ce que le suivi de progression réclame. Ce sont exactement les fonctions qui font grossir un produit d’échecs sans fin, et les nommer comme exclues d’emblée est ce qui a permis de tenir le prix et la date jusqu’à la mise en ligne.