TwoMore Roadmap

Status: Active Last reviewed: 2026-06-28

This is the current product and engineering roadmap for TwoMore. It supersedes the older phase list that treated several already-shipped capabilities as future work.

Use this with:

• Current Project State for generated repository facts.
• Current Documentation State for doc authority.
• Roadmap Implementation Plan for concrete slices, allowed surfaces, acceptance proof, and verification per track.
• R1 Activation Source Pack for the accepted current-state inventory behind the R1 club-growth implementation slices.
• Product Spec Sheet for product scope, personas, and success metrics.
• App Functionality Map for the current tab, feature, and backend capability map.
• Market & Revenue Research for competitor and monetization evidence.
• Sports Club Administration Opportunity Audit for the app-to-market improvement plan behind R2 Organizer Operations.
• Production Readiness and External Blockers Register for launch gates.

North Star

TwoMore is the operating layer for Korean amateur tennis clubs: organize members, sessions, match flow, payments, trust, records, and shareable growth in one mobile-first system.

The wedge is not "generic sports app" and not "court booking marketplace" first. The wedge is the high-frequency 총무 workflow that already happens across KakaoTalk, spreadsheets, bank transfers, and manual score/ranking conversations.

Market Thesis

The roadmap is grounded in these external signals:

• Korea's latest national sports participation survey is an annual, government-run survey of 9,000 residents aged 10+ and tracks participation, facilities, duration, and spending. The 2025 survey is the freshest source for the recreational-sports backdrop. Source: MCST 2025 National Sports Participation Survey.
• MCST's English summary of the 2025 results reports high public-facility usage, rising average monthly sports spend, and time/accessibility as recurring constraints. That supports a roadmap focused on reducing coordination friction rather than adding passive content. Source: MCST survey summary.
• KakaoTalk remains the default distribution layer for Korean social coordination: Kakao's IR materials present KakaoTalk as Korea's dominant messenger with roughly 48 million domestic monthly users in early 2024 and very high population penetration. TwoMore should use Kakao-native auth/share/notification paths instead of trying to replace Kakao social behavior on day one. Source: Kakao IR presentation.
• Racquet-sports platforms converge around bookings, payments, memberships, events, leagues, lessons, and mobile player experience. CourtReserve and Playtomic validate the direction, but their center of gravity is facility/platform operations. TwoMore's near-term advantage is club-community operations before facility marketplace scale. Sources: CourtReserve, CourtReserve feature summary, Playtomic, Playtomic Global Padel Report.
• Generic team-management products such as TeamSnap and Spond validate the bundle of scheduling, RSVP, communication, and payments. TwoMore should keep those primitives, but specialize them for tennis: rotations, scoring, ratings, trust, guest/pickup flows, court/weather context, and Korean club operations. Sources: TeamSnap, Spond.

Current Baseline

Built or scaffolded today:

• Mobile app, web shell, Supabase backend, RLS, edge functions, storage, OTA setup.
• Club creation, discovery, membership, roles, invites, guest applications, and pickups.
• Sessions, RSVP, waitlist, live scorecard, match board, participants, attendance, session payments, dues, club venues, court directory, weather/TMI, and notifications.
• Rating/records system, leaderboards, achievements, challenges, practice log, profile, friends, DM, reports, blocks, image messages, and share-card composers.
• Manual participation-fee flow and mock checkout. PortOne production rail is scaffolded but blocked on credentials, native adapter, and runtime validation.
• Production-readiness guardrails: docs gate, architecture tests, ESLint rules, PI schema lint, generated state docs, and active blocker register.

Known constraints:

• Public launch is blocked by external legal/platform steps, not by lack of core app surface.
• Production Kakao auth and real PortOne payments require owner/vendor setup.
• iOS launch requires Apple Developer credentials and first iOS preview/production builds.
• A green yarn check is a baseline, not device-level release proof.

Sequencing Principle

Sequence by proof, not aspiration:

1. Prove the club-growth loop with real or seeded clubs and device-level evidence.
2. Make club administration visible enough that admins can understand their weekly work from the app, not from memory or external spreadsheets.
3. Polish and optimize the core Home / Clubs / Activity / Records loop so the app is fast, understandable, and resilient enough for first public users.
4. Run launch readiness as the final pre-launch gate after R1-R3 are accepted.
5. Add real payments only after payment authority, ledgers, and smoke tests are reliable.
6. Expand into venue booking, leagues, coaching, and marketplace only when the core club loop creates enough retained supply and demand.

