TwoMore Product Spec Sheet

Status: Active Last reviewed: 2026-06-28

This spec sheet is the compact product contract for TwoMore. It defines what the product is, who it serves, what is in scope, how success is measured, and how the roadmap should be interpreted.

Product Definition

TwoMore is a Korean amateur-tennis club operating system.

It helps clubs and pickup hosts coordinate people, courts, sessions, RSVPs, payments, attendance, match flow, trust, records, and sharing without spreading the work across KakaoTalk chats, spreadsheets, bank transfers, and manual scoreboards.

Product Promise

For players: find the right match, know where to go, pay or confirm cleanly, track progress, and build a trusted tennis identity.

For organizers: run the club week without chasing headcount, payments, attendance, lineups, and repeated questions across multiple tools.

Strategic Position

TwoMore should win by being tennis-specific and Korea-specific:

• Tennis-specific: rotations, match board, scorecard, ratings, records, trust, attendance, court/weather context, guest/pickup flow.
• Korea-specific: Kakao-first auth/share habits, Korean legal/privacy posture, local club terminology, 총무 workflows, transfer/manual-payment reality, and public-court context.
• Club-first: start with amateur club operations before facility booking, coaching, brand, or multi-sport expansion.

Evidence Floor

Evidence	Product implication
Current Project State shows the app already has clubs, sessions, RSVPs, scores, records, trust, DM, manual payments, mock checkout, weather/TMI, and production guardrails.	The next roadmap should harden and sequence, not restart feature discovery.
App Functionality Map maps the current tabs, supporting surfaces, backend adapters, ports, and edge functions.	Product claims should stay attached to source-grounded app behavior.
Market & Revenue Research compares Korean tennis apps, generic group tools, global racquet SaaS, and team-management products.	Revenue work should start with organizer operations and payment trust before broad marketplace bets.
Production Readiness and External Blockers show launch is mainly blocked by legal/platform/vendor gates.	Track external gates in parallel, but run launch readiness as the final pre-launch acceptance gate after club growth, organizer operations, and polish evidence.
MCST 2025 National Sports Participation Survey is the freshest government survey for Korea recreational sports participation.	Treat this as a real recreational sports market, but optimize for participation friction and facility access.
MCST English summary reports high public-facility use, rising sports spending, and time/accessibility constraints.	Prioritize scheduling, venue clarity, reminders, and low-friction coordination.
Kakao IR presents KakaoTalk as Korea's dominant messaging layer with very broad domestic reach.	Integrate with Kakao habits; do not try to replace Kakao social behavior immediately.
CourtReserve and Playtomic show racquet platforms monetize booking, payments, memberships, events, leagues, lessons, and player experience.	TwoMore's later revenue paths are credible, but require club/venue supply and payments first.
TeamSnap and Spond validate team operations around schedules, RSVP, messaging, and payments.	The general workflow is proven; TwoMore's differentiation must be tennis depth and Korean club context.

Primary Personas

Persona	Problem	TwoMore must provide
총무 / club admin	Too much operational work: session setup, RSVPs, fees, attendance, rankings, reminders, member issues	A reliable weekly operating cockpit
Regular member	Wants predictable play, clear rules, fair lineups, progress, and fewer scattered messages	Home feed, sessions, RSVP/payment state, records, trust identity
Pickup host	Wants to create a paid/free session and approve the right guests without becoming a club admin	Pickup creation, guest applications, host dashboard, preview/share path
Guest/player prospect	Wants to discover a club/session and know if they fit before joining	Club/session previews, skill/trust context, apply/join flow
Venue/operator	Wants utilization and booking flow, but may not be ready for full SaaS	Venue data, booking handoff, later direct booking/operator tools
Coach/brand partner	Wants qualified leads or campaigns after player intent is proven	Later marketplace experiments tied to player stats and club trust

Primary Navigation Contract

TwoMore has five visible tabs. Club-first does not mean every club feature moves to the first tab.

Tab	Product job
홈	Attention router for what matters now: live play, today's schedule, weekly/monthly context, unresolved user obligations, and role-gated admin exceptions.
클럽	Club identity and operations: joined clubs, discovery, member/admin role context, club health, and the club admin cockpit.
경기	Session and pickup execution: find play, RSVP/apply, manage upcoming sessions, and handle session-specific host actions.
기록	Competitive identity, progress, history, leaderboards, and shareable proof of play.
프로필	Account identity, settings, privacy, safety, friends, achievements, and legal/account controls.

