One way in
Open an issue. That’s the entire booking system.
It’s a form. Five fields, most of them optional, roughly ninety seconds — which is still less time than you’d spend deciding whether to book a paid mock and then not booking it.
Why a GitHub issue, in 2026
Because a calendar integration for a service with no confirmed users is a lovely way to spend a Saturday and learn nothing.
An issue costs me nothing to operate and answers the only live question: does anybody actually want this? If the answer is no, I’d rather find out from an empty issues tab than from a beautifully instrumented booking funnel with an empty issues tab.
The friction is real and it certainly filters people out. Consider it the first question of the session.
What happens next
- A handful of issues: I book sessions by hand, in the thread. Slow, unglamorous, works.
- More than a handful: an actual calendar appears on this page and I stop pretending this is a feature.
- People who fancy being the duck as well: the club gets a roster, you pick a duck, or two members pair up and cut me out of it entirely. That last one is the version I’m actually hoping for. Playing dumb on purpose is a skill worth having on both sides of the table, and it’s considerably easier to practise than being right.
There’s a question on the form about whether you’d sit on the other side for somebody else. Answering it honestly is more useful to me than answering it generously.
Ground rules
No fee. No score, no report card, no written feedback with a traffic-light grid. If you want a numerical assessment of your performance, the industry is extremely well supplied with people who’ll sell you one.
Issues are public, so keep your current employer out of it. “A large payments company” tells me everything I need to know.
No GitHub account?
You’ll need one to open an issue — free, takes a minute. Or just mention it next time we speak; word of mouth remains the most reliable protocol I’ve deployed.