Roadmap Overview

Track	Status	Outcome	Why now
R1 Club Growth Loop	Active	New users can join/create clubs, find play, invite others, and return weekly	Drives adoption before monetization
R2 Organizer Operations	Active	총무 can run sessions, payments, attendance, member quality, and comms with less manual work	Core retention wedge — R2-0..R2-4 delivered, owner acceptance pending
R3 Product Polish & Optimization	Active	Core product surfaces are understandable, fast, accessible, and launchable	UX audit + Waves 1-5 + engineering soundness delivered; 0.7.0 install gates delivery
R4 Launch Readiness Final Gate	Final Gate	Public launch can happen without legal, auth, store, or production-safety blockers	Final stop before launch after R1-R3
R5 Real Payments & Subscriptions	Gated	Participation fees and dues can use PortOne; pricing gates are tested with pilot clubs	Revenue needs trust and legal rails
R6 Venue & Court Platform	Discovery	Court/venue data becomes operationally useful before direct booking	Marketplace needs venue supply
R7 Leagues & Inter-Club Play	Held	Structured competition, seasons, and club-vs-club events	Higher engagement after club base exists
R8 Coaching & Brand Marketplace	Held	Coaches, lessons, sponsored challenges, equipment, cosmetics	Requires retained players and transaction rails
R9 Expansion Platform	Held	Internationalization, multi-sport, white-label	Avoid premature generality

How To Build From This Roadmap

This roadmap is the product sequence and acceptance-gate map. Build execution lives in Roadmap Implementation Plan.

Default workflow:

1. Start with the first Planned slice in the active track.
2. Confirm the slice start condition and allowed surfaces.
3. Keep implementation inside the slice's blocked-scope boundaries.
4. Prove the slice with its acceptance proof and verification ladder.
5. Update the implementation-plan status and any product, blocker, or generated docs whose truth changed.

For 2026-06-28, R1-0 Activation source pack, R1-1 Intent-aware onboarding routing, and R1-2 Club discovery and creation first-session loop are accepted. The active implementation slice is R1-3 Share and deep-link activation. The first R1-3 source slice, canonical share-link helpers plus club invite-code prefill, is shipped to preview OTA group 3ea7b802-e498-4197-a081-0284f3f49c12. The second R1-3 source slice, bounded public receiver previews plus seeded web receiver smoke, is committed at ce6a23185a322c51c2d31f301b0a82fc96f82bba. Source commit de703f539076523f7884c79189e966862c730330 adds generated custom-scheme receiver smoke tooling. Source commit 111dbf77eb590b2ee6a49b0c70bffc3c2a5a342b adds mobile public-share receiver fallbacks for RLS-blocked /s and /m recipient links, preview OTA group e01fc19c-19a8-4012-8ec8-1555edad14d6 ships them, and hosted workflow 019f0c32-1afc-70c5-82d8-185df88e8ad4 passes generated Android custom-scheme proof for /p, /s, /lb, and /m. Source commit c9d81257205f29cf71707eb730d762aab65876d5 extends that generated proof to /join-club?code=<inviteCode>; hosted workflow 019f0c63-85bc-7f19-9d9b-d449ed548eb1 passes the updated flow against the same Android preview build, proving invite-code receiver prefill and submit without manual input. Source commit a667567887143fbc85bb801ffad46e187dd6b222 wires the canonical https://twomore.app share domain, native iOS/Android HTTP app-link config, credential-gated web association handlers, and yarn check:r1-app-links; source commit e6f60c2850dbff3dfc6a58a6642e0f1e6c3b240c adds the credentialed remote/live-domain proof command yarn check:r1-app-links:remote, which currently fails because the canonical .well-known paths redirect to www instead of serving this app's association JSON. Source commit 422037f28e815f17c179f54d2a033ac40bda3c60 adds the R1 Kakao template manifest, kakaoTemplate payload metadata on every R1 share-card composer, and yarn check:r1-kakao-share; static Kakao coverage is now guarded, while native KakaoTalk delivery remains blocked on template IDs, the native Kakao app key, a preview build, and device smoke. Source commit fb2fd1bd76835a6921f1623b8c9600da2b3f6796 wires the native Kakao Share adapter and fallback path, but no credentialed build or KakaoTalk rendering proof exists yet. Source commit 64ea165c7651226f4f9a316b7de581d1cc353a92 adds yarn check:r1-release-readiness:eas as the aggregate R1 release gate and yarn report:r1-release-readiness as the non-exiting handoff report. Continue from the Roadmap Implementation Plan and R1 Activation Source Pack.

