Rook Chess

Gli scacchi si allenano in due modi completamente diversi. Sul telefono sono tre minuti in fila: un esercizio, una variante, e via. Alla scrivania è un’ora con la scacchiera aperta, una partita ripercorsa mossa per mossa leggendo perché ognuna è stata giocata. La maggior parte delle app sceglie uno dei due e tratta l’altro di sfuggita: un sito desktop compresso, o un’app che in realtà è un sito dentro una cornice.

Rook Chess doveva farli bene entrambi. La strada ovvia erano due progetti: un team app e un team web, due backlog, due cicli di rilascio e un database condiviso che non è di nessuno. Costa il doppio e, soprattutto, garantisce che i due divergano: una lezione aggiunta sul web impiega settimane ad arrivare sul telefono, e i progressi fatti sul telefono compaiono tardi alla scrivania.

Lo abbiamo impostato come un unico prodotto con un backend e due interfacce. Lezioni, posizioni, progressi e pianificazione dei ripassi esistono una volta sola, dietro una API. React Native regge il telefono, Next.js la scrivania, e ciascuno mostra lo stesso materiale nella forma che quel modo richiede: sul telefono una scheda e una scacchiera grande, alla scrivania la scacchiera accanto al commento, perché la scacchiera è l’unico elemento che non può rimpicciolirsi.

Il perimetro era scritto prima che esistesse una riga di codice, compreso quello che restava deliberatamente fuori dalla versione uno: nessuna analisi con motore, nessun multigiocatore, nessun account oltre a quanto serve per tenere traccia dei progressi. Sono esattamente le funzioni che fanno crescere un prodotto di scacchi all’infinito, e indicarle come escluse fin dall’inizio è ciò che ha permesso di rispettare prezzo e data fino al lancio.