PRD Index: reserve (studio booking & management)
Date: 2026-11-11 · Source: Rezerv for Business recon (../replica/recon.md, ../replica/features.csv, 723 screenshots in ../replica/screens/)
Each PRD lives in its own folder and contains a README.md (the full PRD) and an evidence/ folder (key screenshots plus an evidence.md that maps requirements to the original screens).
Core loop
A studio puts classes on the schedule, sells credit packages / memberships, then customers book & pay online and check in when they arrive.
Every priority below is ranked by one question: what gets this loop running end to end for one real studio the fastest?
PRD list
| PRD | Module | Tier | Size | FR (must/should/could) | Depends on |
|---|---|---|---|---|---|
| 01 | Workspace & foundation: business, locations, rooms, staff, roles, shifts, admin shell | P0 | L | 34 (20/10/4) | auth (already exists) |
| 02 | Classes: catalog, categories, wizard, settings, bookings | P0 | L | 29 (19/8/2) | 01 |
| 03 | Schedule & calendar: recurring sessions, publish, time blocks | P0 | L | 26 (17/8/1) | 01, 02 |
| 07 | Customers: list, detail, tags, notes, suspend | P0 (core) | L | 28 (16/10/2) | 01, auth |
| 06 | Pricing plans: packages, memberships, promos, pricing groups | P0 (core) | L | 25 (15/6/3) | 01, 02, 07 |
| 08 | Sales & payments: manual POS, transactions, tax, refunds | P0 (manual) | L | 28 (17/6/2) | 01, 06, 07 |
| 09 | Storefront & customer booking: timetable, signup, checkout, account | P0 | L | 43 (29/10/4) | 02, 03, 06, 07, 08 (appointment/course/builder parts follow 04, 05, 12) |
| 11 | Email notifications: 35 events, template editor, history | P1 (transactional subset in P0) | L | 28 (19/7/2) | 01–08 |
| 04 | Appointments: 1-on-1 services, staff + resources, recurring | P1 | L | 25 (16/7/2) | 01, 03, 06, 07, 08 |
| 10 | QR check-in & outlet access | P1 | M | 24 (7/12/5) | 01, 02–06 |
| 14 | Reports (31), KPIs, ratings & feedback | P1 | L | 27 (9/9/9) | 01–08 |
| 12 | Website builder: themes, pages, navigation, blog, FAQ, domain | P1 | L | 58 (36/15/6) | 01, 02, 04–06, 11 |
| 05 | Courses: multi-session programs, tickets, online/hybrid | P2 | L | 22 (12/8/2) | 01, 07, 08 |
| 13 | Marketing: campaigns, automation, referrals | P2 | L | 27 (11/10/6) | 07, 11, 15 |
| 15 | Integrations & embed widget, tracking pixel | P2 | M | 24 (7/12/5) | 01, 09, 11 |
Build order
Wave 1: sellable MVP (P0)
Build order: 01 → 02 → 03 → 07 → 06 → 08 (manual) → 09, plus 11 (transactional email only).
Why:
- 01 Foundation first. Every other entity hangs off the business, locations, rooms and staff. Auth (email OTP, Google, JWT) already exists in the codebase, so only roles/permissions and workspace data need adding.
- 02 Classes + 03 Schedule are the core product for yoga/fitness studios, the clearest segment in the recon (the demo account, the
/business/yogapage). Without a schedule there is nothing to book. - 07 Customers is needed before anyone can buy or book. The core version is enough: list, add, detail, suspend.
- 06 Pricing plans (credit packages + one-time memberships) are how a studio makes money. Recurring billing is deferred because it needs a payment gateway.
- 08 Manual sales (cash/transfer + proof of payment, tax, refund records) lets a studio sell without waiting on the payment gateway decision. This takes the biggest risk off the critical path.
- 09 Storefront closes the loop: customers see the timetable, sign up, book and buy packages. v1 uses one fixed template, not the website builder. Only PRD 09's FRs for classes and packages are in Wave 1; the FRs for booking appointments and courses ship with the PRD 04 and 05 waves.
- 11 transactional subset (booking confirmation, cancellation, purchase, OTP) is required because booking without an email confirmation feels broken.
internal/mailandinternal/templatealready exist; only templates need adding.
Wave 1 definition of done: one studio can create a location, classes and a schedule, sell packages manually or through the storefront, and customers receive a confirmation email after booking.
Wave 2: operations & retention (P1)
Order: 10 → 04 → 14 → 11 (full) → 12, plus 08 with an online payment gateway + recurring memberships.
- 10 Check-in goes first because it is small (size M) and immediately useful at the front desk. Its data also feeds attendance into reports.
- 04 Appointments opens a second segment (personal training, therapy, salons), but its availability engine (staff shifts × rooms × equipment × concurrency) is the hardest scheduling piece, so it is deliberately left out of the MVP.
- 14 Reports only become useful once there are real transactions and bookings. Start with sales, booking and customer reports; payroll comes later.
- 11 full (template editor, email themes, send/open history) and 12 Website builder (58 FRs, the largest module) add branding value but are not required for a studio to operate.
- Payment gateway + recurring billing land here once a gateway is chosen (see Decisions below).
Wave 3: growth (P2)
05 Courses, 13 Marketing, 15 Integrations & embed.
All three are valuable but serve secondary needs:
- 05 Courses: multi-week programs with an 8-step wizard, which even the original product limits to 2 courses on its lowest tier.
- 13 Marketing: campaigns, automation and referrals need a customer base and an email provider first.
- 15 Integrations with third parties (SMS, smart locks) go through official APIs only and depend on vendor decisions.
Decisions needed (blockers)
| # | Decision | Blocks | Needed by |
|---|---|---|---|
| 1 | Payment gateway (Xendit / Midtrans / Stripe / other) | online checkout in 09, recurring memberships in 06, gateway refunds in 08 | start of Wave 2 (Wave 1 runs on manual payments) |
| 2 | Launch country & currency, tax and rounding rules | 01, 08 | Wave 1 |
| 3 | Production email provider (open/delivery tracking, domain verification) | 11 full, 13 | Wave 2 |
| 4 | Customer identity: our auth (email OTP + Google) per studio, or one account across studios | 07, 09 | Wave 1 |
| 5 | Custom domains: automatic or manual DNS + SSL | 12 | Wave 2 |
| 6 | Pricing tiers & feature gating (everything marked "pricing tier: TBD") | all | before launch |
Out of scope
- The original product's shared cross-studio customer identity and shared customer app.
- Partner integrations as-is (ClassPass-style aggregators, Igloohome, their email provider). If needed, rebuilt through official APIs.
- A branded mobile app. That is a separate project.
- The original product's brand, copy, illustrations and template assets.
Recon gaps (guessed, not observed)
- Storefront payment page, customer account area, cancel flow and post-login mobile screens. Signup rejected
@example.comaddresses. A real mailbox is needed to close this gap. - Automation editor and its triggers, report columns and ratings. The demo account data was empty.
- Rule details: how late cancels/no-shows affect credits, the "lost member" rule, default staff notification events.
Assumptions are marked in each PRD (✱ or in the Open questions section).
Test data left in the demo account
Everything is prefixed "ZZ Test" (location, class + 2 sessions on 12–13 Nov, appointment, course, package, customer, cash transaction, shift). The full list is in ../replica/recon.md, section "Test data left in the demo account".