MatchPoint
A native iOS app for finding people at your level to play with, and a rating based on a fair system.
Industry
Consumer social · Recreational sport
Team
2 members
Platform
iOS 17+ · Supabase
My roles
Product Architecture · UX Research · Operations ·
Rating logic · UI Design
Tools
SwiftUI · Swift Charts · MapKit · Supabase
Postgres · React · GitHub Copilot
TIMELINE
6 Weeks
(Currently ongoing - Beta Testing)
At a glance
Find someone worth playing, not just somewhere to play
You find players and courts near you, send a challenge, sort the details out in chat, and confirm the score afterwards. Every sport you play carries its own skill rating, and it only moves when both people agree on who won. The backend is live, the closed beta is planned to the device, and the app is ready for TestFlight.
24.3M
Americans played pickleball in 2025, up 171.8% in three years [1]
2M+
players already carry a DUPR rating. None of that number finds them a game [4]
6
sports modelled in two shapes, individual and group. Two are live in the beta
80
where everyone starts, per sport, on an uncapped scale
12 → 2
how far one result can move you, from your first match to a settled rating
10
matches before a rating stops being marked provisional
17
Supabase migrations, with row level security on every client facing table
20
closed beta testers across two sports, with ten end to end acceptance runs
The loop the whole product is built around
Each lap produces a verified result, and each verified result makes the next match fairer.
01
The gap
Ratings scaled and matchmaking did not. Every product solves one half of the problem.
02
The shape of a sport
Cricket broke the model, so the app stopped organising by sport and started organising by shape.
03
A number that means something
An uncertainty aware rating, verified by both players, and no rating at all where one would be noise.
04
Built, not mocked
Designed by building it: SwiftUI, a Postgres backend, privacy rounded maps and a 20 person beta.
01 · The problem
Everything is ready except the opponent
It is hard to find someone at your level who is free when you are and who will actually turn up. The evening is free, the court is bookable, and you still do not play, because two of your four regulars are busy.
Your regular group, on a Tuesday
Four in the chat. Two are busy. So there is no game.
Functional
Scheduling is conversational labour
Player discovery lives in one app, courts in another, availability in a group chat, and the score nowhere at all. Every handoff loses the context of who, when and how good.
“I cannot tell whether someone who says intermediate will create a fair game.”
Emotional
Fear of the mismatch
Approaching a stranger is harder when you might be outclassed in public, or waste a better player's evening. Momentum dies when a promising chat never becomes a game.
“I want to play tonight, but I do not know who is both nearby and free.”
Economic
Empty slots cost real money
Paid court time is wasted by incomplete groups and no shows. Captains and clubs carry the admin, and off peak courts sit idle while players who would fill them never meet.
“We played three games, but the result was never recorded.”
The idea in one line
Social apps make you friends. Rating systems make you a number.
MatchPoint does both, and that is the whole product.
You cannot build a fair game out of friendship alone, and you cannot build a community out of a leaderboard. Put the two together and the rating stops being a vanity metric. It becomes the thing that decides who you meet.
Three players, three reasons to open the app
The Squad Organiser is the one who brings fifteen others with him.
The Rated Competitor
Plays 3x a week, carries a DUPR rating
Will travel for a good match and will not spend an evening on a mismatch.
Pain
Wants a verified opponent inside a narrow band
In the app
Rating filtered map, verified scores, a real ladder
The Returner
Back after a decade, plays once or twice a week
Confident in the sport, no idea where he now sits, and no local network left.
Pain
Afraid of being outclassed in public
In the app
A provisional 80, unrated play, a low stakes first game
The Squad Organiser
Captains a cricket XI, 15 on the roster
His problem is not finding opponents. It is getting eleven people to agree on a Saturday.
Pain
Chases availability across three group chats
In the app
One shared fixture calendar, no ladder required
02 · Why now
The players arrived. The matching layer did not.
Pickleball has been the fastest growing sport in the US for five years running, and the people who play it most often grew fastest of all. A couple of million players already have a verified skill number, and not one product uses it to find them a game. The rating industry and the social industry grew up beside each other and never met.
US pickleball players, millions
Played at least once in the year
SFIA Topline Participation Reports 2025 and 2026 [1][2]. 2021 derived from SFIA's reported 85.7% growth into 2022.
The committed core grew fivefold too
2020 ○ versus 2025 ●, millions of players
SFIA 2026 Pickleball Single Sport Report [1]. Core means eight or more times a year.
42.9%
of pickleball players are now women, up from 38.6% in 2020 [1]
13 to 24
the age band with the highest participation rate of any segment [1]
Global sport app market, US$ billions
Hatched bar is a forecast, 10.64% CAGR from 2025 to 2034
Precedence Research, Sport App Market [3]
37%
North America's share of the sport app market in 2024, the largest region [3]
17,000+
clubs on DUPR across 183 countries, with 10M+ matches logged [4]
68,458
pickleball courts in the US. Courts exist. Knowing who to play on them does not [6]
8.3M
people in Dallas Fort Worth, the launch market and the fourth largest US metro [5]
Every product solves one half of the problem
Apps that find you a game do not know how good anyone is. Systems that know how good you are will not find you a game.
The honest version
A clean quadrant would not survive diligence
DUPR links rated players to clubs and events. Pickleheads runs groups with DUPR results. RacketPal and Playtomic both do some matching. Claiming that nothing like this exists would fail the first investor question.
So the differentiation had to be narrower and measurable: a result both players verify, an uncertainty aware number built from it, and that number deciding who you are shown next. Discovery attracts people. Verified matches are the asset.
North star: verified matches completed per weekly active player, not profiles browsed or messages sent.
Archetype
What it does well
Where it leaves room
Rating network, DUPR
Trusted rating identity, result volume, club integrations
The rating is the centre. Turning it into a scheduled casual match with someone nearby is not the core job
Court and game directory, Pickleheads
Court data, sessions, organiser tooling, a large pickleball community
Built around organised sessions rather than individual discovery and a cross sport identity
Booking marketplace, Playtomic
Venue inventory, payments, open matches in its markets
Venue supply comes first. Players outside integrated venues are left to coordinate themselves
Player matching app, RacketPal
Multi sport discovery and messaging
Has to prove local density and a rating people trust
Group chat and calendar
Everyone already uses them
No skill model, no match object, no result, no consequence
03 · Architecture
One app, very different sports
We built the first version around pickleball. Adding badminton was fine. Adding cricket broke the whole thing.
A pickleball match is two or four people, a scoreline, and a result both sides confirm. A cricket fixture is a team, a ground, a three hour window, and a result that says nothing about how you personally played. We were modelling both as “a match”, and the screen we got out of it was wrong for both.
So we stopped organising by sport and started organising by shape.
That one split ended up driving everything else. Players carry a separate profile per sport too, so your badminton rating and history are a different record from your pickleball ones.
It did not turn into three apps
The shell is the same everywhere. Four tabs, one app bar, one create button. What changes is the inside, and it changes all the way down. The second tab renames itself, swaps its icon, and renders a different screen.
Sport is a mode, not a destination
Switching sports is a dropdown in the app bar rather than a tab. It re-tints the whole app, and it will not switch while you have a form open, because a half written challenge would just disappear.
Six sport identities from one system
The beta runs on pickleball and badminton. The rest stay visible in the sport picker as coming soon. Each sport carries its own tint and illustration, your character changes equipment with it, and group sports bring their own review categories.
Pickleball
MP rating
Live in beta
Badminton
MP rating
Live in beta
Ping pong
MP rating
Coming soon
Cricket
Batting · Bowling · Fielding
Coming soon
Soccer
Passing · Finishing · Defense
Coming soon
Volleyball
Serving · Setting · Defense
Coming soon
Shared across every sport
One person
Name, username, age, photo, bio and city. The social graph, every conversation, notifications and saved availability. Up to four sports per person.
Owned by one sport
Many records
The rating or peer skills, home court and play style, match history and statistics, challenges and fixtures, map results, clubs and communities.
04 · Information architecture
Where does the social layer live?
We kept coming back to the same question, and it was not really about the tab bar. What belongs to MatchPoint as a platform, and what belongs to an individual sport? Matches belong to a sport. So do courts, ratings and challenges. People do not.
Before
Chat started out as a tab
It sat in the sport scoped nav next to Home, Map and Matches. That works until you switch from badminton to cricket and your conversations change with it. Notifications had the same problem, since a challenge or a friend request can come from anywhere in the app.
After
Chat moved above the line
Chats, notifications and the sport switcher now live in the app bar and slide over everything. A message is from a person, not from a badminton person, so switching sport does not touch any of it.
The badge had to change too
It used to be a count. Once notifications went global, the local count was still scoped to the active sport while the server count was not, so the number meant different things depending on where it came from. We swapped it for a dot, which promises less and is always true.
The container is neutral, what goes in it is not
Chat itself does not care what sport you are in. A challenge sent inside one does, and the composer only offers the sports you both actually play. On the server, a challenge needs an accepted connection and a shared active sport, so a crafted API call cannot create one either.
The question stopped being what the screen looked like and became where the feature actually belonged.
05 · Core flows
From a stranger on a map to a result on the record
Every step raises the commitment a little. Browsing costs nothing, a request costs a tap, a challenge names a time and a place, and a verified score is a record both people signed. The rules that keep that honest live in Postgres, not just in the interface.
Getting to a confirmed match
Guards in yellow are enforced by the backend as well as the UI.
HOME
A to do list for your sport
Scores waiting on your verification, connection requests, incoming and outgoing challenges, recommended players at your level, and clubs, leagues and facilities nearby. Each section opens its own sheet.
MAP
Wide, but never exact
Pan and pinch from your block to the whole country. Filter by rating, gender, and everyone or friends, with a gold ring around people you know. Every pin is rounded to the neighbourhood.
MATCHES
Past, upcoming, and a week at a glance
A weekly calendar where status is the only legend: filled means confirmed, outlined means awaiting a reply. Each result shows where its score came from.
CREATE
One button that knows the sport
The persistent action button expands into challenge and upload scores for individual sports, and add a game and submit a review for group sports.
CHALLENGE
Three times, one tap to answer
The composer proposes up to three windows, names a court, and leaves the wager for the chat. The other player picks a time instead of writing a paragraph.
WAGER
Consent before stakes
A wager is never baked into the first challenge. It is proposed afterwards, accepted, or skipped, and only an agreed one travels with the match.
SCORES
Every game, not just the winner
Singles or doubles, one to seven games, a winning side per game, and a session result the other player has to confirm before anything counts.
RESULT
The rating moves last
Verification is its own screen: the reported games, the rating before, the change, and the rating after, so nobody agrees to a number they have not seen.
The screens, as they run on device
Captured from the build, pickleball and badminton modes.
01 · Onboarding
Three stories set expectations before any form. This one says what a win is worth.
02 · Your identity
Choose your player from a cast of characters. Your character changes equipment when you switch sports.
03 · Choose your sports
Individual and group sports are listed apart. Pickleball and badminton are live, the rest say coming soon.
04 · Configure each sport
Everyone starts at 80, and anyone can opt out of the rating system, per sport.
05 · Home, pickleball
Your rating, then the things waiting on you: four scores to verify, connection requests, challenges.
06 · Notifications
Global, not sport scoped, and filterable. Every score submitted for you to verify shows its own action.
07 · Map
Rated players nearby, clustered when they overlap, with everyone or friends, gender and rating filters.
08 · Player drawer
Distance, skill rating per sport, connections in common, and block sitting right next to connect.
09 · Matches
Upcoming with status, past with the score and the rating change it produced.
10 · Match details
Every game in the session, the venue and the date, with a route into the statistics.
11 · Send a challenge
Up to three times, a court, an optional note, and the wager left to be agreed in chat.
12 · In the chat
The challenge lands as a card in the conversation, and waits for the other player to pick a time.
13 · Upload scores
Singles or doubles, up to seven games, a winner per game, and a session result submitted for verification.
14 · Profile
The current number, how it works, matches, wins, win rate, and a trend for the last 30 days.
15 · Home, badminton
Same shell, second sport. The switcher re-tints the app and swaps every record underneath.
16 · Facility
Courts come from Apple Maps and are cached, then clubs and groups get built on top of them.
06 · Systems
Making skill mean something
Everyone starts at 80, per sport, on an uncapped scale. Beating someone above you should move you more than beating someone below you, which is how Elo already works. What we cared about is that the same result should move a new player further than a veteran, because we know a lot less about the new player.
How far you move
change = K × (what happened − what was expected)
Expected comes from the gap
A logistic curve over the rating difference, with a scale of 10. Ten points above your opponent, you are expected to win about 73% of the time.
K comes from how sure we are
Uncertainty starts at 12 and decays 4% a match to a floor of 3. K maps onto it, from 12 for a first match down to 2 once a player has settled.
So two people can win identical matches and move by different amounts. Under ten games you are marked provisional, which is our way of saying the number has not settled yet.
Fairness by design
The rating is opt in, and opting out costs you nothing
Rated players have every verified result move the number. Unrated players still play, log scores and keep a history, with no number and no ladder. If either player has opted out, the match is rating exempt and the app says so before it is sent, so a rated player gains nothing from beating an unrated one and an unrated player risks nothing. So the game happens.
Most competitive apps make the ladder compulsory. Making it optional is what keeps the casual half of a club, the beginners and the older players on the platform.
What was expected
Chance of winning by rating gap
How sure we are
K factor by matches played
Same result, different move
Rating change for a player rated 80, computed with the shipped engine
Parameters from rating_engine_config v2: start 80, uncertainty 12 to 3, decay 0.96, K 12 to 2, scale 10. The onboarding promises +1 to +2 for beating an even opponent. That holds once a rating has settled. Provisional players move further, on purpose.
Doubles was harder than singles
One team expectation, four personal K values
A team's strength is the average of its players' ratings, and both teams get one shared expected score from that. Each player then moves by their own K, from their own uncertainty.
Team A wins
Rating
Matches
Change
A · new partner
85
3
+7.6
A · veteran
75
40
+1.5
B · first match
90
0
−8.8
B · veteran
90
40
−1.5
Team A averages 80 against 90, so it was expected to win 27% of the time. Worked example, not beta data.
Two matches finishing at once
A snapshot, then a lock
Every update comes off a snapshot taken before anything settles, so both sides are worked out against the same starting state. In production that is a Postgres function that locks every affected row in a fixed order first, so two matches finishing at once cannot interleave.
Each participant gets exactly one immutable rating event per match, carrying the rating and uncertainty before and after, the expected score and the engine version.
1
rating event per player, per match
v2
engine version stamped on every event
Verified, or it does not count
An uploaded score does nothing until the opponent confirms it. That is the difference between a rating and a claim.
Verify a result
The opponent sees every reported game, the rating before, the change and the rating after, and confirms or disputes. Nothing settles until then.
Explained in the app
The same rules, in the product: verified wins move it gradually, the matchup affects the change, both players confirm, and every sport stays separate.
A number would have looked authoritative
We could have given cricket players a rating. It would have been mostly noise. Whether your team won says very little about how you batted, and nothing about whether you got to bat.
So group sports get reviews instead
Teammates review skills that belong to the sport: batting, bowling and fielding for cricket. One enthusiastic teammate cannot manufacture a reputation. We would rather show no number than one that does not mean anything.
Knowing when not to create a rating
A cricket skill score after a run of five star teammate reviews
Reviews are pulled toward a neutral 4.0, weighted as five reviews, until enough real ones exist.
07 · Iteration
Designing it by building it
The interface did not come out of one design pass. Four things changed how we thought about the product, and all four happened while we were building it. The commit history shows it plainly, including the reverts.
JUL 31
PickleMatch audit
A dark Court Glass prototype, a 1 to 100 Elo starting at 50, and every player on the map still mock data.
AUG 5
Shared repository
The SwiftUI prototype moves into one codebase for both of us.
AUG 17
13 commits, 2 reverts
My browser prototype becomes the behaviour baseline. Its visual system is ported, reverted, rebuilt natively, then replaced by Rally.
AUG 31
A real backend
Production schema, secure onboarding, the uncertainty rating, atomic peer reviews, rounded map coordinates, account deletion.
SEP 3
Global social layer
Chats and notifications leave the tabs, unread state persists, native date pickers are replaced.
SEP 10
Closed beta ready
Integrity checks on challenges, scores and chat, and privacy safe discovery across the country.
Five visual directions, one that shipped
The behaviour stayed constant while the skin changed. A functional inventory of every screen, state and safeguard was written first, so each redesign could not quietly drop a capability.
Sorbet
Cream, candy accents, illustrated players
Court Glass
Deep forest, mint, Avenir Next
ACTIV8
A louder brand exploration
My 8/17 system
Illustrated players, the React build
Rally, shipped
White, ink, sun yellow, SF Expanded
01
We retrofitted my visual system, then threw it away
Porting the direction I had built onto our existing screens half worked. Those screens assumed a different hierarchy, so we kept compromising the new system to fit them. We reverted the commit and rebuilt it as its own SwiftUI experience.
02
Moving chat turned into a navigation rewrite
It meant a second presentation layer above the tabs, notifications going from a sheet to a full page, and an unread state that had never needed to exist. The IA decision and the state architecture were the same decision.
03
We replaced iOS's own date picker
A challenge proposes a few times, so the sheet stacks several date fields. The system picker was cramped and could not be styled to match anything near it. Each one became a button that opens a custom editor.
04
The unread dot needed a database
It started out computed in the view, comparing the message IDs you had seen against what came in. Correct, and completely local. Close the app and everything was unread again.
We also reverted an illustration system after importing it, and the theme file still carries three generations of naming. The history is not tidy. That is what iterating in the codebase looks like.
Replaced on purpose
Native menus and pickers
Branded controls replaced system menus, pickers, toggles and selector sheets wherever they sat next to custom UI.
Removed on purpose
A whole onboarding step
The separate “When can you play?” page was cut. Availability lives in your profile and gets compared inside chats instead.
Kept on purpose
Every 8/17 behaviour
A parity audit checked 25 screens and workflows against the August 17 baseline. All 25 were carried into SwiftUI.
08 · Built for real
A backend that assumes strangers
An app that introduces people who then meet on a court cannot run on a mocked social graph and a report button that does nothing. Everything below is in the repository today, and every client facing table has row level security.
19k+
lines of SwiftUI across 44 files, plus a home screen widget
17
Supabase migrations, applied in order to every environment
28
tables, each with row level security enabled
44
Postgres functions, from matchmaking to account deletion
How the pieces talk
The client never writes a rating. It asks the database to settle a match, and the database decides.
ASKED IN CONTEXT
“Your exact location is never shown to other players.”
Location
Near, never exact
Pins are rounded to two decimal places, roughly a neighbourhood. Exact coordinates never leave the database. The map can zoom out to 3,000 miles while Home recommendations stay local, and the app still works if you deny location.
Consent
Nothing happens to you uninvited
You reply to a chat only after accepting it. A challenge needs an accepted connection and a sport you both play. Blocking removes someone from discovery, challenges and messages, even with no prior conversation.
Integrity
No impossible records
A closed beta test runs the riskiest multi account flows in one rolled back transaction: accept a chat, challenge, upload, agree from two accounts, and settle exactly one rating event per player. Delete your account and your private data goes with it.
09 · Beta and launch
A closed beta planned down to the device
Pickleball and badminton are live. The beta is sized to break the riskiest parts on purpose: two accounts on two phones, doubles with four real people, testers far from the primary city, and people who say no to location and change their mind later.
Who tests what
20 testers, each square is one person
4+
doubles groups, so partner and opponent choices are tested with real people
4+
testers outside the primary city, to prove wide map discovery
2+
testers who deny location, then turn it on later in Settings
8
fields logged for every failure: device, iOS, account, action, expected, actual, screenshot, time
Ten acceptance runs
Every run crosses two accounts on separate devices. None of them can pass in a simulator.
01
Two new accounts confirm email and finish onboarding on separate devices
02
Both allow location, and each sees the other at an approximate, not exact, pin
03
One sends a connection request, the other accepts, and both can chat
04
Pickleball and badminton singles run through challenge, acceptance, score, verification and rating change
05
Doubles runs with a partner and two opponents, checking every participant choice
06
Conflicting results are submitted, and the match is disputed with no rating change
07
Join a club, create or join a group, and confirm membership from another account
08
Block an account, and discovery, challenges and messages all become unavailable
09
Deny location, and the app stays usable without map discovery
10
Delete a disposable account, and its private data is no longer accessible
The words that bring people back
Push copy is written for every event in the loop. Inactivity nudges are opt in, capped at one a week, and never include anyone else's location.
Event
Title
Body
Connection request
New connection request
{name} wants to connect.
Challenge received
New {sport} challenge
{name} offered some times. Choose what works.
Challenge accepted
Match confirmed
{name} accepted {date and time}.
Reminder
Match coming up
Your match with {name} starts {relative time}.
Score verification
Verify the result
{name} submitted a score from your match.
Result verified
Rating updated
Your {sport} rating is now {rating} ({change}).
Inactive user
Ready for a game?
See who is available near you this week.
USER TESTING FINDINGS
Slot for the results from our user testing rounds
Waiting on the session notes: who we tested with, the tasks, what broke, and what changed in the build because of it. This block is a placeholder and will not ship empty.
Why Dallas Fort Worth first
A matchmaking product is worthless at low density. So we start where we already know everyone.
One cricketer is not one user. He is a roster, a fixture list, and two other sports.
A cricket league is the cheapest possible door into a multi sport network, because the captain has to invite his eleven for the fixture to be any use to him.
8.3M
people in the metroplex, the fourth largest US metro, up 30.6% since 2010
~150
pickleball courts built in DFW in one year by a single contractor, per the pitch deck
After Dallas: seven doors that are already open
In each city there is a workplace, a recreational facility or a university, and someone there who would take it forward. Seven warm starts beat fifty cold ones.
HOME ★
Dallas
Cricket leagues, pickleball and badminton facilities
WORKPLACE
Austin
A dense young recreational scene
UNIVERSITY
College Park
Campus community and recreation
WORKPLACE
San Francisco
A network across the Bay Area
UNIVERSITY
Pittsburgh
Campus community and recreation
UNIVERSITY
Salt Lake City
A strong outdoor sport culture
WORKPLACE
Seattle
Year round indoor facilities
WHAT WE ARE ASKING FOR
Not capital yet
Conviction, introductions to facility and league operators, and someone to argue with us about the launch sequence.
The supply side: fair draws, not just fair matches
Organisers currently seed by reputation and guesswork, and the first round is full of lopsided blowouts that make half the field never come back. This is also where revenue eventually comes from.
Facility owners
More footfall
List courts and open sessions, fill the quiet hours, reach players by sport and level.
Tournament organisers
Better outreach
Publish a draw to the right players, seed by verified rating, reach beyond the usual list.
League and club admins
Less admin
Run ladders with real numbers, keep squads on one calendar, see who is actually active.
10 · Reflection
From designer to product builder
None of these decisions arrived in a design file.
01
The sport split was a modelling problem
It was not a screen. It only showed up once cricket had to share a data model with pickleball.
02
The navigation change was a state problem
Where a feature lives and where its state lives turned out to be one question, not two.
03
The rating was a question about what a number can claim
And the answer ended up being a Postgres function with a row lock in it.
We were moving between product thinking, interface, architecture and Swift constantly, often in the same commit. There was no handoff and no clean line between the design and the build.
Sanjana and I built MatchPoint together across product architecture, UX, the sport system, the rating logic and the SwiftUI implementation. We pressure tested the ideas with people who have a lot more experience than us, including a Design VP at JPMorgan Chase and researchers at Google DeepMind.
Building it is how we found out what we were designing.
Built by Sashank Mullapudi and Sanjana Venkat.
11 · Handover and next steps
What stands between the build and the App Store
The codebase and the Supabase project are ready for a small pickleball and badminton beta. What remains is mostly owned by Apple accounts, and then the harder question of whether one market can reach density.
NOW · APPLE STEPS
TestFlight
Developer Program enrolment, signing for the app and widget, the APNs entitlement and key, a privacy policy and support URL, App Store privacy answers, final icon and screenshots.
PHASE 2
Make the loop real and repeatable
Push and deep links into chats and matches, recurring availability with calendar import, cancellations and no shows, expiring opt in presence, and a match day widget backed by server state.
PHASE 3
Deepen the network
Court booking and fill the court offers, then an organiser toolkit: recurring sessions, waitlists, round robins, seeding by rating and facility dashboards. Never cash wagers.
The gates we set before expanding
Targets for the pilot, not observed results. A city is not launched because the app is downloadable there.
80%
task success in moderated tests, find a player through to scoring a game
<7d
median time to a first confirmed match
50%
of challenges accepted
60%
of confirmed matches actually played
85%
of results verified by the opponent
<5%
of results disputed
A business model that cannot pay to win
Tier
Test range
What it adds
Free
$0
Profile, discovery, map, chat, scheduling, rating, scoring and every safety tool
Plus
$7.99 to $11.99 a month
Advanced filters, travel mode, deeper stats, priority alerts
Organiser or club
$49 to $199 a month
Rosters, sessions, waitlists, round robins, leaderboards
Referral
Per booking
Court time, events, lessons and equipment, never wagers
PLANNING SCENARIO, NOT A FORECAST
What a Plus subscriber has to be worth
$212
lifetime value at $9.99, 85% net, 4% monthly churn
$64
acquisition cost ceiling for a 3.3x return
7.5
months to pay back that cost
Willingness to pay gets tested only after retained value is proven. Conversion is never optimised at the expense of match completion.
REFERENCES
1 · Sports & Fitness Industry Association. SFIA Releases 2026 Pickleball Single Sport Report, and U.S. Pickleball Participation Statistics.
2 · SFIA 2025 Topline Participation Report, as reported in The Dink, Pickleball participation surges to nearly 20 million in 2024.
3 · Precedence Research. Sport App Market Size to Hit USD 13.22 Billion by 2034.
4 · DUPR. dupr.com, rated players, clubs, countries and matches logged, retrieved September 2026.
5 · USAFacts, from US Census Bureau estimates. How many people live in the Dallas, TX area?
6 · Pickleheads. Pickleball Statistics, court counts confirmed with USA Pickleball.
7 · Mullapudi, S. and Venkat, S. MatchPoint: One app, very different sports, the MatchPoint product video, and the MatchPoint repository: rating engine, Supabase migrations, beta plan and parity audit.
MatchPoint · A rating, a calendar, and someone to play tonight.
Sashank Mullapudi's Portfolio © 2026-27. Designed by Sashank Mullapudi.