Source document · Planning/SB_Relaxing_Club_Project_SRS.md

SB Relaxing Club Project SRS

Version: 2.0
Status: Implementation baseline
Last updated: 25 September 2026
Product: SB Relaxing Club marketplace and community platform

1. Purpose and authority

This document is the product-level Software Requirements Specification for SB Relaxing Club. It defines the user-facing product, roles, core workflows, business rules, and quality expectations. The implementation-specific specifications are the Go API SRS and the Kotlin Multiplatform Mobile SRS. In case of conflict, this product SRS governs product behavior; implementation documents may refine technical details but must not silently change product behavior.

The product is a multi-sided service marketplace combined with a community and entertainment app. Customers discover and book local services, providers operate listings and fulfil orders, members use social and lifestyle features, and platform staff administer operations and financial reporting.

2. Product goals

1. Enable customers and guests to discover providers and book local services.
2. Give providers tools to publish businesses, receive and fulfil orders, communicate with customers, and track sales.
3. Provide community features for Moments, short videos, meetings/livestreams, dating/friend-finding, and curated lifestyle content.
4. Give administrators centralized control of users, marketplace content, moderation, announcements, and reporting.
5. Deliver the mobile experience on iOS and Android using Kotlin Multiplatform and provide a separate Next.js/shadcn admin web application.
6. Make the Go API the authoritative source for business rules, authorization, workflow transitions, and persistent data.

3. Product boundaries and platforms

3.1 Applications

• Mobile app: Kotlin Multiplatform for Android and iOS. Shared Kotlin code owns domain models, API access, validation, state, and reusable presentation logic. Native capabilities are integrated through platform-specific implementations. Compose Multiplatform may be used for shared UI; platform-specific UI is acceptable where it materially improves a system-critical interaction.
• Backend: Go HTTP API, with real-time channels where required, durable database, and object storage. All clients use this API; clients do not connect directly to the database.
• Admin webapp: Next.js with shadcn/ui for administration, moderation, accountant reporting, and operational management.
• Media delivery: uploaded media is stored in object storage and delivered through controlled URLs/CDN as appropriate.

3.2 Product scope

In scope: authentication, service discovery, provider profiles and listings, ordering, manual QR payment workflows, optional card processing, order tracking, provider operations, chat, push notifications, Moments, short-form videos, meetings, livestreams, lifestyle/dating content, entertainment links, localization, themes, administration, moderation, and accountant reports.

Out of scope unless separately agreed: automated WeChat Pay/Alipay gateway capture, creator monetization, recommendation algorithms, group calling beyond the specified meeting model, and additional languages beyond the six listed below.

4. Roles and access intent

The backend must enforce permissions on every request. Hiding a control in an app is not authorization.

5. Navigation and information architecture

The primary mobile navigation is Home, Videos, Chat, Lifestyle, and Orders. Search, Profile, Settings, Provider Dashboard, notifications, and individual detail screens are secondary destinations reachable from these areas and deep links. Provider-only navigation is shown only to eligible accounts. Admin and accountant workflows belong in the web application.

6. Marketplace requirements

6.1 Discovery

Home displays a greeting, rotating full-width hero content, service-category grid, featured business listings, and an Add Your Business entry point. Search supports live filtering across service names, listing names/descriptions, categories, and provider names. Discovery cards expose the provider/business identity, service description, menu items, prices, and relevant availability/contact details.

Initial categories include Haircut, Food, PlayStation/FC26, Printing, Cleaning, Photoshoot, Massage, Hairwash, Packing & Moving, Shoes Cleaning, Kuaidi Pickup, Hair Braiding, and Transport & Delivery. Admins can maintain catalog entries and categories.

6.2 Provider registration and listings

Any logged-in member may apply/register as a provider. The profile captures display name, phone, image, biography, categories/services, service area, contact/payment QR assets, and up to ten portfolio media items. A profile may support a second associated person/contact where enabled.

Providers can create multiple business listings containing name, category, description, cover image, menu items and prices, and WeChat/Alipay payment QR images. Owners can edit or deactivate their own listings. Admins can review, deactivate, and feature listings.

Business publication prices documented for the current product are:

Publication fees are monthly. The system reminds the owner three days before and on the due date. If payment is not confirmed, affected listings may be suspended; they can be restored after confirmation. Static QR payment is manually confirmed. The exact grace period and suspension timing require product-owner confirmation before launch.

7. Ordering and payment requirements

Customers may order platform services or business menu items, selecting multiple items in one order when supported. The form captures contact name, phone, requested date/time, service address/room, notes, selected items, and category-specific attachments. Kuaidi Pickup supports package screenshots/details. Printing supports document uploads. A WeChat QR attachment is optional.

Payment methods are determined by service/listing configuration:

• WeChat Pay and Alipay: show the provider’s QR image and allow the customer to indicate payment was submitted. This is not proof of payment. Provider/admin confirmation is a separate state transition.
• Stripe card payment: optional, where enabled and configured.

Successful order submission creates a pending order and notifies the assigned provider. Customers receive a confirmation summary and can see status/history. Providers can confirm, progress, complete, or cancel orders according to permitted transitions. Completion creates the completed-order record and sale entry, updates all authorized views, and notifies the customer.

