KartMetrixProduct Requirements Document
Executive Summary
Go-karting in India has 120+ commercial tracks growing at 15% annually - yet every track is a digital island. Bookings happen via phone calls, walk-ins, or inconsistently on general platforms like District and Paytm. No platform unifies discovery, booking, driver profiles, and operator analytics for Indian go-karting. KartMetrix solves this with a full-stack B2B2C platform: web and WhatsApp slot booking, real-time lap timing via RFID, driver profiles with cumulative stats, kart health monitoring, and a revenue analytics dashboard for operators.
KartMetrix is currently a concept with a clickable prototype that demonstrates the full flow. The functional MVP - real bookings, payments, WhatsApp, and RFID - is the immediate next build.
| Dimension | Detail |
|---|---|
| Product type | B2B2C marketplace + SaaS (solo build, full-stack) |
| Status | Concept + clickable prototype - functional MVP is the next build |
| Primary B2B user | Go-kart track operators in Indian Tier-1 cities (Bangalore, Delhi, Mumbai, Hyderabad, Pune) |
| Primary B2C user | Weekend go-karters, 18-35, metro-based |
| Revenue model | SaaS subscription (₹4,999-19,999/mo) + 5% booking commission + display ads (future) |
| Tech stack | Next.js · Node.js · Supabase · Razorpay · WhatsApp Business API · MQTT · Raspberry Pi 4B |
| Target Phase 1 | 10 tracks across Bangalore + Delhi within 6 months of pilot launch |
Problem Statement
Booking is fragmented and analog
80% of Indian tracks take bookings via phone or walk-in. District/Paytm listings are inconsistent. No driver can see real-time slot availability across city tracks in one place.
Drivers have no persistent identity or stats
Lap data lives in the timing software and nowhere else. No driver profile, no personal bests, no leaderboard that persists after the session ends.
Operators run blind on revenue and kart health
Revenue is approximated from cashier reports. Kart issues are discovered when drivers complain. No heatmap, no maintenance alerts, no LTV data on repeat customers.
Group and corporate bookings are painful
No single platform handles multi-person group booking, GST invoicing, and confirmation at scale. Each booking requires manual coordination.
Supporting evidence
- →Most Indian go-kart tracks have no standardised online booking - observed from reviewing 40+ track websites, Google listings, and booking pages across Bangalore, Delhi, Mumbai, and Pune
- →WhatsApp Business API now accessible without enterprise contracts - deployment friction is minimal
- →District and Paytm Insider proved online experience booking works in India - the behaviour is validated in adjacent categories
- →120+ commercial tracks in India, growing at ~15% annually post-Covid experiential leisure surge
User Personas + Jobs-to-be-Done
Rahul Sharma
Weekend Go-Karter · 24 · Bangalore
Goal: Book 4-5 slots for Saturday evening, see lap times vs friends, come back next week
Jobs to be done
→Find and compare available slots across Bangalore tracks in one place
→Book and pay instantly - no phone calls
→See my lap time vs. friends and track my improvement over sessions
Pain points
✗Googles each track separately to check availability
✗No way to track personal bests across sessions
✗Phone call booking feels uncertain - no instant confirmation
Priya Mehta
Corporate Event Organiser · 32 · Delhi
Goal: Book 1-hour exclusive slot for 15 people with GST invoice for reimbursement
Jobs to be done
→One booking flow for a large group - not calling each track
→Get a proper GST invoice for finance team
→Confirm the slot immediately, not after a callback
Pain points
✗No track has a proper group booking flow online
✗Manual invoicing requires follow-up calls
✗Can't compare price + availability across tracks simultaneously
Arjun Kapoor
Track Owner · 40 · Mumbai · 2 tracks
Goal: One dashboard showing bookings, revenue, kart health, and top customers for both tracks
Jobs to be done
→See all bookings from both tracks in one view instead of two WhatsApp groups
→Get alerts before a kart breaks down, not after a driver complains
→Know peak vs. off-peak hours to set prices and staffing accordingly
Pain points
✗Manages bookings via WhatsApp group with cashiers - chaotic
✗Discovers kart issues only when drivers report mid-session
✗Revenue visibility is approximated, not real-time
Meera Rao
Competitive Racer · 19 · Hyderabad
Goal: Track personal improvement, compare nationally with serious racers
Jobs to be done
→See my fastest lap per track and improvement trend over 3 months
→Compete on a national leaderboard, not just the local track board
→Know which sessions improved my technique and which kart produced my best lap
Pain points
✗Lap data is lost after leaving the track
✗No cross-city leaderboard exists
✗No way to identify performance patterns across sessions
Feature Scope
Core philosophy: solve the booking problem first. Every driver who books online becomes a driver profile. Every profile creates leaderboard data. Leaderboard data drives re-engagement. Re-engagement drives subscriptions and repeat bookings. The booking layer is the flywheel entry point.
V1 - Shipped
Interactive track map (Leaflet)
Map-first discovery across 28 tracks in Delhi NCR, Bangalore, Mumbai, and Pune. City filter tabs, tier-coded pins (Enterprise/Pro/Starter), "Near me" geolocation button. Tap a pin → see available slots → Book This Track pre-seeds the booking flow with track + city. Eliminates the city selector step entirely.
Web slot booking + Razorpay payment
Primary conversion surface. Real-time availability. UPI/card/net banking. Instant confirmation.
WhatsApp slot booking (Meta Business API)
Primary channel for non-app-installing drivers. Handles booking, confirmation, and cancellation end-to-end.
QR check-in tickets
Each booking generates a QR + verification code. Scanned at the gate to verify booking + payment. Eliminates name-list reconciliation.
Real-time slot + kart status
Shared state across web, WhatsApp, and walk-in blocking via Supabase Realtime. One source of truth. No overbooking.
Walk-in blocking
Staff block a kart for 1/2/3 hours for walk-in customers; it instantly leaves online availability.
Auto-release function
Unpaid holds expire after 10 min; no-shows auto-release 15 min after slot start. Postgres triggers, no manual cleanup.
Invite-only operator onboarding + RBAC
Server-side role isolation. Role column writable only via service-role key. No open operator signup.
Booking management (view, modify, cancel)
Cancel via WhatsApp up to 2 hours before. Auto-refund. Slot released immediately.
Driver profile + cumulative stats
Lap history, personal bests per track, session count, trend over time.
Post-session WhatsApp lap delivery
Auto-sent within 60 seconds of session end. Leaderboard rank + "Book next slot" CTA.
Track leaderboards (per-track)
Primary driver retention hook. Social competition drives repeat sessions.
RFID lap timing via RS-232 serial bypass
Avoids MyLaps per-crossing API fees. 10ms resolution vs 500ms via vendor API.
Operator booking dashboard
All bookings (upcoming, active, past) in one view. Manual override capability.
Kart health monitoring + maintenance alerts
Engine hours tracking, anomalous lap variance detection, maintenance log per kart.
Revenue analytics + utilisation heatmap
Sessions/day, revenue/hour, peak vs off-peak heatmap. Pricing conversation starter.
Group bookings + GST invoice
Corporate events and friend groups. GST invoice auto-generated on payment confirmation.
V2 - Roadmap
District + Paytm availability sync
Two-way sync so tracks don't manage two separate calendars.
Dynamic pricing engine
Off-peak slot price recommendations based on utilisation data.
City + national leaderboards
Cross-track rankings. "Fastest driver in Bangalore" narrative drives organic growth.
Sector time analysis
Where is a driver losing time? Corner 3 or straight speed. Competitive driver feature.
SEO landing pages per track and city
"Go karting in Bangalore" - organic acquisition layer.
Multi-track operator dashboard
Consolidated view for operators with 2+ venues.
Out of scope - V1 + V2
Native mobile app (iOS/Android)
Web-first. WhatsApp covers mobile booking. App adds App Store review cycle friction.
Booking + payments for non-karting experiences
Category-specific focus is the moat. Horizontal expansion dilutes the product.
Race replay / video sync
Camera hardware + storage cost. Demand unvalidated at current scale.
Insurance product
Regulatory complexity. Defer until V3+ and only with clear demand signal.
User Stories & Acceptance Criteria
Epic hypothesis
We believe that giving Indian drivers one place to discover and book go-kart slots - on web or WhatsApp - and giving operators a real-time view of bookings, karts, and revenue, will replace the phone-call-and-walk-in status quo. We'll know we're right when >40% of bookings at a partner track come through KartMetrix within 90 days, and operator NRR exceeds 90%.
As a weekend go-karter, I want to see available slots across tracks in my city and book instantly, so I don't have to call each track.
Acceptance criteria
- ✓Selecting a city shows all partner tracks with live slot counts
- ✓A slot can be booked and paid for via Razorpay (UPI/card/net banking) in under 90 seconds
- ✓Slot availability updates in real time so two users can't book the last slot
- ✓Booking generates a QR check-in ticket sent via WhatsApp
As a driver without an app, I want to book over WhatsApp, so I can reserve a slot in the channel I already use.
Acceptance criteria
- ✓Sending "SLOTS" returns available times with price and remaining capacity
- ✓Replying with a time and group size returns a payment link
- ✓On payment, a confirmation + QR ticket is delivered in WhatsApp
- ✓Sending "Cancel" up to 2 hours before the slot triggers an auto-refund and releases the slot
As a driver, I want my lap times after every session, so I can track improvement and feel pulled to return.
Acceptance criteria
- ✓Lap times, personal best, and leaderboard rank are sent via WhatsApp within 60 seconds of session end
- ✓The message includes a one-tap link to book the next slot
- ✓Lap data accumulates into a persistent driver profile across sessions and tracks
As a track operator, I want a live view of every kart's status, so my desk staff always know what's free, in use, or down.
Acceptance criteria
- ✓A grid shows each kart as available, in-session, walk-in, or maintenance, updating in real time
- ✓Staff can block a kart for a walk-in for 1/2/3 hours; it instantly leaves online availability
- ✓Staff can scan a QR ticket to verify booking + payment and mark a session active
- ✓A bookings ledger lists the day's reservations with verification codes and check-in state
As a track owner, I want revenue and kart-health visibility, so I stop running the business on a counter diary.
Acceptance criteria
- ✓Dashboard shows sessions/day, revenue/hour, and a peak vs off-peak utilisation heatmap
- ✓Engine-hours per kart trigger a maintenance alert at a configurable threshold
- ✓Anomalous lap variance (a kart consistently 2s+ slower than fleet) raises a check-engine alert
Booking System Specifications
Web Booking Flow
| Step | Spec |
|---|---|
| 1. Discovery | Driver selects city + date. System returns all partner tracks with live slot counts and next available slot time. |
| 2. Track selection | Track card shows: photos, distance, price/person, rating, kart types, track length, indoor/outdoor. |
| 3. Slot selection | Calendar/time grid showing available slots with remaining capacity. Slots lock for 5 minutes on selection to prevent race condition. |
| 4. Group size | Slider 1-20. System checks capacity. Group of 8+ triggers corporate invoice option. |
| 5. Payment | Razorpay checkout: UPI, card, net banking, EMI. Slot confirmed on payment_success webhook. Released on payment_failed. |
| 6. Confirmation | WhatsApp confirmation + email. Booking reference + QR check-in ticket generated. Slot removed from availability calendar. |
| 7. Day-of reminder | WhatsApp reminder 2 hours before. Includes track address, parking info, arrival instructions, and the QR ticket link. |
| 8. Check-in | Driver shows QR ticket at the gate. Staff scans → verifies booking + payment → marks session active. Used/invalid codes flagged instantly. |
Cancellation + Modification Policy
| Action | Window | Outcome |
|---|---|---|
| Cancel | >2 hours before slot | 100% refund via Razorpay. Slot returned to availability immediately. |
| Cancel | <2 hours before slot | No refund. Slot may be offered to waitlist. |
| Reschedule | Any time | Old slot released, new slot locked. No additional charge if same price tier. |
| Group cancel | >24 hours before | 100% refund for all slots in group booking. |
| No-show | N/A | No refund. Driver profile flagged after 2 no-shows. |
Third-party Integration
| Platform | Integration type | Phase |
|---|---|---|
| Razorpay | Payment gateway. Webhook-driven booking confirmation. Payout API for operator settlements. | V1 |
| Google Maps | "Book on KartMetrix" link in Google Business listing. Direct booking URL integration. | V1 |
| District (by Zomato) | Two-way availability sync via REST API. Bookings from District appear in KartMetrix operator dashboard. | V2 |
| Paytm Insider | Listing sync. Availability state shared. KartMetrix as source of truth. | V2 |
WhatsApp Integration Specifications
Why WhatsApp is the primary booking channel
530M+ Indian WhatsApp users. 95%+ delivery rate for opted-in messages vs 60% push notifications. Zero app install friction. Post-session lap delivery in the 5-minute adrenaline window achieves 40%+ re-booking click rate. The window closes the moment a driver has to install an app.
Message Types + Cost
| Type | Use case | Cost |
|---|---|---|
| Template message | Booking confirmations, reminders, lap delivery - sent outside 24-hour window | ₹0.33-0.78 per 24hr conversation window |
| Session message | Conversational booking flow within 24hrs of user-initiated contact | Free |
| Interactive buttons | Quick-reply options for slot selection, cancellation confirmation | Within session cost |
WhatsApp Booking Flow Spec
| Driver message | Bot response | Next step |
|---|---|---|
| "SLOTS" or "Book" | Shows today's + tomorrow's available slots with time, capacity remaining, and price | Driver replies with preferred time |
| Time preference | Confirms slot, asks for group size | Driver replies with number |
| Group size | Shows total price, sends Razorpay payment link (expires in 10 minutes) | Driver pays |
| Payment confirmed (webhook) | Sends booking confirmation with reference, date, time, address, and parking | Booking created in system |
| "Cancel" + reference | Confirms cancellation eligibility, asks for confirmation | Driver confirms |
| Cancel confirmed | Processes cancellation, initiates refund, sends confirmation | Slot released |
Post-session Lap Delivery Spec
| Parameter | Spec |
|---|---|
| Trigger | Session end event from RFID edge device via MQTT. Fires within 5 seconds of last crossing. |
| Delay | Lap calculation + message composition: <60 seconds from session end. |
| Content | Fastest lap, personal best (new PB flag if applicable), leaderboard rank, full leaderboard link, "Book next slot" quick-reply button. |
| Opt-in | Captured at first booking. Driver must provide phone number. Opt-out available at any time via "STOP". |
| Kart normalisation | Lap times tagged with kart ID. Leaderboard separates by kart class to ensure fair comparison. |
Operator Dashboard Specifications
Dashboard Design Principles
4 numbers, not 40
The operator persona is a family-business owner checking an iPad behind the counter once a morning. Overwhelming the dashboard with 8 charts increases support burden and churn risk. V1 shows: sessions today, revenue today, utilisation rate, and maintenance alerts. One actionable recommendation adjacent to each metric.
Real-time Kart Status Grid + Walk-in Management
| Feature | Spec |
|---|---|
| Status grid | Live grid of every kart with one of four states: Available (green), In-session (blue), Walk-in (amber), Maintenance (red). The default screen desk staff keep open. Supabase Realtime + 30-second polling fallback for connectivity gaps. |
| Walk-in blocking | Staff tap a free kart → "Block for walk-in" → choose 1/2/3 hours. The kart instantly leaves online availability across web and WhatsApp. Auto-unblocks at the chosen duration or on manual release. |
| QR scanner | Operator scans a driver's QR ticket via the dashboard camera. Validates booking reference + payment status. Marks session active. Already-used or invalid codes flagged immediately. |
| Bookings ledger | Daily list of all reservations: time, group size, verification code, payment status, and check-in state. The operational source of truth for the day. |
| Manual booking | Staff create a booking directly (phone or walk-in conversion) from the dashboard - appears in the same ledger and availability state. |
Roles + Onboarding
| Aspect | Spec |
|---|---|
| Roles | customer (driver), operator (track staff/owner), super-admin (KartMetrix team). All signups default to customer. |
| Role security | The role column is protected by RLS and writable only via the service-role key on the server. A client can never escalate its own role. |
| Operator onboarding | Invite-only. Super-admin sends an invite → operator completes setup (password, track details, first venue) at a scoped onboarding URL. No open operator signup. |
| Why invite-only | Controls listing quality, prevents fake tracks, and ensures every operator has been verified before going live. |
Kart Health Monitor Spec
| Feature | Spec |
|---|---|
| Engine hours tracking | Each kart accumulates engine hours from RFID session data. Configurable maintenance threshold (default: 40 hours). Alert fires when kart approaches threshold. |
| Anomalous lap variance | If kart X laps consistently 2+ seconds slower than fleet average across 10+ sessions, alert fires: "Kart 7 performance anomaly - check engine." Threshold configurable by operator. |
| Maintenance log | Operator logs each service: date, type, cost, technician. System calculates cost-per-engine-hour per kart. Identifies underperforming karts. |
| Kart class split | Lap times normalised by kart class (junior/standard/pro). Leaderboards split accordingly. Anomaly detection is class-scoped. |
| Fleet view | All karts in one view with health score (Green/Amber/Red), engine hours, days since last service, and pending alerts. |
Pricing Tiers
| Tier | Price | Target | Key inclusions |
|---|---|---|---|
| Starter | ₹4,999/mo | Indoor, mall, small tracks | Analytics dashboard, leaderboard, WhatsApp lap delivery, basic booking dashboard |
| Pro | ₹9,999/mo | High-volume outdoor tracks | All Starter + WhatsApp booking, kart health monitor, revenue heatmap, customer CRM, Google Maps integration |
| Enterprise | ₹19,999/mo | Chains, academies, large venues | All Pro + dynamic pricing, multi-track dashboard, API access, custom WhatsApp number, dedicated onboarding |
Technical Architecture
| Layer | Technology | Responsibility |
|---|---|---|
| Hardware | AMB/MyLaps RFID transponders + RS-232 serial | Lap crossing detection at 10ms resolution. Serial bypass avoids vendor per-crossing API fees. |
| Edge device | Raspberry Pi 4B + Go daemon + SQLite buffer | Serial parsing, MQTT publish with QoS 2, local buffer during connectivity drops. ~₹8,000/unit. |
| Message broker | MQTT (Mosquitto) + QoS 2 | Guaranteed exactly-once delivery. Handles 4G outages at semi-urban tracks. |
| Backend | Node.js + Supabase (Postgres + Realtime) | Lap processing, booking logic, RLS for multi-tenant + role isolation, Realtime for live slot/kart status, Postgres triggers for auto-release of expired holds and no-shows. |
| QR check-in | qrcode generation + camera-based scanner | Booking generates a signed QR + verification code. Operator scans to validate booking + payment and mark session active. |
| Payments | Razorpay | UPI, cards, net banking, EMI. Webhook-driven confirmation. Payout API for operator settlements. No PCI data touches KartMetrix. |
| Meta Business API + webhook receiver | Template messages (confirmations, lap delivery), session messages (booking flow). ₹0.33-0.78/conversation. | |
| Web | Next.js + Tailwind CSS | Driver booking, track discovery, driver profiles, leaderboards. Operator dashboard. |
| Hosting | Vercel (web + API) + Supabase (DB) | Both on free tiers at current scale. Scale triggers at ~1,000 concurrent users. |
The RS-232 serial bypass
MyLaps charges per-crossing API fees. At 120 sessions/month × ~60 crossings/session = 7,200 events/month. At scale, this erodes the ₹9,999/month subscription margin before factoring in hosting. Reading directly from the RS-232 serial port - the same port the MyLaps software reads - drops latency from 500ms to 10ms and removes the per-transaction cost entirely. Trade-off: proprietary serial protocols require Go parsers for AMB and MyLaps formats. One-time engineering overhead per hardware generation.
Monetization Model
Status: concept + prototype, functional MVP coming soon
No revenue generated yet. All figures below are model projections based on SaaS comp analysis and booking platform benchmarks. Not current actuals.
| Revenue stream | Model | Timing |
|---|---|---|
| SaaS subscription | ₹4,999-19,999/month per track. 90-day free pilot, then standard pricing. | V1 - active |
| Booking commission | 5% per online booking (web or WhatsApp). Paid by driver on top of slot price. | V1 - active |
| Display advertising | Google AdSense on discovery, city, and leaderboard pages. Passive income as SEO traffic grows. | V2 |
| Corporate event packages | ₹10,000-50,000 per event. KartMetrix coordinates multi-slot group bookings with invoicing. | V2 |
| Premium driver subscription | ₹199/month for sector analysis, national rankings, performance trends. | V3 |
| B2B white-label | White-label platform for karting chains (Smaaash) and motorsport academies. | V3 |
Illustrative model - 20 Pro tracks (target, not actuals)
₹2,00,000
SaaS MRR
20 × ₹9,999
₹40,000-80,000
Booking commission
~1,000 bookings × ₹400 avg × 5%
~₹25,000
Infra cost
Hosting + WhatsApp API + MQTT
~88%
Gross margin
At 20 Pro tracks
~9 months
Operator hardware payback
RFID install + Raspberry Pi at Pro plan
~₹1.44 Cr ARR
TAM ceiling (India)
~120 commercial tracks at 100% penetration
TAM ceiling is explicitly not venture-scale. KartMetrix is positioned as a profitable niche SaaS, not a unicorn play. The honest ceiling is acknowledged as a design constraint.
Cash Flow & Unit Economics
Status: pre-revenue, near-zero burn
KartMetrix is a concept with a clickable prototype; the functional MVP is coming soon. No product is in market and no tracks are paying yet. The model below shows what the business is designed to earn once the MVP ships and tracks come online. All figures are projections, not actuals.
| Monthly (modelled) | 5 tracks | 15 tracks | 28 tracks (Phase 1 target) |
|---|---|---|---|
| Mix assumption | All Pro | 10 Pro · 3 Starter · 2 Ent | Tier-weighted (~₹10.7K avg) |
| SaaS subscription MRR | ₹50,000 | ₹1,34,970 | ₹3,00,000 |
| Booking commission (5%) | ~₹15,000 | ~₹60,000 | ~₹1,40,000 |
| Gross monthly revenue | ~₹65,000 | ~₹1,95,000 | ~₹4,40,000 |
| Infra + WhatsApp + payments | ~₹12,000 | ~₹30,000 | ~₹55,000 |
| Net monthly contribution | ~₹53,000 | ~₹1,65,000 | ~₹3,85,000 |
| Annualised run-rate | ~₹6.4L | ~₹19.8L | ~₹46.2L |
Booking commission assumes ~150-250 online bookings/track/month at a ₹400 average slot value. At the 28-track Phase 1 target, run-rate (~₹46L) sits comfortably inside the ~₹1.44 Cr TAM ceiling - this is a deliberately modest, defensible niche, not a hockey-stick.
Operator unit economics
Hardware economics (per track)
Business Model Canvas
Value Proposition
- For drivers: discover + book any track on web or WhatsApp in under 90 seconds, with lap stats and a leaderboard that persist across visits
- For operators: one dashboard for bookings, live kart status, walk-in blocking, kart health, and revenue - replacing the WhatsApp-group-and-diary status quo
- The only go-karting-native platform in India - not a generic experience-booking listing
Customer Segments
- Track operators (B2B buyer) - family-run venues in Tier-1 cities
- Weekend drivers (B2C) - 18-35, metro, casual
- Corporate / group organisers - team outings, birthdays
- Competitive racers - want stats, sector times, rankings
Channels
- Direct sales to operators (Phase 1)
- Operator-driven: every booking onboards a driver
- SEO landing pages per track + city
- Google Maps "Book on KartMetrix" links
Key Resources
- RS-232 serial bypass (avoids MyLaps per-crossing API fees)
- Real-time availability engine (no overbooking across web/WhatsApp/walk-in)
- WhatsApp Business API integration + booking bot
- Operator relationships in Phase 1 cities
Key Partners
- Razorpay - payments + operator payouts
- Meta - WhatsApp Business API
- AMB / MyLaps - existing timing hardware at tracks
- District / Paytm Insider - availability cross-listing (V2)
Cost Structure
- WhatsApp conversation costs (≤₹3/booking)
- Razorpay payment fees (~2%)
- Supabase + Vercel (free tier early, ~₹3-4K/mo at scale)
- Edge hardware (~₹8K/track, one-time)
- Founder time - sales, onboarding, support
Revenue Streams
- SaaS subscription ₹4,999-19,999/mo (primary)
- 5% booking commission (primary)
- Display ads on discovery pages (future)
- Corporate event packages (future)
- Premium driver subscription ₹199/mo (future)
Go-to-Market Strategy
B2B-first GTM: sign operators, drivers follow
One track going live means every driver who books there becomes a KartMetrix user. No cold-start problem on the driver side if the operator side is seeded correctly. Phase 1: direct sales, free pilot. Phase 2: self-serve onboarding. Phase 3: chain partnerships.
| Phase | Cities | Timeline | Strategy | Gate |
|---|---|---|---|---|
| Phase 1 | Bangalore + Delhi | Month 1-4 | Direct sales. 10 tracks. 90-day free pilot (5% commission only). Target: IndiKarting, Grips, F9 Gurgaon, Turbo Drift. | 8/10 tracks renew post-pilot |
| Phase 2 | Mumbai + Hyderabad + Pune | Month 5-9 | Self-serve onboarding. Remote setup. District/Paytm integration. 20 tracks. SEO pages per track. | 40%+ bookings via KartMetrix vs walk-in/phone |
| Phase 3 | Chennai + Kolkata + all Tier-1 | Month 10-18 | Chain partnerships (Smaaash, Timezone). Enterprise plan. National leaderboard. Corporate event packages. | 100+ tracks · 10,000+ driver profiles |
Competitive Positioning
| Competitor | Category | KartMetrix position |
|---|---|---|
| District / Paytm Insider | General experience booking | Partner, not competitor. Tracks can list on both. KartMetrix adds the layer they don't have: driver profiles, lap data, kart health. |
| RaceFacer | European lap timing platform | Validates the category globally. No India presence, no WhatsApp, no booking. We own India. |
| MyLaps / AMB | Timing hardware vendors | Hardware partners. We build the digital layer they don't. RS-232 serial bypass removes vendor API dependency. |
| Phone call / walk-in | Current default (80% of tracks) | The baseline. Every track converted from analog booking is a clear win. Extremely low bar to beat. |
Success Metrics
All targets below are for 6 months post-pilot launch. Not current actuals.
| Layer | Metric | Target | Why it matters |
|---|---|---|---|
| North Star | Online bookings / month | 1,000+ by month 6 | Measures if KartMetrix is actually replacing phone calls - not just collecting sign-ups. |
| Operator | Net Revenue Retention at 12 months | >90% | Operator churn is the existential risk. Sub-90% means the product doesn't solve a real pain. |
| Driver | WhatsApp opt-in rate | >80% of bookers | The re-engagement loop only works if drivers opt in to lap delivery. |
| Driver | D30 re-booking rate | >35% | Measures whether post-session engagement (lap times, leaderboard) actually drives return visits. |
| Operator | Utilisation improvement at 90 days | +15% vs. pre-KartMetrix baseline | If online booking doesn't move off-peak utilisation, the operator value prop is weak. |
| Revenue | Pro plan upgrade rate from Starter | >20% within 6 months | Measures whether WhatsApp booking + kart health creates upgrade pull. |
Guardrail Metrics
Things that must not regress while we chase the targets above:
| Guardrail | Threshold | Why |
|---|---|---|
| Booking checkout completion | ≥85% of started bookings complete payment | If a redesigned flow or commission charge tanks completion, we are losing real revenue to chase sign-ups. |
| Double-booking incidents | 0 per month | Walk-in blocking + real-time availability exist to guarantee this. Any overbooking erodes operator trust instantly. |
| QR check-in failure rate | <1% of valid tickets | A driver who paid being turned away at the gate is a catastrophic experience. Scanner reliability is non-negotiable. |
| Operator support tickets / track / week | ≤2 | Rising support load signals the dashboard is too complex and threatens the thin-team operating model. |
| WhatsApp cost per booking | ≤₹3 | Message cost must stay well under the 5% commission per booking, or unit economics invert. |
Risks + Mitigations
Small TAM ceiling (~120 commercial Indian tracks)
CriticalAt 100% penetration, ARR is ~₹1.44 Cr - not venture-scale. This product is positioned as a profitable niche SaaS, not a unicorn play. The ceiling is acknowledged and accepted as a design constraint. Expansion to adjacent categories (laser tag, escape rooms) is a V3+ option if karting TAM is fully penetrated.
Operator adoption friction (tech-literacy gap)
HighTrack owners are often family-business operators, not tech-forward. Mitigation: 90-day free pilot removes financial risk. White-glove onboarding (remote setup, video walkthrough, Hindi-language support). Dashboard deliberately minimal - 4 numbers, not 40. One-click WhatsApp daily summary as alternative to dashboard logins.
WhatsApp API rate limits and message cost at scale
HighWhatsApp conversation-based pricing (₹0.33-0.78/24hr window) is sustainable at early scale but could erode margins at high volume. Mitigation: batch lap delivery (one message per session, not per lap). Opt-out reduces cost from non-engaged users. Model includes WhatsApp cost in infra projection.
RFID hardware compatibility (AMB vs MyLaps protocol differences)
MediumIndian tracks use both AMB and MyLaps hardware. Both have different serial protocols. Edge device Go daemon must implement parsers for both. Risk: undiscovered edge cases in protocol parsing cause lap data loss. Mitigation: edge device logs every raw serial event. Failed parses trigger an alert rather than silent failure.
District/Paytm refusing or delaying integration
MediumTwo-way availability sync requires their API cooperation. If they decline, KartMetrix cannot prevent double-bookings for tracks listed on both platforms. Mitigation: Phase 1 tracks should exclusively use KartMetrix for online booking. District/Paytm integration negotiated as a Phase 2 unlock.
Driver cold-start on leaderboards
LowEmpty leaderboards at launch provide no competitive incentive. Mitigation: pre-seed with historical timing data from MyLaps software export where available. Minimum 10-driver leaderboard before track goes live. Consider pre-seeding with anonymised times from beta testers.
Dependencies
| Dependency | Type | Status / risk |
|---|---|---|
| WhatsApp Business API (Meta) | External | Requires a verified business + approved message templates. Approval can take days to weeks. On the critical path for the WhatsApp booking channel. |
| Razorpay (payments + payouts) | External | Live integration needs a registered business entity + KYC. Standard onboarding; low risk but blocks real money flow. |
| RFID hardware at the track (AMB/MyLaps) | External / per-track | Lap timing depends on existing transponder hardware. Tracks without it need install before go-live. Edge device (Raspberry Pi) is procured and flashed per track. |
| District / Paytm APIs | External | Two-way availability sync (V2) depends on their partner API access. Not on the V1 critical path; Phase 1 tracks use KartMetrix exclusively for online booking. |
| Track operator onboarding | Partner | Each track must provide slot structure, pricing, kart inventory, and a WhatsApp number. White-glove setup for the first cohort. |
| Supabase + Vercel | Technical | Database, auth, realtime, and hosting. On free tier at current scale; no blocker until ~1,000 concurrent users. |
Launch Plan
| Phase | Timeline | Focus | Gate |
|---|---|---|---|
| Concept + Prototype (current) | Done | Clickable prototype demonstrating the full flow - discovery, booking, QR, operator grid. | Demo live at kartmetrix.vercel.app |
| Build functional MVP | Month 1-3 | Wire up real bookings, Razorpay, WhatsApp Business API, and RFID at one pilot track. Turn the prototype into a working product. | One track taking real online bookings |
| Phase 1 expansion | Month 3-4 | 10 tracks across Bangalore + Delhi. Self-serve onboarding flow. WhatsApp booking live. | 8/10 tracks renew after pilot |
| District/Paytm sync | Month 5 | Two-way availability integration with District and Paytm. Cross-listing eliminates double-booking. | Zero double-booking incidents for 30 days |
| Phase 2 cities | Month 5-9 | Mumbai + Hyderabad + Pune. SEO pages per track. National leaderboard launch. | 30+ tracks, 1,000+ driver profiles |
| V2 features | Month 6-9 | Dynamic pricing engine, sector analysis, corporate event packages, premium driver subscription. | MoM booking growth ≥20% |
Open Questions
Unresolved decisions that need validation through pilot data or operator conversations before they're locked in.
?Who pays the 5% booking commission - the driver or the operator?
Charging the driver on top keeps operator margin intact but adds checkout friction. Splitting from operator revenue is cleaner for the driver but a harder operator sell. Needs to be tested with the first pilot tracks.
?Does WhatsApp booking need an LLM, or is a rule-based flow enough?
A deterministic flow is reliable and cheap for the money path. An LLM concierge could handle fuzzy queries ("track near Whitefield under ₹600") but shouldn't touch payment. Leaning rule-based for V1, LLM as a V2 discovery layer only.
?How do we handle the leaderboard cold-start at a new track?
Empty leaderboards have no competitive pull. Option: pre-seed with historical timing data exported from the track's existing MyLaps software. Needs a minimum-driver threshold before a track goes live.
?Free pilot length - 90 days or shorter?
90 days removes financial risk and gives data to prove utilisation lift. But it delays revenue and may attract non-committed operators. Open question on the right pilot-to-paid conversion gate.
?Should District/Paytm integration be Phase 1 or Phase 2?
Phase 1 tracks could be KartMetrix-exclusive for online booking to avoid double-booking complexity. But operators already on District may resist exclusivity. Sequencing TBD based on operator feedback.