SmashRank Case Study: A Padel Ranking Players Trust by Shoaib VohraSmashRank Case Study: A Padel Ranking Players Trust by Shoaib Vohra

SmashRank Case Study: A Padel Ranking Players Trust

Shoaib Vohra

Shoaib Vohra

TL;DR

Product: SmashRank, a competitive padel ranking and matchmaking app for Pakistan, with its own portal for court owners.
My role: Solo founder and PM. Strategy, UX, design and the build with AI coding tools.
Status: Android app in closed testing on Google Play, web at smashrank.pk.
Scale of the build: 195 commits, around 69 screens, 45 database tables and 133 migrations.

The problem

Padel is booming in Karachi and Lahore, but finding a game still runs through WhatsApp groups and DMs, and there's no shared way to know who plays at your level.
A ranking fixes that only if players trust it. One fake or one-sided result and the leaderboard means nothing. So the real design problem wasn't the leaderboard screen. It was trust.
Home and rating: every player starts at 1200 and only confirmed results move it.
Home and rating: every player starts at 1200 and only confirmed results move it.

Key decisions

1. Use a proven rating model

Elo with a K-factor of 32. Every player starts at 1200, across 12 tiers from Low Beginner (below 1100) to Legendary (2300+). I revised the tiers twice (9, then 7, then 12) so newer players see progress sooner.

2. A result only counts when both sides confirm it

Once both players confirm, a database trigger updates ratings, wins and losses, streaks and league in one step. In doubles, one confirmation per side is enough, and the reporting side is auto-confirmed.
Leaderboards: singles, doubles and city rank, built on results both sides confirmed.
Leaderboards: singles, doubles and city rank, built on results both sides confirmed.

3. Close the loopholes before they're exploited

A losing player could simply never confirm, so unconfirmed results auto-confirm after 14 days.
Disputes go to an admin, and an account with an open dispute can't be deleted.
Court owners can only enter scores from an approved booking that has already started, with one result per booking.

4. Keep self-rating separate from the real rating

New players rate themselves 0 to 7 (the Playtomic scale) so Discover can match them quickly. Only confirmed results ever move their competitive rating.
Tournaments and courts: owners run events and enter scores only from approved bookings.
Tournaments and courts: owners run events and enter scores only from approved bookings.

5. Replace DMs with availability posts

Players post an open match (court, time and price), others apply, and the poster accepts one. Accepting creates a normal challenge, so the existing report, confirm and rating pipeline runs unchanged, with no second system to maintain. Posts share to WhatsApp in one tap, meeting players where they already are.

6. Cut friction and running costs

I dropped phone OTP to avoid paying for an SMS provider. Sign-in is email-based, with Google and Apple as options.

Process

Iterating on abuse: the first doubles rule required all four players to confirm, which stopped people naming an uninvolved partner. Once safer checks were in place, I relaxed it to one confirmation per side to cut friction.
Privacy-first analytics: PostHog with 16 custom events, keyed only to an anonymous user ID. No personal data in events, GeoIP off and an opt-out in Settings. Activation and conversion funnels come first.
Launch work: Play Store listing and screenshots, tournament terms, the production access submission, and a five-year financial model for investor conversations.

What shipped

Players: leaderboards (singles, doubles, city rank), discover and challenges, open matches, permanent doubles partners, friends and chat, achievements, and push notifications.
Court owners: bookings, availability, customers, analytics, score entry and public court pages.
Events: tournaments and balanced mixers, plus an admin dashboard and block and report tools.
Stack: Expo SDK 57 and React Native, TypeScript, Supabase (Postgres with row-level security, Realtime, Edge Functions), Expo push and FCM v1, EAS Build, PostHog, Netlify.

By the numbers

195 commits
About 69 screens across players, court owners and admin
45 database tables and 133 migrations
7 server functions
16 tracked product events

What's next

Production release on Google Play with an opening tournament, and signing letters of intent with court owners.

What this shows

I think in systems: incentives, edge cases and abuse, not just screens. And I can ship that thinking as a working app.
Need a PRD, an AI-built MVP or a product and UX audit? Message me here on Contra.
Like this project

Posted Oct 9, 2026

How I designed a fair Elo ranking for Pakistan's padel scene: two-sided result confirmation, anti-abuse rules and matchmaking beyond WhatsApp.