Turning 'are you free?' into a paid booking, automatically

Owner-operated gyms, pilates and yoga studios, small group-class spaces: anywhere the owner is also the coach, the receptionist, and the one chasing deposits. Built for a single location first, with room to add coaches later.

I built the smallest thing that actually changes her day: a booking flow that holds nothing until money moves.

• Class schedule with capacity per slot, editable from the owner's phone
• PromptPay deposit collected at booking; the slot is only held once it clears
• Automatic LINE reminder the day before, with a one-tap way to cancel inside the window
• A simple bilingual booking page that works on the phones members actually use
• An owner view of who is coming, who paid, and who cancelled

• The full codebase, in the gym's own repository
• Hosting, domain, and the PromptPay and LINE accounts set up in the gym's name
• A plain-language runbook: how to add a class, refund a deposit, change reminder timing
• A short handover call, recorded, so the owner can rewatch instead of re-asking

1. Map

   A short first week

   I sat with the owner and traced one real booking, from the first LINE message to the no-show, to find where money should change hands.

   A one-page scope: the exact flow, the deposit rule, and what we deliberately leave out.

2. Shape

   Inside the same fortnight

   I designed the booking screen around the smallest number of taps a tired member would tolerate on a phone.

   Clickable screens the owner approved before any backend was built.

3. Make

   The build weeks

   I built the booking, the deposit, and the reminder as one tested path, not three features bolted together.

   A working booking on a real test number, deposits landing in a real PromptPay account.

4. Prove

   A focused week

   We ran the gym's own members through it for a week and watched where anyone hesitated.

   A short list of fixes from real use, all closed before launch.

5. Hand-off

   The final days

   I moved every account into the gym's name and walked the owner through running it without me.

   The keys: code, hosting, accounts, and a runbook in plain Thai and English.

• Quoted per project after a short scope call. You see the full number before any money moves.
• Payment is phased against the build: a deposit to start, a milestone at a working booking, the balance at hand-off.
• Fixed scope, fixed price. If you want more later, it is a new, separately-quoted scope, never a surprise.

• The gym has, or is willing to open, a PromptPay-capable account in its own name.
• Members book on phones, mostly through LINE; we design for that first.
• One location and one owner-approver for decisions during the build.

• No point-of-sale or in-person card terminal; this is online deposits, not the front desk till.
• No native app on the stores; a fast web booking covers the real need without app-store overhead.
• No multi-branch franchise console in the first scope; it is a clean place to grow into, not day one.

The deposit is the product, not a feature

The owner first asked for a calendar. The real problem was no-shows, so the one decision that mattered was refusing to hold any slot until a PromptPay deposit cleared. Everything else, the schedule, the reminders, the owner view, exists to support that single rule. Selling the rule, not the calendar, is what changed her week.

• A clean, fast public schedule page that Google can read, so 'pilates near me' lands on the booking, not a competitor.
• Bilingual page structure so Thai and English searches both find the right class.

The result

The owner stopped negotiating slots in chat and started waking up to deposits already paid. No-shows fell sharply once deposits were in, because a paid deposit is a kept appointment.

What it proves

That a booking app earns its keep when it changes behavior, not when it adds buttons. Hold nothing until commitment, and the no-show problem mostly solves itself.