LiveTwo players tap the same court at the same second. Only one should win.
TapNGame is a sports venue booking and pickup-game platform I founded, built, and operate in Metro Vancouver. It's live on the App Store, Google Play, and the web. This is the story of what it took.
founded it, coded it, answer the support inbox — all meBooking a court in Vancouver meant phone calls and dead group chats.
Every racquet-sports player here knows the routine: call the venue during business hours, squint at a screenshot of a spreadsheet someone posted to WhatsApp, or just show up and hope. The systems that did exist were built for the venue's front desk, not for the player holding a phone.
I was the frustrated user. I wanted to play at 7, not administrate at 6. So I built the thing I kept wishing existed.
Three products that share one backend.
The player app (iOS and Android, Flutter) — find courts, book a slot in about thirty seconds, join pickup games with waitlists that auto-promote, message hosts, pay with Apple Pay or Google Pay.
Venue Manager — the operator dashboard at partners.tapngame.com: booking calendar, courts and pricing, memberships, leagues, staff, coupons, ticket scanning, financials, and analytics an owner can actually act on. Venues onboard themselves and take bookings the same day.
Admin console — the platform side: moderation, banners, feature flags, audit trails. The lens that keeps the marketplace safe and accountable.
Two people want the same court. The database decides.
The failure mode every booking system gets wrong: two players tap the same 7 p.m. slot within the same second, both see "confirmed," and someone shows up to an occupied court. In a marketplace with money attached, that mistake costs you the venue's trust, not just the player's.
The fix lives in Postgres, not the UI: row-level FOR UPDATE locks on the slot, a lock-on-tap hold while you check out, and idempotent restore-on-cancel triggers so a refunded slot comes back exactly once. One tap wins. The other player gets an honest "taken" — and the next open time.
Payments either reconcile or they rot.
Stripe makes charging a card easy. What it doesn't give you for free is integrity: payments that succeed after the app crashed, webhooks that arrive twice, refunds mid-dispute, a price the client claims that the server never agreed to.
TapNGame is PaymentIntent-first with idempotent webhook handling and server-side price validation. Refunds, disputes, memberships, and orphaned-payment recovery all flow through one ledger discipline: money in matches money out, every time. Apple Pay and Google Pay sit on top; the guarantees live underneath.
The right nudge, in the right hour, exactly once.
Sports apps either spam you or go silent when the one message that mattered — "your 7 p.m. game is confirmed" — got lost. Both failure modes kill retention.
I built an outbox-driven engine: per-user-timezone quiet hours, multi-device dedup, APNs collapse-ID idempotency. Every send is derived from state, so a retry can never mean a duplicate. It's invisible when it works, which is the point.
A real product, in real use.
Venues across Metro Vancouver are onboarded and players book daily across badminton, tennis, basketball, pickleball, volleyball, and indoor soccer. Refunds flow through Stripe. Notifications go out without spamming anyone. Pickup games fill from waitlists.
I operate the whole thing — App Store releases, the support inbox, the growth instrumentation, and the 2 a.m. pager, which is quiet because the boring engineering above got done first.
I run this end to end — product, code, payments, support.
If that's the kind of ownership you're hiring for, the about page has the longer version of how I work.
How I work