Order lifecycle and payment lifecycle are distinct. Minimum order states: pending, confirmed, in_progress, completed, cancelled. Minimum payment states: unpaid, payment_submitted, payment_confirmed, payment_rejected, and refunded if refunds are supported. Customers may cancel according to the documented policy; completed/cancelled orders can be hidden from the customer’s own list without erasing financial/admin records.

8. Provider operations and reporting

Provider Dashboard shows action-required orders, active orders, completed orders, chat conversations, sales summary, and manual/off-platform order entry. Manual orders must be identified as off-platform and auditable. A sale is generated when a provider/admin completes a valid order or records a manual sale. Corrections must preserve an audit trail.

Accountants see only assigned services and related completed orders/sales, with day/week/month summaries and export/report capability. Admins see platform-wide operational and financial records.

9. Communication and notifications

Customer-provider one-to-one chat supports text, image, and video attachments, unread counts, read state, and near-real-time delivery. Push notifications are required for new orders to providers, order status changes to customers, new chat messages, and admin announcements. Tapping a push opens the corresponding authorized destination. APNs and FCM are used for iOS and Android respectively.

10. Community and lifestyle

• Moments: member-authored captions with one or more images/videos and optional location; likes and comments; China Place subtype when enabled.
• Short videos: vertical autoplay feed; authorized uploads; title, description, thumbnail; likes, comments, share action, and view count.
• Meetings: members create named rooms, optionally protected by passcode; participants join audio/video through WebRTC; host can end the room; participant membership is tracked.
• Livestreams: eligible providers stream to viewers; viewers watch and interact with likes/comments/viewer count; recording retention is optional.
• Dating/friend-finder: opt-in profiles with display name, age, gender, country, looking-for, biography, interests, images/media, and contact settings.
• Curated lifestyle content: music, comics, games, books/stories, and entertainment links managed by authorized staff. Audio playback may continue in a mini-player if enabled.
• Lifestyle consent: a user opts into relevant sections before accessing gated lifestyle features.

User-generated content needs report, block, moderation status, removal, and user suspension capabilities. Detailed retention and moderation response policy must be set before public launch.

11. Administration

The Next.js/shadcn admin app supports dashboard summaries; users and roles; providers; listings and featuring; services/categories; orders; completed orders and sales; accountant assignments/reports; Moments/video/comment moderation; lifestyle and entertainment content; announcements; and operational audit history. Tables must support search, filtering, pagination, and appropriate bulk actions. Destructive or financially significant actions require confirmation and audit logging.

12. UX and visual direction from the reference video

The reference video is a 288×640 portrait recording of the existing mobile experience. It is the visual reference for marketplace, booking, order history, profile, and provider dashboard screens. Preserve its dark-first charcoal/navy surfaces, turquoise primary actions and active states, orange/yellow provider accents, rounded bordered cards, compact status pills, circular category icons, readable high-contrast typography, and bottom navigation. Use large rounded form fields and full-width bottom actions. Date selection should feel native. Keep primary actions reachable when the keyboard or modal is visible.

The reference is behavioral and visual guidance, not a complete screen specification for every social feature. Extend the same color, type, spacing, card, button, and navigation system consistently to screens not shown in the recording. Support light mode, system font scaling, accessibility contrast, and right-to-left Arabic layout.

13. Localization and account settings

Supported languages: English, Chinese (中文), French, Arabic, Kiswahili, and Spanish. All user-visible strings are localized. Dates, times, and currency use locale-aware formatting. Users can change language/theme, edit profile, manage notification preferences, sign out, and permanently delete their account.

14. Non-functional requirements

• HTTPS/TLS for network communication and secure credential storage on device.
• Server-side authorization and validation for every protected operation.
• Graceful retry/error states for network failure; cached previously loaded services, own orders, and recent chats where feasible.
• Upload progress and retry for media and documents.
• Target Home interactivity within 3 seconds on a mid-range device over 4G; cached search response within 300 ms; smooth media feed scrolling.
• Accessibility: contrast, target sizes, system font scaling, screen-reader labels, and Arabic RTL.
• Reliability: idempotent order submission and safe retry for financial/workflow mutations.
• Maintainability: feature-oriented modules; centralized role, validation, and workflow rules.

15. Acceptance and release baseline

Release acceptance requires end-to-end verification of guest/member/provider/accountant/admin permissions; order, payment-confirmation, completion, sale, and notification workflows; upload flows; localization including Arabic RTL; account deletion; and push delivery on physical iOS and Android devices. Store privacy declarations, terms, privacy policy, and user-generated-content controls must be ready for release.

16. Open product decisions

The following must be resolved before the affected feature is finalized:

1. Guest booking identity/contact verification and guest access to later order tracking.
2. Exact provider order cancellation/refund rules and publishing-subscription grace period.
3. Whether Stripe is in launch scope and which service categories can use it.
4. Whether live streams are provider-only or available to all eligible members; the overview says providers only while the mobile SRS also describes eligible users.
5. Content retention, reporting response times, block behavior, and livestream moderation policy.
6. Whether featured placement is fixed-duration or renewed with each monthly publishing fee.
7. Final rules for a shared/two-person provider profile and ownership transfer.