R1 - Club Growth Loop

Goal: a new or invited player can get to useful play quickly, and a club can grow through shareable flows.

Field	Plan
Primary artifact	Activation and invitation loop
Implementation plan	R1 implementation slices
Bounded input	Existing club/pickup/share/onboarding routes, club_growth scenario, Kakao/domain setup
Acceptance proof	Seeded and device-level smoke shows club discovery, join/apply, session RSVP, and share/deep-link return path
Verification ladder	node scripts/run-scenario.mjs club_growth; hosted Maestro club-growth flow; yarn smoke:r1-share-receivers; yarn check:r1-app-links; yarn check:r1-kakao-share; yarn check:r1-release-readiness:eas; hosted R1-3 custom-scheme flow; production Kakao/app-link smoke
Blocked scope	Paid acquisition, paid ads, coach marketplace, international expansion
Deferral rule	If a growth idea does not improve activation, invite conversion, or first weekly session, park it

Work slices:

1. Accepted: source-grounded inventory for onboarding, club discovery, invite, share, deep-link, and club_growth paths.
2. Accepted: make onboarding intent-aware for new player, club member, 총무, pickup host, returning invitee, and safe internal next links.
3. Accepted: zero-club discovery/create path reaches a first club or session action, with server-enforced open and invite-code joins.
4. Active: canonical share-link contract, club invite-code prefill, seeded public web receiver smoke, mobile public receiver fallback, hosted Android custom-scheme return proof including invite-code receiver prefill/submit, native HTTP app-link source config for twomore.app, and the static Kakao template metadata contract plus native Kakao Share adapter wiring are shipped/proven. Next complete Kakao-native delivery by setting template IDs and TWOMORE_KAKAO_NATIVE_APP_KEY, creating a preview build, and smoking KakaoTalk template rendering/return.
5. Finalize credentialed universal-link/app-link proof for the share routes by correcting the live twomore.app web deployment, setting the Apple Team ID and Android SHA-256 fingerprints, passing yarn check:r1-app-links:remote, then running a preview build and device smoke. This is not OTA-only work.
6. Keep the club_growth hosted smoke path healthy and record evidence after any routing/onboarding/share changes.

R2 - Organizer Operations

Goal: a 총무 can run a real club week with less chasing: headcount, payments, attendance, quality control, and communication are all visible.

Field	Plan
Primary artifact	Organizer operating cockpit
Implementation plan	R2 implementation slices
Bounded input	Existing club/session payments, attendance, dues, DM, reports, roles, notifications
Acceptance proof	A seeded club admin can create a session, collect RSVPs, track payment states, mark attendance/no-shows, message members, and resolve exceptions
Verification ladder	Scenario seed; focused hook tests for money/trust paths; manual device smoke for admin workflows
Blocked scope	Facility POS, coach marketplace, full accounting export
Deferral rule	If it does not reduce admin follow-up or improve player reliability, defer

Work slices:

1. Strengthen test coverage for money/trust mutations: dues update, session-payment hooks, attendance exceptions, consent/profile updates.
2. Add a club operations read model that can power both the Clubs tab and Home admin-attention cards without duplicating query logic.
3. Add an organizer dashboard that aggregates upcoming sessions, unpaid holds, submitted transfers, no-show/attendance risks, pending join/guest applications, and reports.
4. Bring admin attention into Home only as role-gated exception cards for admins: payment confirmation, RSVP deadline risk, attendance closeout, join/guest decisions, and reports. Do not turn Home into a general admin console.
5. Improve automated reminders around unpaid holds, submitted transfer confirmation, RSVP deadlines, and attendance follow-up.
6. Add exportable attendance/payment summaries only after the in-app workflow is stable.
7. Keep all payment/trust events routed through existing ports, cache helpers, i18n, and compliance logs.

R3 - Product Polish & Optimization

Goal: the core club app is understandable, fast, resilient, and visually coherent before the final launch gate.

Field	Plan
Primary artifact	Product polish and performance acceptance packet
Implementation plan	R3 implementation slices
Bounded input	Home, Clubs, Activity, Records, Profile, VitePress tracker, docs/state gates, performance logs, accessibility checks
Acceptance proof	Seeded users can complete the club growth loop and organizer operations loop without ambiguous destinations, stale instructions, or untriaged launch-blocking UI/performance issues
Verification ladder	yarn docs:check; yarn check; route smoke for Home/Clubs/Activity/Records/Profile; manual mobile smoke for club member/admin journeys; perf log review for high-frequency surfaces
Blocked scope	New market categories, direct booking marketplace, real payment capture, multi-sport generalization
Deferral rule	If polish does not improve first-session success, club comprehension, admin exception handling, accessibility, or measured performance, defer it

