App makers · Local social apps
Should your local social app launch in a second neighborhood?
Measure whether people at the first location can find each other in time. A table-tennis club pilot shows how the same number of requests can produce eight Wednesday matches and three Saturday matches.
GimmeTheSauce editorial ·
If a member needs someone nearby to respond, expand when people in the first location can repeatedly get the promised interaction in time, with an amount of organizer work you can sustain. Start by measuring one place and one time slot. A member who wants to play table tennis on Wednesday evening gets little value from a hundred players who are only free on Saturday.
Paul Graham describes early Facebook opening within individual colleges, where people had a reason to find one another. For a sports app, a club and its playing hours can give you a similar boundary for a first test. If you still need participants, recruit people around their next real task. Paul Graham’s account of early recruitment
Give each request a deadline
Suppose your app helps adults find a table-tennis partner at their club. A member wants an answer before they make other plans. For this hypothetical pilot, offer two recurring sessions and take requests at least 24 hours before play. Promise to show whether a partner has accepted within 24 hours of posting.
Before the test, decide how often the club needs to deliver on that promise and how much organizer time it can afford per session. A waitlist total gives you neither number.
Count one request for one player seeking one partner for one session. A repost keeps the original request ID and clock. In this example, responders accept an open request and have no competing request for the same session. A match needs a compatible player who accepts the specified club and playing time. A reaction, a generic greeting or a reply after the deadline does not fulfill that promise.
Use one row per request. Record the slot, posting time, time of acceptance, and whether an organizer personally found or nudged the partner. Keep requests whose 24 hours have not elapsed in a pending list until the comparison is ready. A confirmation tells you the players arranged a game. To learn whether they played, ask after the session and record unknown outcomes separately.
Sharetribe’s search-to-fill metric counts the share of marketplace searches that produce a transaction. Here the analogous unit is a player’s request and the outcome is timely acceptance. The deadline belongs to this club pilot. Sharetribe’s guide to marketplace metrics
Read the results one slot at a time
Across several sessions at one hypothetical club, 24 distinct requests have reached their deadlines. Each row below accounts for every request in that slot.
| Playing slot | Opened requests | Accepted unaided | Accepted with organizer help | No timely match |
|---|---|---|---|---|
| Wednesday evening | 12 | 6 | 2 | 4 |
| Saturday morning | 12 | 1 | 2 | 9 |
On Wednesday, 8 of 12 requests found someone in time. On Saturday, 3 of 12 did. Across the club, 11 of 24 succeeded, about 46%. The club-wide number hides where a new player has a reasonable chance of finding a partner. Only 7 of 24 succeeded unaided. Taking away the organizer could also change player behavior, so that last count alone cannot predict what would happen without them.
I would keep the next pilot at the same club. Wednesday has six unaided matches worth trying to reproduce. Saturday has nine missed requests worth opening individually. These counts describe people who posted. Ask a member who signed up and stayed silent whether there was even a session they wanted to join. The small pilot cannot tell you how a whole city would behave.
Decide whom to invite next
Take one missed Saturday request and reconstruct what a compatible player could actually see. Was anyone available at that club and time? Did the request reach those players before their decision deadline? If they saw it, what prevented them from accepting? A brief conversation with a willing player can distinguish a schedule conflict from a request that omitted the playing level. Record an unknown when you cannot tell.
If nobody compatible was available, ask the club organizer to invite willing Saturday regulars for the next session. If compatible players never saw an eligible request, rehearse delivery on two test accounts before recruiting anyone else. If pairs accept but regularly cancel, check what happens between confirmation and play. Each finding calls for a different experiment.
With the two slot counts and an anonymized missed request in hand, plan the next local launch test with Nikita Bier’s AI mentor ↗. Specify what the organizer did for each assisted match so the discussion can account for that labor.
Repeat the test across comparable sessions. Track how many distinct people serve as partners and whether participants return when their next playing opportunity arrives. Six matches supplied by one volunteer carry a different expansion risk from six supplied by six regulars. Once your first club can keep its promise across sessions, try one comparable slot at a second club and keep its ledger separate. You will learn whether the second location can form matches of its own.
For a club that sends invitations by email, trace a delivery through to a joined account before deciding that invited players lacked interest. The worked example uses SaaS workspaces; the same gap between a server accepting mail and a person taking action applies here.