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.

The build is the smallest system that actually changes an owner's day: a booking 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 sit with the owner and trace 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 design the booking screen around the smallest number of taps a tired member will tolerate on a phone.

   Clickable screens the owner approves before any backend is built.

3. Make

   The build weeks

   I build 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 run one real week of bookings through the system in parallel with the old chat and watch where members or the owner hesitate.

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

5. Hand-off

   The final days

   I move every account into the gym's name and walk 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

Owners usually ask for a calendar. The real problem is no-shows, so the one decision that matters is refusing to hold any slot until a PromptPay deposit clears. Everything else, the schedule, the reminders, the owner view, exists to support that single rule. Selling the rule, not the calendar, is what changes an owner's 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

Built so that the owner stops negotiating slots in chat and starts the day with deposits already paid, because a paid deposit is a kept appointment. The interactive demo at the top of this page walks that exact flow; a real build starts from it and gets your gym's own design and brand.

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.