Work slices:

1. Clarify Home versus Clubs responsibility in the product: Home is the attention router; Clubs is the club operating destination; Activity remains the play/session list.
2. Improve club-tab prominence for joined members: show next club session, club health/activity, member role, and admin-action badges directly on club cards.
3. Add Home admin-exception cards only for users who have actionable admin work. These cards should deep-link into the Clubs admin cockpit or existing admin screens.
4. Tighten onboarding and empty states so zero-club users understand that clubs are the primary source of retained play, while pickup remains a low-friction fallback.
5. Audit Home/Clubs/Activity route clarity and remove duplicate or misleading paths.
6. Profile high-frequency surfaces and fix measurable render/network issues before the final launch gate.
7. Complete accessibility and copy polish for primary club, session, payment, and admin flows.

R4 - Launch Readiness Final Gate

Goal: public launch is allowed, observable, and recoverable after R1-R3 are accepted.

Field	Plan
Primary artifact	Release-readiness packet and launch gate closure
Implementation plan	R4 implementation slices
Bounded input	Accepted R1-R3 evidence, External Blockers Register, Pre-launch Checklist, production EAS/Kakao/Apple/Supabase state
Acceptance proof	Every v1.0 launch blocker is closed, feature-gated, or explicitly signed off as not launch-blocking; R1/R2/R3 evidence is linked in the release packet
Verification ladder	yarn docs:check; yarn check; web build; mobile preflight; production build install; production OTA smoke; non-dev account DevPanel/seed gating smoke; hosted club-growth Maestro smoke
Blocked scope	New monetization surfaces, marketplace, multi-sport, large schema generalization, exploratory product redesign
Deferral rule	Anything not required for legal launch, crash recovery, account/auth, first-session success, club comprehension, or admin exception handling moves to post-launch tracks

Required work:

1. Confirm R1 club-growth evidence is accepted.
2. Confirm R2 organizer-operations evidence is accepted.
3. Confirm R3 product-polish/performance evidence is accepted.
4. Close CPO contact and counsel-reviewed legal text.
5. File or gate GPS/location features until the location-service filing is complete.
6. Complete production Kakao IdP onboarding.
7. Complete iOS preview/production builds and store listing assets.
8. Enable branch protection and required checks on main.
9. Produce first production OTA smoke evidence.
10. Verify non-dev production users cannot access DevPanel or seed/simulate paths.
11. Re-run the web build/mobile preflight/dependency-audit readiness checks before launch and ledger any blockers separately from yarn check.

R5 - Real Payments & Subscriptions

Goal: money moves through production-grade rails without compromising trust or legal posture.

Field	Plan
Primary artifact	Production payment rail and pilot pricing gate
Implementation plan	R5 implementation slices
Bounded input	PortOne setup guide, session-payment scaffold, dues model, subscription entity/spec
Acceptance proof	PortOne test channel verifies card/transfer/webhook/idempotency; pilot club can collect a participation fee with server-side confirmation
Verification ladder	PortOne test-channel checklist; edge-function deploy smoke; native runtime build; payment ledger tests; rollback to mock/manual rail
Blocked scope	Marketplace settlement, broad subscriptions, paid user acquisition
Deferral rule	Do not charge before refund/settlement, support, and audit flows are operationally clear

Work slices:

1. Configure PortOne test store/channel/API/webhook secrets.
2. Add the native PortOne adapter behind the existing payment service port.
3. Swap mock confirmation to server-side verify-portone-payment only after test-channel proof.
4. Validate webhook auto-confirm for virtual accounts.
5. Decide the pilot pricing shape: participation-fee transaction fee first, then club subscription, then player analytics subscription.
6. Add revenue analytics only after real payment events exist.

R6 - Venue & Court Platform

Goal: move from "court directory" to "venue-aware play coordination" before attempting a full booking marketplace.

Field	Plan
Primary artifact	Venue operating model
Implementation plan	R6 implementation slices
Bounded input	Current court directory, venue detail, weather/TMI, international data-model decisions
Acceptance proof	Sessions can reliably attach to a canonical venue/court, show useful court context, and support a low-friction booking handoff
Verification ladder	Migration tests; venue mapper tests; session-create/edit smoke; public-court data-quality audit
Blocked scope	Direct booking inventory, operator SaaS, POS, access control
Deferral rule	Do not build direct booking until venue supply and operator workflow are validated

