Drum Lesson Studio Site

At a glance

• Outcome: A guardian requests a lesson with real availability; the instructor reviews the fit, proposes a time, and controls every recurring placement. The instructor’s day is a single Today page on a phone, showing each lesson, the authorized guardian’s contact, and any warning about verification or payment.
• Status: In development. The domain system is well past a landing page, with recurrence, conflicts and lesson value built and tested. The public site is one page: the request form. The pages that would sell the studio come last, on purpose.
• Role: Solo, under contract through my LLC.
• Stack & libraries: Django and PostgreSQL, server-rendered, deployed on Dokku. PostgreSQL is load-bearing rather than incidental, because the rule against double-booking is enforced by the database itself. Payments will be provider-hosted and the client owns that account; the integration isn’t built yet. What stays unpublished is the client’s business: the name, the prices, the address, and anything about a student.
• Limitations: No payment path exists at all; the state machine for it is written and provider-neutral, with no endpoint behind it. One public page. And a caveat worth flagging for anyone reading the tests: the conflict tests skip silently on SQLite, so the suite can pass while proving nothing about the invariant the whole design depends on.

The vocabulary came first

The decision the rest of the system falls out of is a 36-term glossary, where each entry carries a list of words not to use for it. “Booking” is banned from five separate entries.

That sounds like fussiness until you see what it prevents. A guardian submits an Inquiry, which creates neither a reservation nor an enrollment. The confirmation email tells the family so in writing: this is a request, not an appointment or enrollment. The studio calendar is never published, and no permanent slot is ever self-served.

If the word had stayed “booking,” the product would have drifted into a self-service widget by accident, because that’s what the word means to everyone who reads it.

It’s also the one thing here another engineer could lift wholesale for their own project.

The hard part isn’t showing availability

The studio calendar is deliberately never published. The hard part is that five different kinds of lesson can all claim the same instructor and the same room, and two of them must never land on the same half hour.

That rule lives in the database, as a constraint over each lesson’s time range, one for the instructor and one for the room. It isn’t an availability check in application code, so two requests arriving at the same instant can’t both read a free slot and both take it.

The test proving it spawns two real threads through a barrier so they collide in the same second, and asserts that exactly one wins and one is rejected, across all five kinds of lesson the studio schedules.

Three records, so nothing gets overwritten

An Enrollment is the ongoing teaching agreement, not a row that gets edited every week. Date-bounded RecurrenceVersions generate individual LessonOccurrences.

So moving one lesson supersedes that occurrence and leaves a link back to the original. Moving the rest of a series closes the current version on a date and opens a successor. Nothing that already happened gets overwritten to make the new schedule true.

Who caused the missed lesson decides what it’s worth

This is the invented noun: the entitlement, and its kind is the whole point.

A cancelled lesson never just decrements a number. The system writes an append-only ledger entry, which the model refuses to let anyone edit or delete, and creates a named entitlement for the value that moved. The kind depends on who caused the miss, and that’s what decides whether unredeemed value eventually becomes money or simply evaporates.

A test asserts the exact ordered sequence of ledger kinds that a closure, an instructor cancellation, an expiry, and a redemption leave behind. So a family asking why they’re owed a lesson gets an answer with a trail, instead of a number someone adjusted.

How it started

It started as ten standalone landing-page prototypes, built to compare tone and messaging side by side rather than guess at one design: a kinetic kids-and-parents feel, a polished private-studio look, and a world-rhythm angle tying drumming to math, language, and culture. Narrowing those down settled the voice before any of the real machinery got built.

What’s next

The studio opening is the real test. Until a stranger requests a lesson and pays without help, the interesting claims about this project are unproven, so that’s how the status reads.