What it is and who it is for
This is the website for my own piano and voice teaching studio, Ridgley School of Music and Theatre. Families use it to request lessons and see what they owe; students use it for assignments and practice material; I use it to run the studio — approvals, attendance, materials, and money — from one place.
My role
I am the client, the product director, and the tester on this build. The business rules in the software are my studio's actual rules, written down by me: pricing, the 24-hour reschedule cutoff, when an overdue balance blocks a new booking, and what a family sees. I specified the system, oversaw AI-assisted implementation, reviewed screenshot rounds at phone and desktop sizes, and decided what was good enough. The same rule as the rest of this portfolio applies: a page is finished when I call it usable, polished, and finished — not when a checklist turns green.
The problem, and why it was not trivial
A one-teacher studio still has real operations: lesson requests, a schedule that changes with theatre work, siblings booked back to back, charges that must never double-post, and children whose videos must stay private to their own family. Off-the-shelf tools handle pieces of this and none of it the way my studio runs. The moment the site touches money and minors' material, "mostly right" stops being acceptable: balances are kept in integer cents, charges are tied to attendance, and every file access is checked against family ownership on the server.
Key decisions and trade-offs
Bookings are requests, never instant confirmations, because my availability changes with production schedules; I approve or decline each one, and the system rechecks availability and overdue eligibility at approval. Money is kept as an itemized, per-family ledger that is never edited after the fact — corrections are new entries, so history stays explainable. Teaching materials stay in Google Drive and the site stores only references to them, rather than copying files into a second system I would have to secure.
The site was also built to be agent-manageable by API from the start: an AI assistant can be given a narrowly scoped credential — scheduling only, for example — with every action attributed in an audit log, instead of being handed my password. What was rejected: live card charges in the first version. Card payment is wired for test mode only and the software refuses live keys until the studio is ready to turn it on properly.
Challenges and how they were handled
The hardest rules were the boundary cases a real studio hits: a reschedule inside the cutoff, a first late change that should be waived, a charge that must reverse without deleting history, a retry that must not create a second charge. These are covered by automated tests written against the exact thresholds — the precise 24-hour line, the exact overdue amount where booking blocks. Every page also went through screenshot review at phone and desktop width before it was called done, the same loop this portfolio uses.
Results
Built and working today, checked by automated tests, a type check, a production build, and a full HTTP smoke run against demo accounts: public studio pages, a family portal and student view, lesson requests with approval, attendance that posts charges, per-family balances, private progress-video uploads, Drive-based materials, and interactive practice trainers that render real musical notation for younger students.
Stated just as plainly, what is not true yet: the site is not publicly launched and has no public deployment or domain yet, no live payment has ever been taken through it, email runs in a preview mode that sends nothing until a provider is configured, and final acceptance — mine, as the studio owner — is still open while the design rounds finish. It is in very early development, newer even than BKeeping.
What I would do differently
I would not get too attached to the existing design, to leave more room for iteration.