Work slices:

1. Fix known venue/court data-quality issues that affect session creation and display.
2. Adopt the canonical venue bridge only where it directly improves session workflows.
3. Add booking-link/contact handoff for venues before full inventory management.
4. Pilot with a small set of Seoul venues or club-managed courts.
5. Revisit direct booking only after repeated manual handoff demand.

R7 - Leagues & Inter-Club Play

Goal: turn retained clubs into structured competition.

Field	Plan
Primary artifact	Season/league/inter-club event system
Implementation plan	R7 implementation slices
Bounded input	Rating/records, match board, tournament/rotation rules, season specs, inter-club challenge entity
Acceptance proof	A club can run a season or inter-club event with schedules, scoring, standings, and shareable results
Verification ladder	Pure rules tests; migration/RLS tests; seeded tournament/season smoke; records/leaderboard UI smoke
Blocked scope	National federation integration, prize money, open marketplace
Deferral rule	Build only the format demanded by pilot clubs; keep full division/season generality held

Work slices:

1. Ship the smallest season model that supports pilot club standings.
2. Add weekly/monthly leaderboard share variants if they increase club engagement.
3. Add inter-club event workflow after club-admin demand is real.
4. Introduce flexible multi-set scoring only when a pilot format needs it.

R8 - Coaching & Brand Marketplace

Goal: monetize retained player intent without distracting from club operations.

Field	Plan
Primary artifact	Marketplace experiment pack
Implementation plan	R8 implementation slices
Bounded input	Player stats, trust/reviews, payments, DM, share surfaces
Acceptance proof	A small pilot can generate qualified lesson/equipment/sponsor leads without degrading club workflows
Verification ladder	Manual pilot ledger; conversion metrics; abuse/report flow smoke; payment/refund policy review
Blocked scope	Open marketplace launch, affiliate automation, broad ad inventory
Deferral rule	If retained clubs and payment rails are not stable, keep marketplace parked

Candidate experiments:

1. Coach lead form tied to player stat gaps.
2. Sponsored club challenge with opt-in participation.
3. Cosmetic stat-card/profile-frame pack.
4. Equipment recommendation cards as content, not paid placement, until trust is proven.

R9 - Expansion Platform

Goal: preserve optionality without building speculative infrastructure.

Implementation plan: R9 implementation slices.

Held until Korea tennis traction is proven:

• International data model adoption beyond fields that unblock current features.
• Multi-sport support.
• White-label licensing.
• Generic facility SaaS/POS.
• AI video, sensor, or advanced shot analytics.

Tripwire to reopen: at least one active revenue line, retained multi-club usage, and a specific customer asking for the expansion capability.

Success Metrics

Track these per release:

Metric	Why it matters
New-user activation	Did the user join/create a club or RSVP/apply to play within the first session?
Club activation	Did a club create a session and get real RSVPs from non-admin users?
Weekly play loop	Did users return for another session, score, or record within 7-14 days?
Organizer saved-work signal	Are unpaid holds, attendance exceptions, join requests, and reports resolved in app?
Growth loop	Are share/deep-link paths producing joins, applications, or RSVPs?
Payment trust	Are payment states reconciled without manual support or duplicate confirmations?
Safety/compliance	Are reports, blocks, consent, deletion, and location gates behaving as designed?

Not Now

Do not spend roadmap cycles on these until their tripwires are met:

• Generic social feed.
• Persistent realtime sockets for ordinary freshness.
• Full court-booking marketplace before venue supply is validated.
• Open coach marketplace before payment/support workflows are stable.
• Multi-sport abstractions before Korea tennis retention is proven.
• Broad subscriptions before pilot clubs demonstrate willingness to pay.

Replanning Rule

Every roadmap slice must have:

• one primary artifact;
• one bounded input set;
• one acceptance proof;
• one verification ladder;
• one explicit deferral rule;
• one explicit stop condition;
• one linked implementation-plan slice before code work starts.

If a proposed slice has multiple unrelated artifacts or cannot be verified against a seeded scenario, test, device smoke, or external sign-off, split it before implementation. Open build sessions with Execute A Roadmap Slice so the session starts with allowed scope, blocked scope, acceptance proof, and stop rules instead of a broad semantic goal.