Sports Marketplace
Players and Coaches, iOS and Android
I cannot name the product, so here is what it does. Players and coaches find each other nearby, agree on a session, talk in chat, and rate each other afterwards. Coaches run their own schedule and client base on the same platform. The founder came to me to build an app. What the business needed was three products: the app people install, the backend nobody sees, and the panel the founder's own team would live in every day. I delivered all three and shipped to the App Store and Google Play on two months of active development. It is live and still growing.
My roleSole engineer · Architecture · Backend · Release owner · Under NDA
The story
A sports marketplace only works if both sides show up. A player has to find a coach nearby, agree on a time, and trust a stranger enough to turn up for a session. That means geo search, scheduling, chat, ratings, payments and moderation all have to work on day one, not in v2. Quote only the screens you can see and the rest of the system arrives later as an invoice.
One scope covering three products: a Flutter app for iOS and Android carrying both roles with a switch between them, a backend holding subscription state, session lifecycle and notification logic, and a web admin panel so the client's own team could work reports, bans and user support without a developer in the loop.
Shipped to both stores on two months of build time, in two interface languages, with the moderation tooling Apple requires for user-generated content built in from the start instead of bolted on at review. The product is live, growing, and still adding features on the architecture it launched with.
What I built
Three interconnected products sharing the same real-time infrastructure.
Mobile App
Flutter · iOS & Android · players and coaches in one app with role switching · 24 sections · 2 languages at launch
Admin Panel
Flutter Web · reports, bans, user messaging, broadcasts and reference data, built for a non-technical team
Backend
Firebase Cloud Functions · 127 server operations · 28 notification scenarios · isolated staging and production
Engineering challenges
The hardest problems I solved, and how.
🛡️Moderation Is a Release Condition, Not a Feature
Apple rejects apps with user-generated content when there is no way to report, block, and remove. Most teams find this out at review, a week before launch, and lose a month. By then the marketing date is already set.
Reports on both people and content, blocking, bans, content removal, a support conversation channel and broadcasts went into the architecture in the first week, together with the admin panel the client's team uses to work them.
Shipped to both stores without a moderation rejection. The client's team handles reports themselves, so no engineering time goes into day-to-day user complaints.
💳Subscription Status Cannot Live on the Phone
If "premium" is whatever the payment library on the device last reported, the status drifts: offline use, a new phone, a refund, family sharing. Users lose access they paid for, or keep access they cancelled. Both end up in support, and one of them is lost revenue.
Subscription state lives on the server and changes only on confirmation from the payment platform. Two tiers for each of the two roles, a grace period so a failed charge does not lock a paying user out overnight, and purchase restore for device changes.
Paid access is not granted or lost by accident, and billing questions stop turning into engineering investigations.
📍The Cloud Bill Is an Architecture Decision
"Find a coach near me" is the most expensive query in this product, and it is easy to write a version that works perfectly in testing and then quietly eats the infrastructure budget as the audience grows. Founders usually meet this problem as a bill rather than as a design choice.
Geo search was designed against a cost target from the start. Radius, filters, sorting and pagination are shaped so the read volume per search stays bounded instead of scaling with the user base.
Running cost stayed predictable as usage grew, and the client never had to choose between the feature and the bill. Cheap to build and expensive to operate is not a saving.
Feature highlights
Geo Search & Map
Radius search from current location, filters, multiple sort orders, infinite scroll, map view, favourites
Session Lifecycle
Create, apply, host confirmation, group joins, comments, edits and cancellation. States advance on time, with no admin action
Mutual Ratings
Post-session ratings both ways, aggregated reputation, reminders, host confirmation that the session happened
Chats & Communities
Direct and group chats, communities, attachments, read receipts, mute, favourites, deletion
Two Subscription Tiers per Role
Paid tiers for players and coaches, grace period on failed payment, purchase restore, one-off paid boosts, referral programme
Coach Tools
Slot scheduling, contact requests from players, plan-based limits, earnings and activity stats
28 Notification Scenarios
Invitations, replies, confirm and rate reminders, reactivation and service messages, with grouping and quiet hours
Two Isolated Environments
Staging and production with separate data, icons and names, both installable side by side on one phone