ChessDesk
A lightweight operations and business-management app for independent chess coaches in South Africa.
Status
BuildingFocus
Full Stack, Operations
Primary Stack
Python + FastAPI
Type
Case Study
Product at a glance
See the workflow in action
Four screens show how ChessDesk brings the day-to-day work of a chess coaching business into one focused workspace.
Overview
Overview
ChessDesk is a single-user web app that gives independent chess coaches one place to manage students, parents or guardians, school clients, sessions, communication, invoices, payments, expenses, and basic business performance.
Individual students with parent or guardian contact details and school clients
Session lifecycle from scheduling through completion, cancellation, and updates
Automatic session communication through WhatsApp, email, or both when enabled
Flexible manual invoicing, external payment records, and private expense tracking
Dashboard metrics for revenue, payments received, outstanding amounts, expenses, and net income
Motivation
Why I Built It
ChessDesk is an exploration of focused operations software for independent chess coaches in South Africa. The product specification starts with a simple need: manage the coaching day and understand the business financially from one place.
The project is deliberately domain-shaped rather than a generic task list. It treats students, parents or guardians, schools, sessions, communication, invoices, payments, and private expenses as connected parts of a coaching business.
Problem
The Problem
Problem statement
Independent coaches often manage their day across spreadsheets, calendars, invoices, and messaging apps. ChessDesk brings those day-to-day records together without trying to replace accounting or payment platforms.
An independent coach may manage roughly 1–20 students, a few schools, or a mixture of both. When client details, schedules, payment records, and expenses live in separate tools, the same information gets entered more than once and the overall state of the business is harder to see.
ChessDesk focuses on that operational gap while staying intentionally small. It is not an accounting replacement, payment gateway, parent portal, or school portal; it is a fast workspace for the coach.
Solution
The Solution
The MVP is organized around the coach’s real sequence of work: schedule a session, coach it, mark it complete, communicate with the client, invoice one or more sessions, and record an external payment.
The FastAPI backend uses SQLAlchemy persistence and a checked-in OpenAPI contract. A Next.js frontend consumes the API through service modules, while SQLite supports local development and PostgreSQL remains available for a larger deployment.
Stack
Tech Stack
Decisions
Technical Decisions
Keep the API contract in the repository
The checked-in OpenAPI document gives the frontend and backend a shared boundary. It makes resource names, authentication behavior, and response shapes reviewable before a consumer has to discover them by trial and error.
Support cookie and bearer authentication
The backend accepts the HttpOnly session cookie used by the browser and bearer credentials for API clients and tests. That keeps the normal web experience secure while leaving the service straightforward to exercise outside a browser.
Separate operational areas into routers and services
Clients, sessions, invoices, expenses, and dashboard data have different responsibilities. Keeping those boundaries visible in the backend makes it easier to reason about permissions and future changes than putting every workflow into one large route module.
Use SQLite locally and keep PostgreSQL available
SQLite makes the project easy to run and test without extra infrastructure. PostgreSQL remains supported for environments that need a server database, which keeps local setup fast without closing off a production-oriented path.
Challenges
Challenges
Keeping frontend and backend behavior aligned
The frontend depends on several related service modules, so a small contract mismatch can show up as a broken dashboard, schedule, or form. Keeping the API document, service code, and backend tests together makes those mismatches easier to locate.
Representing different client workflows
The repository distinguishes individual students from school clients. That is a small but important domain decision: the forms and records need to reflect how a coach actually works with each type instead of forcing both into an overly generic client shape.
Making authentication testable
Authentication has to work through the browser cookie path and through direct API requests. The backend tests cover signup, login, protected requests, and duplicate-account behavior so the security boundary is exercised without relying only on the UI.
Lessons
What I Learned
A small product benefits from explicit domain boundaries just as much as a large one.
A checked-in API contract is useful documentation and a practical coordination tool.
Local defaults should make the first run easy without hiding the path to a stronger deployment database.
Authentication behavior is worth testing through every supported client path.
Status
Current Status
building
ChessDesk is actively in development. The repository contains the current implementation, tests, and setup path; there is no public demo URL attached yet.
Architecture
System Design
ChessDesk — current repository shape
FastAPI backend
Test surface