Admin work belongs primarily in 클럽 and club detail. 홈 may surface urgent admin exceptions for officials, but it must not become the full admin console.

Core Workflows

Launch-critical workflows:

1. Create account with production social auth.
2. Complete onboarding and land in a useful home state.
3. Create or join a club.
4. Discover or receive a shared club/session/pickup.
5. RSVP/apply/waitlist.
6. Host or administer a session.
7. Track participation-fee/payment state.
8. Run match board / scorecard.
9. Record attendance/no-show/payment exceptions.
10. View records, ranking, trust, and profile.
11. Message/report/block where needed.
12. Delete/export/consent-manage account data.

Post-launch workflows:

1. Production PortOne payment confirmation.
2. Dues automation and subscription pricing pilots.
3. Venue/court booking handoff.
4. League/inter-club play.
5. Coaching and brand experiments.

MVP v1.0 Scope

v1.0 is not "every roadmap feature." v1.0 is the smallest legally safe public app that proves the club operating loop.

Must be true:

• Public signup is legally safe.
• Production Kakao auth works.
• Store builds/install paths are proven.
• First production OTA smoke is documented.
• Dev-only surfaces are inaccessible to normal production users.
• New user can join/create/find a club or pickup.
• Session RSVP/waitlist/payment states are understandable.
• Organizer can see and resolve operational exceptions.
• Records/rating/trust/profile surfaces make the app worth returning to.
• Push/share/deep-link paths do not strand users.

Not required for v1.0:

• Real PortOne money movement.
• Paid subscriptions.
• Direct venue booking.
• Coach marketplace.
• Brand marketplace.
• Multi-sport.
• International expansion.

Capability Map

Capability	Current state	Spec decision
Clubs / roles / invites / discovery	Built	Harden activation and admin cockpit
Sessions / RSVP / waitlist / scorecard	Built	Keep as core loop
Pickups / guest applications	Built	Keep as growth and supply loop
Ratings / records / leaderboards	Built	Keep one app-facing player identity; add formats only when demanded
Trust / attendance / reports	Built	Prioritize organizer visibility and critical tests
Dues / manual participation fees	Built	Harden before real payment rail
PortOne rail	Scaffolded	Gate on owner/vendor setup and test-channel proof
Kakao auth/share	Auth scaffolded; share composers built	Complete production credentials and Kakao-native sharing
DM / media / safety	Built	Keep lightweight; avoid rebuilding Kakao group chat
Venue/court data	Built directory + venue surfaces	Improve data and handoff before booking marketplace
Subscriptions	Spec/entity shells	Pilot only after retained clubs and payment trust
Coaching/brand	Planned	Held until user intent and payment rails exist
Multi-sport/international	Designed in places, not built	Held until Korea tennis traction

Success Metrics

Product metrics:

• Activation: account -> onboarding complete -> club join/create or RSVP/apply.
• Club activation: club created -> session created -> at least one non-admin RSVP.
• Weekly retained play loop: user returns for session, score, attendance, DM, or records.
• Organizer efficiency: unpaid holds, submitted transfers, guest apps, attendance exceptions, and reports are resolved in app.
• Growth: share link -> app open -> join/apply/RSVP.
• Payment trust: no duplicate confirmations, missing holds, or unresolved paid states.
• Safety: reports/blocks/consent/delete/export paths remain functional.

Engineering metrics:

• yarn docs:check, yarn lint:agents-md, and yarn check stay green.
• Any release candidate also has device-level smoke evidence for changed workflows.
• Stale claims are kept out of active docs.
• New work follows the active roadmap slice contract.

Product Constraints

• Do not add a second app-facing rating metric without strong product evidence.
• Do not reintroduce persistent realtime as the default freshness mechanism.
• Do not charge real users until payment, refund/support, legal, and audit flows are clear.
• Do not turn DM into a generic KakaoTalk replacement.
• Do not build direct venue booking before validating venue supply and operator workflow.
• Do not generalize to multi-sport before Korea tennis retention and revenue are proven.

Roadmap Linkage

The active roadmap is TwoMore Roadmap. Concrete roadmap slices live in Roadmap Implementation Plan.

Use the roadmap for sequencing and acceptance gates, the implementation plan for slice-level build scope, and this spec sheet for product definition and scope boundaries. When they conflict, update the affected docs in the same docs-only slice and run:

yarn docs:generate
yarn docs:check