Running Crew Race Group Registration Admin Tool

3.80

Derivation Chain

Step 1 Marathon participation boom

→

Step 2 Activation of running crews

→

Step 3 Inefficiency of crew admins manually handling group race registration, fee settlement, and participant management

Problem

In running crews (10-50 members) with many members in their 40s-50s, the person serving as the admin must manually collect participant lists, t-shirt sizes, and entry fees via KakaoTalk, organize them in Excel, and then manually register each member on the race website. Since each race has a different registration form, re-entry is required, and fee settlement requires cross-checking transfer records from Toss and KakaoPay. For a crew of 30, registering for one race takes 3-4 hours, and settlement takes 1-2 hours, causing extreme admin fatigue and eventually leading to no one wanting to take on the role.

Solution

When the crew admin shares the race registration form link in the crew's KakaoTalk chat, members directly input their participation information (name, date of birth, t-shirt size, course selection) and pay the entry fee. The participant list is automatically organized into Excel/CSV and can be downloaded in the format required for the race website upload, and payment status is tracked in real time with automatic reminders sent to those who haven't paid.

Target: Running crew admins or operations staff aged 40-55, crew size 10-50, participating in races 1-2 times per month, communicating via KakaoTalk.

Revenue Model: Free for crews of 10 or fewer, 5,000 KRW (approx. $3.75) per race for crews of 11 or more, and 49,000 KRW (approx. $36.75) per crew per year for annual subscription (unlimited races).

Ecosystem Role: Supplier

MVP Estimate: 2_weeks

NUMR-V Scores

N Novelty

4.0/5

U Urgency

4.0/5

M Market

3.0/5

R Realizability

4.0/5

V Validation

3.0/5

NUMR-V Scoring System

N Novelty	1-5	How uncommon the service is in market context.
U Urgency	1-5	How urgently users need this problem solved now.
M Market	1-5	Market size and growth potential from proxy indicators.
R Realizability	1-5	Buildability for a small team with realistic constraints.
V Validation	1-5	Validation signal quality from competition and demand data.

N=.15 U=.20 M=.15 R=.30 V=.20

Feasibility (69%)

Tech Complexity

29.3/40

Data Availability

20.0/25

MVP Timeline

20.0/20

API Bonus

0.0/15

Feasibility Breakdown

Tech Complexity	/ 40	Difficulty of core implementation stack.
Data Availability	/ 25	Practical availability and cost of required data.
MVP Timeline	/ 20	Expected time to ship a usable MVP.
API Bonus	/ 15	Bonus for viable public API leverage.

Market Validation (56/100)

Competition

8.0/20

Market Demand

6.2/20

Timing

14.0/20

Revenue Signals

7.5/15

Pick-Axe Fit

10.5/15

Solo Buildability

10.0/10

Validation Breakdown

Competition	/ 20	Signal quality from competitor landscape.
Market Demand	/ 20	Demand proxies from search and mention patterns.
Timing	/ 20	Fit with current shifts in tech, behavior, and regulation.
Revenue Signals	/ 15	Reference evidence for monetization viability.
Pick-Axe Fit	/ 15	How well the concept serves participants in a trend.
Solo Buildability	/ 10	Practicality for lean-team implementation.

Technical Requirements

Frontend [medium] Backend [medium] Infrastructure [low]

Dashboard