Pay First, Then Pick a Time

There's a quiet leak in every "book a call with me" setup: people book the time and never pay. You end up chasing an invoice for a slot that's already on your calendar, or worse, sitting on a no-show you can't charge for.

I had four paid session offers for Home Studio Mastery, a quick mobile-studio check at $99, all the way up to a $699 multi-session custom build-out, and the "system" behind them was four Google Calendar appointment links. Pick a time, show up, we'll sort out money later. That's backwards.

So I flipped it: pay first, then pick a time. This is the story of building that, and the parts that surprised me.

---

The flow is simple from the outside. You choose a session, you check out with Stripe, and only then do you land on a scheduler to pick your slot. The moment you confirm, a Zoom meeting gets created, a Google Calendar invite lands in your inbox, and the booking is logged. No back-and-forth, no "let me send you a link," no unpaid slots.

The interesting part is what makes that safe.

---

The first thing I learned is that the booking link is the whole security model, and it can't live in the browser. My instinct was to reveal the scheduling link after payment. But if that link ships to the page, anyone can read it out of the source and book for free. The paywall leaks instantly.

So the link never touches the client. The site only shows you a time slot, and the server checks your payment with Stripe before it will create the booking. The thing you're "buying" is never something you can grab early.

---

The second surprise was the multi-session package. The $699 tier is three calls, not one. I didn't want a client to pay three times, and I didn't want to manually email them links between sessions.

The answer was a pass: pay once, and you've got three bookings to spend. Book them all in one sitting if you want, or save a private link and come back later, no second charge. The system just counts how many you've used and stops you at three. I added one guard there too: the link is tied to the email you paid with, so a forwarded link can't be spent by someone else.

---

The lesson that paid off the most, though, was building the whole thing mock-safe. Every external piece, Stripe, Zoom, Google Calendar, the database, runs in a clearly-labelled fake mode when its credentials aren't set. That meant I could build and click through the entire flow locally, with zero accounts wired up, and only flip on the real keys at the very end.

It sounds like a small thing. It's not. It's the difference between "I think this works" and watching the actual screens, the actual error states, the actual confirmation page, before a single real dollar or calendar event is involved.

---

The last mile was the unglamorous stuff that makes it a business and not a demo: an admin view to see every booking and every multi-session pass at a glance, a dashboard that counts what's upcoming, and a runbook so future-me (or a teammate) can wire the live credentials without reverse-engineering anything.

---

What started as four calendar links is now a thing that takes money, books itself, shows up on Zoom, and keeps its own books. The takeaways I'm keeping: gate on the server, never the page; model "pay once, use many" as a first-class idea; and make every integration fakeable so you can see the product long before it's live.

If you want a studio that lets you show up and just press record, book a session, and yes, you'll pick your time right after you pay.