Jasiri

0What this document is

The full opportunity space for Jasiri: what it is, how it makes money, how it is built, and what has to be true for it to work. It maps the whole surface rather than scoping a first release, because the decisions that matter most — the data model, the payment architecture, the consent structure — are the ones that are expensive to revisit later.

Where a number is an assumption rather than a measurement, it is labelled as such. Sequencing appears in Section 15. Everything before it is the map, not the route.

1Executive summary

Nairobi has courts, pitches and studios. It has people who want to play. What it lacks is the thing that turns those two facts into a game on a Saturday morning. Games die in WhatsApp groups on Friday evening because eight of the ten needed players confirmed, and one person gave up chasing the other two.

Jasiri makes games happen. It answers two questions and treats everything else as support: what can I play that I would actually enjoy, and can I get enough people there to play it.

The game is the atomic unit. A specific sport, at a specific place, at a specific time, needing a specific number of people. Every write in the system resolves to a game. Venues are inventory beneath it. A user's week is the surface above it.

Basketball builds it. Padel funds it. Jasiri's community, credibility and first 150 to 200 users are in basketball, which makes it the cheapest place to prove the coordination loop with people who will say plainly when it fails. Padel reuses the same mechanics against far better economics. Fitness classes add frequency, touch rugby and 5-aside add volume, and group outings add margin.

Payments are the wedge. Splitting a court fee across ten people, holding a deposit, backfilling a dropout and refunding the difference is the part everyone hates and nobody has built properly here. Jasiri runs both direct settlement and custodial escrow, routing each booking to the right one. An organiser who never fronts money again does not go back.

The position is defensible on both sides. Venues buy yield rather than listings: no operator in Nairobi is short of demand at 6pm on Saturday, but they are empty at 2pm on Tuesday, and Jasiri sells the dead hours before buying blocks outright and carrying the fill risk itself. Users are held by something a competitor cannot purchase. Preference models are copyable; a verified record of who actually shows up, and a paid network of the people who make games happen, are not.

Revenue rests on three pillars: off-peak yield, corporate wellness contracts, and brand-sponsored open slots, with twenty-five further lines mapped in Section 10. Consumer subscriptions are excluded because the core loop has to be free to reach liquidity. Betting is excluded because it would change what Jasiri is.

Three things would kill it: supply too thin to fill the matches it promises, no-shows eroding trust faster than the platform can build it, and a data model that assumed consent it never asked for. Each has a designed answer, in Sections 9, 4.5 and 13 respectively.

2The problem

2.1 What actually goes wrong

Take a typical Nairobi 5-aside crew. There is a WhatsApp group of about thirty people. One person, usually the same person, does all of the following every week, unpaid:

1. Proposes a day and time
2. Chases confirmations, often individually
3. Calls or WhatsApps the venue to check availability
4. Books and frequently fronts the money
5. Chases reimbursement, usually incompletely
6. Handles the two drop-outs on the day
7. Decides whether to cancel

Any one of these failing kills the game. Step 6 kills more games than all the others combined. Step 5 is why organisers eventually burn out and stop.

Note what is not on this list: finding a venue they didn't know about, and comparing prices. Discovery is not the bottleneck. This matters because most sports apps are built as discovery products and then wonder why retention is poor.

2.2 The corollary

Jasiri is a coordination product with discovery attached, not a discovery product with coordination attached. That ordering drives everything downstream: the home screen, the notification model, the data schema, and the revenue model all resolve differently because of it.

2.3 The four user problems

P3 is the most universal and the least visible. It is the residue of P1 and P2 — the chasing, the remembering, the deciding, the apologising — and it persists in verticals where the other three do not. It is also the problem Jasiri monetises most directly, through the organiser programme in Section 5.3, because solving it converts the person who makes games happen into someone with a reason to stay.

P4 is what most sports apps are built for. It is real, and it is last. A solo player cannot join a game that nobody organised, which makes discovery dependent on P1 through P3 being solved first, for other people, before it can be solved for them.

2.4 Which problems each vertical actually has

The four problems are not evenly distributed. Building as though they were produces features that solve nothing in half the portfolio.

Three consequences the plan has to absorb.

Basketball may not exercise P2. Much of Nairobi basketball runs on free or cheap public and school courts, and where there is no fee there is nothing to split. Since basketball is the first build and payments are the wedge, this is a live gap rather than a footnote. Section 12.1 resolves it by seeding deliberately at paid venues — indoor courts, fee-charging school courts, league fixtures — and by running one group outing early with the seed cohort, since outings are the most acute payment case in the portfolio and require no matching to test.

Fitness classes only touch P4. No roster threshold, no split, no organiser. They are a discovery and habit vertical, which is why Section 3.3 assigns them frequency and retention rather than validation of the core loop.

Group outings invert the profile. P2 and P3 at their most severe, P1 modified into headcount uncertainty rather than a fixed minimum, and P4 absent entirely because nobody joins a stranger's birthday paintball. This is precisely why outings are the strongest demonstration of the payments product and no demonstration at all of matching.

The one problem present everywhere is P3. Every vertical in the portfolio, including the ones with no roster threshold and no money to split, has someone doing unpaid coordination work. That makes the organiser the most consistent customer Jasiri has, and it is the reason Section 5.3 treats organisers as supply rather than as users.

3Market opportunity

3.1 Basketball: the starting point

Jasiri already has a basketball community and a team. This is the single most valuable asset in the business, and Jasiri builds on it first.

Basketball gives Jasiri 150–200 warm first users, credibility with players, existing relationships with courts, and a sponsorship story that already works. Starting anywhere else means paying for all of that.

What basketball does not give is easy monetisation. Much of Nairobi basketball happens on free, cheap, public or school courts, which means low commission per game and weak venue leverage. That is acceptable, because the job of the first sport is not revenue. It is to prove that the coordination loop works with real people who will tell you honestly when it doesn't.

What basketball proves (P1, P3 and P4):

• That crews will move their weekly game onto Jasiri
• That the shared game link outperforms a WhatsApp roll call
• That reliability scoring changes no-show behaviour
• That auto-backfill saves games that would otherwise die
• That organisers will use the tooling and value the revenue share

What basketball will not prove on its own (P2). Where the court is free, there is nothing to split, and the payments product goes untested by the vertical that carries the first cohort. Section 12.1 closes this deliberately rather than leaving it to chance: seed at paid courts where they exist, and run one group outing early, since outings are the sharpest payment case in the portfolio and need no matching to test.

Format: 3v3 is the format that fits fill mechanics. Small roster, half-court, short games, natural rotation. Full-court 5v5 is a partial-fill format at best, and it is the more common social format, so both need supporting.

The discipline this requires. Basketball validates; padel monetises. Once the loop is proven, Jasiri moves to padel rather than waiting for basketball to become profitable, which it largely will not. The threshold for that move is defined in advance, not negotiated when it arrives.

3.2 Padel: the revenue engine

Padel follows basketball because it monetises where basketball cannot, while reusing the same mechanics almost unchanged.

Why it fits Jasiri specifically:

• Fixed roster of four. One stranger is 25% of the group, and one no-show is recoverable by a single backfill.
• Skill mismatch distributes rather than concentrates. A weaker padel partner loses points; a weak goalkeeper ruins the game for nine people.
• Hard time boundary. Courts are booked by the hour, giving every session a clean start and end.
• Negligible injury exposure from mismatch. Non-contact, enclosed, low collision risk.
• High price point, which makes commission on a booking meaningful.
• Acute off-peak problem. Courts are consistently described as busiest on evenings and weekends, which is exactly the condition that makes a yield product valuable.

Competitive infrastructure already exists, and it matters. Nairobi has a functioning tournament calendar. The Carrefour Open at Networks Padel Village drew more than 250 athletes in June 2026, and Networks Open Season 2 ran in August 2026 with a prize pool above KES 600,000 across nine categories spanning Beginner, Intermediate, Advanced and Elite.

Three consequences for the product. Nine skill bands already exist in the wild, which tells Jasiri what granularity players themselves find meaningful. A competitive layer is generating public rankings, which is usable seed data for matching. And the player base is large enough to have segments, which gives recommendation something to work with.

Venue universe. Known Nairobi operators include PlayOn Padel (Jaffery Sports Club, Lavington), Networks Padel Village, Zen Garden, Padel Tennis Kenya (Gigiri), Padel Point (Ngong Race Course), Padel 254 (Ngara Road), Ace Padel (Aga Khan Sports Centre), Padel Plus Sports (Karen), Duma Padel (Ole Sereni), and Padel Kenya (Westlands). Enough operators to constitute a market, few enough to sign meaningfully in a quarter.

The constraint to hold in view. Padel's Kenyan uptake skews toward expatriates and higher-income residents. Good for early monetisation, at odds with the community positioning Jasiri wants long term. Treat it as a beachhead that funds broader reach, not as the platform's identity.

3.3 Fitness classes

Structurally different from everything else in the portfolio, and worth including early for reasons that have little to do with revenue per session.

What makes it valuable:

• Frequency. The closest thing to a daily habit in the entire portfolio. Someone who does three classes a week opens the app three times a week, which no ball sport will match.
• Zero matching complexity. The instructor sets the level. There is no skill band to derive, no roster to balance, no mismatch risk. It is pure inventory fill.
• Excellent off-peak inventory. Studios and gyms have empty mid-morning and mid-afternoon classes and a strong incentive to fill them, which makes them the easiest Tier 1 venue conversation available.
• Low liability. Supervised, indoor, non-contact.
• Participation profile. Many class formats skew female, which makes this a natural place to establish the norms described in Section 8 rather than retrofitting them.

What this vertical does not prove. Fitness classes carry P4 and nothing else. There is no roster threshold, no split, and no organiser doing unpaid work, so nobody needs nine other people for a class to happen. This vertical exercises the inventory and habit half of Jasiri and none of the coordination half.

Role: a frequency and retention layer that keeps users in the app between games, and the easiest venue-side win available.

3.4 Touch rugby

A strong fit that is easy to overlook, and one with an unusual advantage.

• Non-contact by design, which removes the injury and liability objection that rules contact rugby out of stranger matching entirely.
• Mixed-gender play is normal and established in touch, not an accommodation. That makes it one of the few sports in the portfolio where women joining an open game is the default rather than something the product has to carefully engineer.
• Roster of roughly 6 a side. Too large for full fill, well suited to partial fill where a core group posts two or three open slots.
• Established social league culture in Nairobi, with existing organisers and existing groups. That means recruiting whole crews rather than individuals.
• Cheap pitch inventory, so thin margin per game, similar to 5-aside.
• Skill mismatch distributes reasonably well. A weaker player in touch costs possession, not the match.

Role: community breadth and a genuine women's-participation on-ramp. Modest revenue, high social value, and the mixed-gender norm makes it strategically more interesting than its economics suggest.

3.5 5-aside football

The largest existing informal demand and the worst coordination pain in the portfolio. It is where Jasiri would have the most impact and the least margin.

• Roster of 10 to 12. Too large for full stranger fill; ideal for partial fill.
• Skill mismatch concentrates badly, particularly in goal.
• Meaningful injury exposure, especially on hard or poorly maintained surfaces.
• Highly price sensitive, so commission per head is thin.
• Enormous volume, and the split-payment problem is at its most acute here.

5-aside is the volume play and the split-payments beachhead. It is not where early margin comes from.

3.6 Group outings: paintball, laser tag and bowling

These three belong together and apart from everything else in the portfolio. They are not sports verticals. They are an outings category, and almost every mechanic in Section 4 either does not apply to them or applies differently.

What they share:

• Venue-owned experience. The operator supplies the arena, the equipment, the marshals and the rules. Users bring nothing but people. This makes the venue relationship deeper and the inventory genuinely exclusive, unlike a court where the game is BYO.
• Occasion-driven, not habit-driven. Birthdays, farewells, team-building, holiday weekends, someone visiting from abroad. Frequency is measured in months, sometimes years. No amount of product design will make paintball a Tuesday habit.
• Large, elastic groups. Eight to thirty people. Roster size is set by who the organiser can gather, not by the rules of the game.
• Skill is irrelevant, and that is the appeal. Nobody is matched. Everyone being a beginner is the point. No skill band, no rating, no matching logic.
• No fill, ever. These are closed groups. A stranger inserted into someone's birthday paintball outing is a product failure, not a feature.
• High ticket, high margin. A single booking can be twenty people at a per-head price several times a court share. One outing can be worth more in commission than a month of 5-aside.
• Heavy ancillary attach. Food, drinks, extra rounds, equipment upgrades, photos. Often a large share of the venue's take, and available to Jasiri as attached revenue.
• The worst off-peak problem in the portfolio. Weekday daytime is close to dead. Corporate bookings are the only weekday demand these venues have, which makes them highly receptive to a partner that can generate them.

Why this category matters more than its frequency suggests

This category carries P2 and P3 at their most severe, P1 in modified form as headcount uncertainty rather than a fixed minimum, and no P4 at all. The coordination pain is the most acute in the document, worse than 5-aside. Organising an eighteen-person paintball outing means chasing headcount for a fortnight against a venue that wants a deposit and a final number, collecting perhaps KES 2,500 a head in advance from people who will pay late or not at all, deciding what happens to the four who drop out after the deposit is paid, and arranging food and transport alongside it. Someone is currently doing this on a spreadsheet and fronting several thousand shillings of their own money.

That makes group outings the strongest possible showcase for the payments product, and payments is the wedge feature. An organiser who watches Jasiri collect KES 45,000 from eighteen people, hold it in escrow, handle the four drop-outs, pay the venue and refund the difference without them fronting a shilling will use Jasiri for every other thing they organise. The outing is the acquisition event; the weekly game is the retention.

It is also the natural entry point for corporate revenue. Team-building outings are budgeted, recurring, and booked by someone in HR or operations who is exactly the person Jasiri needs to talk to about corporate wellness. The outing sells itself and opens the door to the larger contract.

How they differ from one another

Three practical consequences. Bowling is the only one of the three that supports a same-day, spontaneous booking, which makes it the one that can appear in weekly recommendations rather than only in planned events. Laser tag and bowling both routinely involve minors, which engages the policy in Section 13.3; these are closed private groups so the risk profile is different from stranger matching, but the product must handle under-18 participants explicitly rather than by omission. And paintball carries genuine, if minor, injury exposure and travel logistics, so it needs waivers and transport coordination that the other two do not.

Bowling has one further advantage: the score is already displayed on a screen at the end of every game. That is the cheapest possible capture mechanism, requiring only a photograph and OCR rather than any camera infrastructure, and it feeds directly into the post-game card described in Section 7.2. Of everything in the portfolio, bowling is the easiest place to produce a shareable result artifact.

What Jasiri actually builds for this category

Not matching. The surface is:

• Group booking with an uncertain and shifting headcount, firmed up against a deadline
• Escrow collection across a large roster, which is Rail B in Section 11.4
• Deposit handling that mirrors the venue's own deposit terms
• Add-on selection: food, extra rounds, transport
• An invitation that works for people who will never install the app
• A single settlement to the venue, and a clean reconciliation for the organiser

Role in the portfolio: high-margin, low-frequency, and the best available demonstration of the payments product. It will not build the habit loop. It will fund it, and it will recruit the organisers who do build it.

3.7 Portfolio summary

3.8 Adjacent categories worth mapping

Not for early build, but the same infrastructure serves them: tennis, climbing, swimming, martial arts, table tennis, volleyball, pickleball, hiking and trail groups, go-karting, escape rooms, cricket, and rugby sevens.

Two notes. Tennis reuses the padel machinery almost unchanged and is the most natural later addition, though club membership culture means much of its inventory is not open to a marketplace at all. Go-karting and escape rooms belong with the outings group in Section 3.6 rather than with the sports, and should be added there once that category is proven.

4The product

4.1 The three-lens model

Jasiri holds three domain objects simultaneously. Each answers a different question, and confusing them is the main design risk.

Stated compactly: the database is organised around games, the interface is organised around the week, and the business is organised around venues. Three lenses, three answers, held simultaneously and deliberately.

4.2 The Game object

The Game is the core entity. It should be rich enough that everything else in the product is a view over it.

Attributes:

• Sport and format (padel doubles, 3v3, 5-aside)
• Venue and specific court or pitch
• Start time, duration, timezone
• Roster: capacity, confirmed players, waitlist, reserved slots
• Visibility: private (invite only), friends-of-roster, community, public
• Skill band and whether it is enforced or advisory
• Fill mode: full, partial, or none
• Price per head, payment status, who has paid
• Organiser and any co-organisers
• Cancellation threshold (minimum players below which the game auto-cancels, and by when)
• Gender policy (open, women-only, etc.)
• State: draft, open, filling, locked, played, cancelled, abandoned

Game lifecycle:

DRAFT → OPEN → FILLING → LOCKED → PLAYED → SETTLED
                  ↓          ↓
              CANCELLED   CANCELLED

Two design points that matter more than they look:

The cancellation threshold is a first-class field, not an afterthought. The organiser sets, at creation, the minimum viable roster and the deadline. If the game has not reached the minimum by the deadline, it auto-cancels and refunds. This converts the single worst experience in recreational sport, showing up to a game that isn't happening, into a system guarantee. It is a small feature with disproportionate trust value.

LOCKED is a distinct state. At lock time (typically 2 to 4 hours before start), the roster freezes, payment is captured, and the venue booking becomes firm. Before lock, joining and leaving is free. After lock, leaving forfeits. Making this a visible, named moment is what makes the deposit model feel fair rather than punitive.

4.3 Fill mechanics

Fill is the mechanic borrowed from competitive gaming: press one button, get placed with strangers, start playing quickly. It is powerful and it is dangerous, because a bad stranger match is worse than no match at all.

Conditions under which full fill is safe. All four must hold:

1. Small fixed roster. One stranger is a large fraction of the group and one absence is recoverable by one backfill.
2. Skill mismatch distributes rather than concentrates. No single position can ruin the session for everyone.
3. Built-in end. Sets, points, or a booked hour. Open-ended sessions with strangers produce awkward exits.
4. Low injury exposure from mismatch. This is the one that carries legal weight, not just experience weight.

The three fill tiers:

• Full fill. 3v3 basketball, padel, pickleball, table tennis, running groups, fitness classes, climbing, swimming. One tap, placed by the system. Fitness classes are a special case: capacity fill with no matching required, since the instructor sets the level.
• Partial fill. 5-aside, 5v5 basketball, touch rugby, volleyball, cycling. An existing core group posts a small number of open slots. Existing members can approve or the slots open automatically after a delay. The customer here is the group, not the individual, which changes the whole interaction model.
• No fill. Contact sports, group outings (Section 3.6), anything involving minors, anything remote or overnight. Invite link only. Group outings are a permanent member of this tier, not a sequencing decision — a stranger placed into a private birthday outing is a product failure.

Partial fill is the workhorse. It carries most of the volume and solves cold start far better than full fill, needing two strangers per game rather than ten.

Matching inputs, in rough order of weight:

1. Skill band
2. Geographic proximity and travel tolerance
3. Time availability
4. Reliability score
5. Social graph proximity (friend-of-friend beats stranger)
6. Prior co-play history and mutual "play again" signals
7. Gender policy compliance
8. Stated intensity preference (competitive vs social)

4.4 Skill rating

Self-reported skill is unreliable in both directions, and a long skill questionnaire is an onboarding cliff. Derive it instead.

Seeding. Three questions maximum at signup: how long have you played, do you play in any league or tournament, and how would a regular partner describe your level. Coarse bands only, and explicitly marked provisional.

Refinement. Two post-game questions, asked of everyone, taking under five seconds:

• Would you play with this person again? (yes / no / neutral)
• Were they roughly at your level? (below / about right / above)

That second question is the rating signal. It is comparative rather than absolute, which is the only way people answer accurately, and it produces a relative ordering that converges toward a usable rating within a handful of games.

Import where possible. Padel tournament categories from events like the Networks Open give a public ranking anchor for competitive players, and league placements do the same in basketball and touch rugby. Use external ratings where they exist rather than rebuilding them.

Presentation. Show bands, never numbers, to users. "Intermediate" is socially survivable; "1,240" invites grinding and gaming. Keep the numeric rating internal.

4.5 Reliability, deposits and backfill

These three together constitute the trust system, and the trust system is the actual product moat.

Reliability score. Visible, portable within the platform, and non-transferable off it. Built from: attendance rate, late-cancellation rate, cancellation lead time, no-show count, and peer confirmation of attendance. Displayed as a band with a game count, so "Reliable · 34 games" rather than a percentage that invites anxiety.

This is the highest-value data asset Jasiri accumulates. Organisers will care about it more than any other number in the app, and a user with a strong reliability history is meaningfully locked in because that history does not exist anywhere else.

Deposits arrive in three stages. Requiring money from a first-time user of an unknown app in a price-sensitive market is a conversion cliff, so trust is earned before it is charged for:

1. Phase one: no deposits. Reliability score only, visible to everyone. Social pressure does the work.
2. Phase two: deposits only on games where Jasiri has itself booked and paid the venue. Frame the charge as "your share of the court," which is what it actually is, rather than as a bond against misbehaviour. Identical money, entirely different feeling.
3. Phase three: organiser-configurable deposits on any game, once the mechanic is culturally established.

Forfeits must not be revenue. The moment no-shows generate income for Jasiri, the incentives invert. Forfeited deposits should flow to the players who showed up, as credit against future games. This is also a far better story to tell, and it makes the person who was let down feel compensated rather than merely inconvenienced.

Auto-backfill. When someone drops after lock, the slot is offered automatically to a ranked waitlist: first to explicit waitlisters, then to matched users who are free and nearby, then to the wider pool. Time-boxed offers, typically ten minutes each, cascading. If backfilled, the original dropper's deposit is returned, which gives them an incentive to drop early rather than silently.

Auto-backfill is the difference between games happening and games dying. If only one thing from this section ships, it should be this.

4.6 The Week

The home surface is a user's upcoming week, not a venue directory.

Structure: a horizontal week strip with today prominent, showing confirmed games, games the user has been invited to, games filling nearby that match them, and open time that could be filled. The emotional target is the same as a calendar: a quick read of "what does my week look like, and is there a gap I want to close."

Recommendation inputs, weighted by what carries value early:

1. Proximity and travel tolerance
2. Open slots in games that are already filling (social proof plus urgency)
3. Time slots the user has historically been free
4. Sports the user has played or expressed interest in
5. Games involving people in their social graph
6. Price, including discounted off-peak inventory
7. Activity level relative to their stated goals, where wearable data exists

Points 1 through 3 carry almost all the value in year one. Points 4 through 7 become differentiating once supply is dense enough for genuine choice. Recommendation sophistication is therefore scheduled to arrive with supply density rather than ahead of it: across forty candidate activities, "near me, cheap, filling now" outperforms any inference model.

Notification model. This product lives or dies by notifications, which means restraint is a feature. Three tiers:

• Transactional, always send: game confirmed, game cancelled, you were backfilled, payment due, lock in one hour.
• Social, send by default, easily muted: someone joined your game, a friend created a game, a slot opened in a game you waitlisted.
• Discovery, opt-in and infrequent: weekly "here's your week" digest, occasional "this game near you needs one more."

The "needs one more" notification is the highest-value discovery message in the product, because it carries urgency, social proof, and a clear action. It should be rationed rather than spent.

5Community architecture

5.1 WhatsApp: augment, never compete

Every community Jasiri wants already lives in a WhatsApp group. Competing with that is a losing battle. The strategy is to augment it. But the technical constraints are severe and they shape the design, so they need stating precisely.

What the WhatsApp Business Platform actually permits:

• Businesses can send messages into groups via the Groups API, including text, media and templates, with webhooks for group lifecycle and participant events.
• Business-API groups cap at 8 participants, against 1,024 for a normal WhatsApp group.
• Members cannot be added via API. An invite link is shared and users join themselves.
• A bot cannot be inserted into a user's existing group chat. The API operates only on groups the business creates.
• Favourably: within a group, any member's message refreshes the 24-hour messaging window for the whole group, so an active game group is cheap to message.

The two-track design that follows:

Track one, existing groups. Jasiri never enters them. Instead Jasiri produces a link worth pasting. A rich preview showing sport, venue, time, price per head, spots remaining, and a live-updating roster. One tap to claim a slot. The group admin remains a human being.

This should be treated as the single most important growth surface in the product. The design objective is that pasting a Jasiri link into a WhatsApp group becomes the fastest way to organise a game, faster than typing "who's in for Saturday?" If that is true, distribution takes care of itself. Every link should carry: current roster state, one-tap join for non-users with account creation deferred until after they have claimed a slot, and a visible countdown to lock.

Track two, Jasiri-created groups. Small, ephemeral, per-game coordination groups. Eight participants is enough for a padel game (4), a 3v3 basketball game (6), or the organiser core of a larger game. It is not enough for a 5-aside roster, and the product must not pretend otherwise. These groups should be created at lock and archived after settlement.

WhatsApp's introduction of usernames helps with the privacy of identity sharing but does not loosen any of the constraints above.

SMS as the floor. Not everyone will install an app. A game link that degrades to SMS with a short URL is the difference between a crew where nine people are on Jasiri and a crew where ten people are.

5.2 Social structures

Four distinct structures, each with different visibility and permission rules:

Crew. A small private recurring group. The Tuesday 5-aside lot. Persistent roster, recurring game template, private by default. This is the most important social object in the product because it maps exactly onto how people already organise, and it makes recurring games one tap instead of a weekly negotiation.

Club. A larger public or semi-public community with a scheduled programme. A run club, a padel club, a basketball programme. Has organisers, members, a calendar, and optionally paid membership. This is the structure that supports sponsorship revenue.

Open game. A one-off with public slots. The main vehicle for fill and for meeting new people.

Event. A larger, ticketed or capacity-limited occasion. Tournaments, leagues, corporate days, group outings. Different mechanics from a Game: entry fees, brackets, fixtures, spectators, add-ons, and an elastic headcount that firms up against a deadline rather than a fixed roster. The group outings in Section 3.6 are the highest-value instance of this object, and it should be designed around their requirements rather than treated as a Game with a larger capacity.

Recurring game templates deserve special mention. Most sport is habitual. A crew that plays every Tuesday should configure that once and have the game auto-created, auto-notified, auto-booked and auto-collected each week, with only the roster needing confirmation. This is where the product stops being an app people open and becomes infrastructure they rely on.

5.3 The organiser programme

Every community has two or three people who make games actually happen. They are performing unpaid logistics labour right now, and they are Jasiri's real supply, because the scarce resource is not venues, it is organised games.

The programme:

• Formal recognition, with a visible role and profile
• A revenue share, a percentage of booking fees on games they run
• Tools: auto-collect, auto-backfill, roster management, recurring templates, waitlist control
• Free or discounted play as a base benefit
• Early access to new features and inventory
• A private channel to the Jasiri team

Why this matters strategically: it converts the most valuable users into people with a financial reason to stay, it scales games faster than venue signing scales inventory, and it creates a distributed sales force for both users and venues. An organiser with 40 people in their group is worth more than a venue.

Progression tiers, borrowing from community platforms that do this well: a casual organiser who runs occasional games, a regular organiser with a recurring crew, and a club lead running a programme with multiple sessions and paid membership. Each tier unlocks more tooling and a better revenue share.

6Identity, gamification and personalization

6.1 The vibe check

A short, playful onboarding quiz that produces a personality-flavoured identity rather than a serious preference model. The reference point is Discord's HypeSquad houses: fast, fun, cosmetic, and socially legible.

Design constraints, all of which matter:

• Under 60 seconds, maximum six questions
• Fully skippable, never a gate to the core product
• Produces a shareable result with a name and visual identity
• Re-takeable, and explicitly re-offered seasonally
• Framed as fun, never as assessment

Candidate axes (illustrative, needs real design work):

The output is a house or archetype, not a report. Something a user posts. The strategic value is that it produces an identity people will defend and display, which drives sharing and gives badges something to attach to.

6.2 Behavioural axes: the real model

The quiz is entertainment. The actual understanding of a user should be derived from behaviour, which is more accurate, costs the user nothing, and cannot be gamed.

After roughly six games, the system knows: does this person book alone or with a crew, do they repeat one sport or try many, do they play competitively or socially, are they consistent or sporadic, morning or evening, do they travel far or stay local, do they organise or attend, how does their behaviour shift with their social circle.

Critically, these are not fixed traits. The model should treat them as time-weighted and drifting, because a user's sporting identity genuinely changes with life stage, injury, social circle and season. A system that locks someone into "solo adventurer" because of what they did in month two will feel wrong by month eight. Recency weighting is not a refinement here, it is a correctness requirement.

6.3 Badges and seasons

Badges are built, and withheld until they mean something. A badge awarded for showing up twice is wallpaper. Scarcity and legibility are what make them work.

Categories:

• Participation: game counts, streaks, sport variety
• Reliability: consistent attendance, never a late cancellation, backfill hero
• Social: introduced new players, organiser tiers, crew founder
• Seasonal: time-limited challenges that expire, creating genuine scarcity
• Sponsored: brand-backed challenges, which is where this layer monetises
• Achievement: tournament results, personal bests, milestone distances

Design rules:

1. Some badges must be genuinely hard to get, or none of them mean anything.
2. Seasonal badges must actually expire.
3. Reliability badges should be the most prestigious, because they reinforce the behaviour the platform most needs.
4. No badge should be purchasable.

Seasons provide the rhythm: a themed period of roughly 8 to 12 weeks with challenges, a leaderboard, and expiring rewards. This is the structure that gives lapsed users a reason to return, and it gives sponsors a defined unit to buy.

7Data and capture

7.1 Wearables and health integration

Integrations worth building, in priority order: Strava (strongest running and cycling community in Nairobi, and an existing social graph), Apple Health, Google Fit / Health Connect, Garmin, Fitbit, and Samsung Health.

What the data enables:

• Post-game effort and intensity reporting
• Activity level relative to a user's stated goals
• Recommendation timing, suggesting lighter activity after a heavy week
• Corporate wellness reporting, which is where it acquires a paying customer
• Insurance partnerships, same logic

Non-negotiable design rule: everything must work without a wearable. Wearable data is an enhancement, never a gate. Most users will not have one, and a product that treats them as second-class has excluded its own market.

Health data is legally sensitive. See Section 13. This cannot be retrofitted.

7.2 Post-game cards

The single highest-leverage growth artifact in the product. The Strava card works because it is one image, one number, one boast, generated automatically without the user doing anything.

Rules:

• One hero stat per card, chosen by the system. Not a dashboard.
• Generated for everyone, wearable or not. Duration, sport, venue, opponents, result and a clip are enough for a card.
• Both individual and team versions. A card the whole crew posts is worth more than five individual ones.
• The wit must earn its place. "22 minutes above threshold, and you still lost 6-2" works. Generic encouragement is noise.
• Every card carries a join link. It is a growth mechanism first and a feature second.
• Fully controllable. Some people will not want their heart rate on a shareable image.

Card variants worth designing: effort summary, head-to-head result, streak milestone, personal best, first-time-at-a-venue, crew season summary, and a monthly or seasonal recap.

7.3 Clips

Jasiri captures the moment, not the scoreline. People leave a game remembering the shot they hit, and that is what they want to send to the group.

Phase one, the clip button. One camera per court, continuously buffering. A physical button at courtside and a button in the app save the preceding 20 to 30 seconds. At session end, every participant receives their clips.

Cheap, robust and immediately useful. It pays for the hardware, produces shareable content, and gives the venue free marketing.

Phase two, session reels. Automatic 30 to 60 second cuts per session, with participant tagging and music. Distribution-optimised, carrying a join link.

Phase three, lightweight capture without cameras. Photograph a bowling screen and read it, photograph a scoresheet, or enter a result through a well-designed form. This reaches the long tail of venues at near-zero cost. Bowling is the obvious first target, since the result is already rendered on a screen at the end of every game.

8Women's participation

This is treated as a design requirement running through the whole product rather than a feature, because that is what it has to be to work.

The barriers are specific: mixed pickup sport has real comfort and safety concerns; skill assumptions run against women in mixed games; some sports have thin existing female communities, so a woman may be the only one in a session; transport and timing constrain evening participation more sharply; and there is a legitimate reluctance to appear in shared photos and video.

Design responses, mapped to product surfaces:

The strategic case. This is not only the right thing to do. Women's recreational sport in Nairobi is underserved to a degree that makes it a genuine beachhead rather than a checkbox. Padel in particular has an unusually balanced participation profile compared with most sports, which makes it a good place to establish these norms early. A platform that is visibly the safest place to find a game will win a segment that competitors are not seriously contesting.

9Venue strategy and operations

9.1 The tiered pitch

"List your catalogue on our marketplace" is a weak proposition. Venues are not short of Saturday demand. They are empty on Tuesday afternoon. The pitch must be yield, and it must change as Jasiri's evidence base grows.

Tier 1 — first 10 to 15 venues. The ask is the calendar, not commitment.

Jasiri has no demand data yet, so it cannot sell fill. It sells free money on dead inventory: give Jasiri your Tuesday 2pm–5pm and Thursday mornings, at zero cost, no exclusivity, cancel anytime. Anything Jasiri books is pure upside on a slot earning nothing.

Target the venues with the worst off-peak problem, which is usually the newest and the most expensive. Bring the basketball community as proof of a real audience rather than a deck of projections.

Tier 2 — once there is data. The pitch becomes specific.

"Over the last 90 days we filled 68% of the off-peak slots you gave us, at an average of KES X per slot, from Y unique players, 40% of whom had never been to your venue before." Narrower claim than any assurance percentage, and far more credible. The new-customer statistic is often the one that closes.

Tier 3 — guaranteed minimums.

Jasiri buys a block of off-peak hours outright at a discount and carries the fill risk. The venue converts uncertain revenue into certain revenue. This is where Jasiri stops being a listing site and becomes a demand partner, and it is where the margin is. Only deploy where fill rates are proven.

9.2 Integration depth

Four levels, and depth beats breadth at every stage:

1. Listed. Venue appears; booking happens off-platform. Almost worthless; avoid.
2. Bookable. Jasiri holds a defined inventory block and books against it. Minimum viable.
3. Integrated. Jasiri sees and writes the full calendar. This is where the data becomes valuable and where dynamic pricing becomes possible.
4. Operated. Jasiri runs the schedule, payments and customer communication. Highest lock-in, and the point at which venue software becomes a saleable product.

9.3 Density sequencing

The rule: one venue per sport per neighbourhood, to full depth, before adding a second.

Two half-integrated padel courts in Kilimani is worse than one fully integrated one, because a matching product with thin supply produces empty matches, and empty matches kill an app faster than no app at all.

Suggested geographic sequence, subject to where the basketball community actually sits: start in one cluster (Westlands / Parklands / Lavington is the densest padel corridor), prove the loop, then expand to Karen / Langata, then Kilimani / Kileleshwa, then the Eastern corridor.

9.4 Venue operations playbook

Things that will consume more time than expected and should be planned for:

• Onboarding takes a physical visit. Photograph the venue, record surface and lighting conditions, confirm actual operating hours against advertised ones, meet whoever actually controls the booking diary. That person is frequently not the owner.
• Calendar truth is the hardest operational problem in this business. Many venues run on a paper diary or a WhatsApp thread. Double-bookings will happen, and the recovery process needs to be designed before it does, not after.
• Settlement cadence must be predictable. Venues will tolerate a commission far more easily than they will tolerate uncertainty about when they get paid.
• A named human contact. Venue relationships in this market run on relationships. An account manager beats a dashboard for the first fifty venues.

10Revenue architecture

Consumer subscriptions are excluded on price-sensitivity grounds: the core loop has to be free to reach liquidity. Betting is excluded because it would change what Jasiri is and would compromise the youth and community positioning.

10.1 The three pillars

Pillar 1 — Off-peak yield take rate. Standard commission on peak bookings, a materially higher take rate on off-peak inventory that was earning nothing. Works from day one, low friction, scales with volume. Progresses into block purchase at a spread once fill is proven.

Pillar 2 — Corporate wellness. The highest revenue per unit of effort available. Kenyan corporates and insurers want measurable employee engagement and have budget where consumers do not. Inter-company leagues, team challenges, an HR-facing engagement dashboard, subsidised employee play. This is where the wearable and activity data acquires a paying customer, and it converts the personalization work from a cost centre into a product.

Pillar 3 — Brand-sponsored open slots. A brand funds 30 free places at a court on a Sunday and receives measured attendance, participant demographics, and content. Jasiri already understands this business through its existing sponsorship relationships. Brand managers cannot get measurable activation from a billboard, which is precisely why this sells.

10.2 The full revenue map

Venue side

1. Booking commission on standard slots
2. Elevated take rate on off-peak slots
3. Wholesale block purchase and resale at spread
4. Venue calendar and POS software fee, once operating the schedule
5. Camera hardware lease or clip-infrastructure revenue share
6. Promoted placement in discovery
7. Payment processing margin on collection
8. Dynamic pricing and waitlist tooling as a paid module

Corporate and institutional

9. Corporate wellness contracts
10. Insurer partnerships: activity-linked benefits and premium discounts
11. School, university and academy league operations
12. County and national government youth sport programmes
13. NGO and development grant funding, particularly youth participation and women in sport
14. Corporate team-building outings: paintball, laser tag, bowling and adjacent group experiences. High ticket per booking, budgeted rather than discretionary, and the most reliable door into the corporate wellness conversation in line 9.

Brand and sponsorship

15. Sponsored open slots
16. Sponsored communities and clubs
17. Tournament title sponsorship, with Jasiri as the operating layer
18. Sponsored badges, seasons and challenges
19. Branded content from session reels

Marketplace and transactional

20. Per-booking service fee, small and visible
21. Coach, trainer and referee marketplace commission
22. Equipment rental and gear commission at point of booking
23. Tournament and league entry fees
24. Physiotherapy, recovery and injury service referrals
25. Single-session micro-insurance attach at booking

Telco and platform

26. Safaricom partnership, with Bonga points redeemable for court time. The most market-native idea on this list, and it costs Safaricom loyalty points rather than cash.
27. Data zero-rating or bundled access as a distribution deal

Data

28. Aggregate, anonymised market insight for venue operators, sports brands and planners. Genuine value, but strictly gated by Section 13.

10.3 Unit economics framework

The model to build, with real figures to be filled from the first 90 days rather than estimated now:

Per game:

Revenue     = (price per head × roster size × take rate)
              + service fees
              + attached revenue (gear, F&B referral)

Direct cost = payment processing (collection + disbursement)
              + messaging cost
              + organiser revenue share
              + support cost amortised

Contribution = Revenue − Direct cost

Per venue:

Slots offered × fill rate × contribution per game
− account management cost
− hardware amortisation (if applicable)

The variables that determine whether this works:

• Fill rate on off-peak inventory. The single most important number in the business.
• Games per user per month. Determines whether acquisition cost is ever recovered.
• Organiser leverage: how many games one organiser generates.
• Payment cost per transaction, which is non-trivial when split payments require collection and then multiple disbursements.
• Cancellation rate, which destroys both revenue and trust.

11Technical scope

11.1 Architecture principles

1. Mobile-first, network-hostile. Assume intermittent connectivity, expensive data, and mid-range Android as the modal device. Offline-tolerant reads, queued writes, aggressive payload discipline.
2. The game is the aggregate root. Rosters, payments, chat, media and ratings all hang off it.
3. Event-sourced state transitions. Game lifecycle changes should be an append-only event log. This makes disputes resolvable, refunds auditable, and reliability scores defensible.
4. Consent as a first-class schema concept. Every sensitive data point carries its consent basis and retention rule. See Section 13.
5. Payments isolated behind a service boundary. Money movement should never be entangled with product logic.

11.2 Stack

Directional rather than prescriptive, chosen for operational boredom over novelty:

• Mobile: React Native or Flutter. Cross-platform matters more than native polish at this stage, and the Android skew is heavy.
• Backend: a boring, well-understood choice. Node/TypeScript or Go. Postgres as the primary store.
• Real-time: roster state and chat need push. WebSockets plus a managed push service.
• Media: object storage with aggressive transcoding, CDN delivery, short retention windows by default.
• Search and discovery: Postgres with PostGIS is sufficient for a long time. Do not reach for a dedicated search cluster early.
• Analytics: event pipeline from day one. The behavioural model in Section 6.2 depends entirely on clean event data, and it cannot be reconstructed retroactively.

11.3 Core data model sketch

User ─┬─ ProfileVisibility
      ├─ SkillRating (per sport, provisional → derived)
      ├─ ReliabilityRecord (append-only)
      ├─ ConductRecord (separate from reliability)
      ├─ ConsentGrant[] (per data category, with basis + expiry)
      ├─ BehaviouralProfile (time-weighted, derived)
      └─ WearableConnection[]

Game ─┬─ Venue → Court
      ├─ RosterSlot[] (user, state, payment, source: invite|fill|backfill)
      ├─ Waitlist[]
      ├─ GameEvent[] (append-only lifecycle log)
      ├─ Payment (collection, splits, disbursement, refunds)
      ├─ MediaAsset[] (clips, cards)
      └─ PostGameSignal[] (skill, play-again, attendance confirmation)

Crew / Club ─┬─ Membership[]
             ├─ RecurringGameTemplate[]
             └─ Organiser[] (with revenue share terms)

Venue ─┬─ Court[]
       ├─ InventoryBlock[] (peak / off-peak, price, availability)
       ├─ IntegrationLevel
       └─ SettlementAccount

11.4 Payments: the hardest technical domain

Requirements: collect from many players for one booking, disburse to the venue, take commission, hold and release deposits, refund on cancellation, and credit forfeits to attendees.

The M-Pesa reality: there is no native split payment. The pattern is collection to a paybill or till (C2B / STK push) followed by disbursement (B2C). That means per-transaction cost on both legs, float requirements, settlement timing risk, and reconciliation complexity. Card payments should exist as a secondary rail for corporate and higher-value transactions.

Jasiri operates two payment rails and routes each booking to the appropriate one.

Rail A — pass-through. Payment routes directly to the venue's own collection account; Jasiri reconciles and invoices commission separately. No user funds are held, so regulatory exposure and float cost are minimal. The trade-off is a thinner product: no deposits, no platform-guaranteed refunds, no forfeit credits, and reconciliation risk sits with Jasiri.

Use for: venues with their own established paybill and a preference for direct settlement; low-value single-payer bookings; early relationships where Jasiri has not yet earned the right to hold money; any venue unwilling to wait on a settlement cycle.

Rail B — custodial escrow. Funds are collected into an escrow account operated by a licensed custodian partner, held until the game reaches its terminal state, then disbursed to the venue net of commission. Jasiri instructs the movement of money; the custodian holds it. This keeps the regulatory burden with the party licensed to carry it while giving Jasiri the full product surface: deposits, cancellation guarantees, instant refunds, and forfeit credits routed to the players who showed up.

Use for: split payments across a roster; any game with a deposit or cancellation threshold; Tier 3 block-purchase inventory where Jasiri carries the fill risk; corporate and tournament bookings; anything where a refund guarantee is part of the offer.

Routing logic. The rail is a property of the venue agreement and the game type, resolved at game creation and surfaced to the organiser before anyone pays. A game that needs a deposit cannot be created on a pass-through venue; the product should say so plainly at that point rather than failing at checkout.

What this demands architecturally. The payment domain must be abstracted behind a single interface with both implementations behind it, from the first migration. Game logic must never know which rail it is on. Refund, dispute and reconciliation flows need to work identically from the product's perspective even though the underlying mechanics differ substantially. The abstraction costs more up front and buys the ability to add venues on either terms without touching product code.

Custodian selection is a business decision, not a technical one. Key criteria: licensing status, M-Pesa integration maturity, settlement cadence and predictability, per-transaction cost on both legs, dispute handling, API quality, and willingness to work with a company at Jasiri's stage. Take regulatory advice on the structure of the arrangement before signing.

11.5 Integration surface

• M-Pesa Daraja: STK push, C2B, B2C, transaction status, reversal
• WhatsApp Business Platform: Groups API, template messaging, webhooks, link previews
• SMS gateway: fallback for non-app users
• Wearables: Strava, Apple Health, Google Health Connect, Garmin, Fitbit
• Maps and geocoding: venue location, travel time, proximity matching
• Push notification: FCM / APNs
• Media pipeline: upload, transcode, thumbnail, CDN
• Calendar: ICS export and two-way sync for organisers
• Venue systems: custom per venue; assume most have none

11.6 The camera system

The system is deliberately simple. Its job is to capture short clips reliably in variable light, on a venue's network, without staff intervention.

• One camera per court, POE where possible
• Local edge device with a rolling buffer of 60 to 120 seconds
• Physical clip button at courtside, plus in-app trigger
• Local clip extraction, upload on venue wifi
• Clips compressed small and downloaded on wifi by preference, since Nairobi data is expensive
• Retention window measured in days, not indefinitely
• Consent signage at the venue, opt-out honoured at the roster level before capture

12Go-to-market

12.1 The seed cohort

150 to 200 warm users from the basketball community and adjacent networks. This is a genuinely strong starting position and it should be spent carefully, because it can only be spent once.

How to use it well:

• Do not launch to all of them at once. Take 30, run real games, fix what breaks, then expand.
• Identify the 5 to 10 natural organisers within the group immediately. They are the actual first customers.
• Use them to seed crews rather than individual accounts. A crew of 12 is worth more than 12 users.
• Have them paste game links into their existing WhatsApp groups. That is the growth loop being tested, and it should be tested from week one.

Covering the payments gap. Basketball exercises P1, P3 and P4 well and P2 barely, because much of it happens on free courts. Since payments are the wedge, the first cohort has to test them anyway. Two deliberate moves:

1. Seed where money changes hands. Weight the first crews toward paid inventory: indoor courts, fee-charging school and club courts, and league fixtures. Free-court crews are still valuable for the coordination loop, but they cannot be the whole cohort.
2. Run one group outing in the first eight weeks. An outing with the seed community is the sharpest possible payments test in the portfolio — twenty people, a venue deposit, a shifting headcount, and a real risk of someone fronting KES 45,000. It requires no matching logic, so it can run before the fill mechanics are finished, and it recruits the organisers who will run everything afterwards.

The order matters. Coordination is proven first because it is cheap to test and everything else depends on it; payments are proven immediately afterwards because they are what the business is built on.

12.2 Sequencing

The dependency chain is: organisers → crews → games → venue evidence → venue depth → open games → strangers.

Strangers come last. Full fill cannot work until there is a supply of games for strangers to join, and that supply comes from crews, and crews come from organisers. Building the fill feature first is building the roof first.

12.3 Growth loops

1. The link loop. Game link pasted into a WhatsApp group → non-users claim slots → they need the app for the next one. Primary loop, highest priority.
2. The card loop. Post-game card shared to social → carries a join link → new user.
3. The organiser loop. Organiser earns from games → runs more games → recruits more players.
4. The venue loop. Venue sees new customers from Jasiri → gives more inventory → more games available.
5. The season loop. Seasonal challenge → lapsed users return → re-engaged.

12.4 Channels beyond the seed cohort

Corporate wellness pilots with one or two friendly employers. University and college sport, which has density and low acquisition cost. Padel tournament presence, given the existing competitive calendar. Run clubs, which are already organised and already have leaders. Venue-side acquisition, with QR codes at courts converting existing venue customers into Jasiri users, which is the cheapest acquisition available and a good reason to prioritise venue depth.

13Compliance, safety and risk

13.1 Data protection and how user data is secured

Jasiri will hold an unusually sensitive combination for a consumer app: heart rate and activity data, precise location, social graph, payment history, and video of identifiable people at venues. Kenya's Data Protection Act treats health data as sensitive personal data, which raises the bar on how it is collected, stored and justified. Implementation detail belongs elsewhere; what follows is the position Jasiri takes.

The principles governing how data is handled:

Collect narrowly. Every data point should have a named use in the product. Heart rate exists to produce a post-game card and a wellness report. Location exists to match by proximity. Nothing is collected because it might be useful later; that is how a data set becomes a liability instead of an asset.

Separate consent by purpose. A user agreeing to activity tracking for their own post-game cards has not agreed to their data appearing in an employer's wellness dashboard, and has not agreed to appearing in a session reel. These are three decisions and they should be presented as three decisions. A single blanket agreement is both weaker legally and worse for trust.

Consent is revocable and the product must survive it. A user who withdraws wearable consent should still be able to play, book, pay and receive cards. Any feature that breaks without sensitive data has been designed wrong.

Retention is bounded by default. Clips expire in days unless saved. Raw wearable data has a defined lifespan; derived summaries can outlive it. Nothing sensitive is kept indefinitely because deleting it was never scheduled.

Video is the most exposed surface. Filming identifiable people at a venue creates obligations for Jasiri and for the venue. Position: clear signage at any camera-equipped court, notice at booking, roster-level opt-out honoured before capture rather than after, and no facial recognition. Anyone opting out is excluded from reels rather than blurred.

Sensitive data is minimised in transit and at rest. Encryption throughout, access to health and location data restricted to the services that need it, internal access logged and reviewable, and no sensitive data in analytics events or third-party tooling.

Aggregate products require an aggregate consent basis. Revenue line 28 is only saleable if the consent chain supports it, and it should be built on genuinely aggregated and anonymised data with no path back to an individual. If the numbers only work by identifying people, the product should not be sold.

Formal obligations to satisfy: registration with the Office of the Data Protection Commissioner as a data controller, an impact assessment before processing health or video data, working data subject access and deletion mechanisms, and a stated position on cross-border transfer if infrastructure sits outside Kenya.

The structural point: consent belongs in the data model rather than in a settings screen. Every sensitive field should carry the basis on which it was collected and the rule under which it expires. Retrofitting that onto a schema that assumed ownership is expensive and sometimes only possible by discarding the data.

13.2 Financial regulation

Holding user funds between collection and disbursement changes Jasiri's regulatory character and may bring it within Central Bank of Kenya oversight. Deposits, escrow and split payments all raise this. Take advice before building, not after. The dual-rail structure in Section 11.4 is partly a compliance strategy: pass-through avoids the question entirely, and custodial escrow places the held funds with a party already licensed to hold them.

13.3 Duty of care and injury

The moment Jasiri matches strangers into physical activity, someone will be injured and will look for someone to hold responsible.

Requirements: clear terms of use with an appropriate liability position; participation waivers; minimum insurance requirements for partner venues; a documented incident reporting and response process; a policy on minors, which should be to exclude under-18s from stranger-matched games entirely while explicitly supporting them within closed private groups, since laser tag and bowling outings routinely include children and the product should handle that deliberately rather than by omission; and surfaced venue safety information.

Handled well, this is also a differentiator. It is part of why someone would trust Jasiri over an unmanaged WhatsApp group.

13.4 Trust and safety

Conduct reporting separate from reliability reporting. Organiser verification. Meaningful consequences that users can see applied. Block and mute. A moderation policy for community spaces. Enforcement of gender policy in matching.

13.5 Risk register

14Metrics

The one number that matters: games successfully played per week. Not users, not downloads, not bookings. A played game means coordination worked, payment worked, and nobody was let down.

Supporting metrics:

Liquidity

• Fill rate, split by peak and off-peak
• Time from game creation to full roster
• Percentage of games cancelled for insufficient players
• Backfill success rate on post-lock drops

Retention

• Games per user per month
• Week-4 and week-12 return rate
• Crew survival rate (percentage still playing after 8 weeks)
• Organiser retention, which is the leading indicator for everything else

Trust

• No-show rate
• Late cancellation rate
• Post-game rating completion rate
• Conduct reports per 1,000 games

Growth

• Link-loop conversion: non-users who claim a slot from a shared link
• Card share rate and click-through
• Venue-sourced signups via QR

Commercial

• Contribution per game
• Off-peak revenue as a percentage of venue total (the number that sells Tier 2)
• New-to-venue customer percentage (the number that closes Tier 2)

15Sequencing

The scope above is broad by design. The order below builds it:

Foundation — basketball. Game object, crews, roster management, WhatsApp link sharing, basic venue inventory, pass-through payments, reliability tracking. 3v3 and 5v5, one neighbourhood, 30 seed users from the existing community.

Trust — still basketball. Auto-backfill, cancellation thresholds, post-game signals, skill derivation, organiser tooling. Expand to the full 150–200 seed cohort. The loop is either working by the end of this stage or the problem is not what this document assumes.

Yield — padel. Deep venue integration, off-peak pricing, the custodial escrow rail, Tier 2 venue pitch backed by real basketball fill data, recurring templates. This is where the business starts making money.

Delight. Post-game cards, vibe check, badges and first season, wearable integration. This is when the product becomes something people talk about.

Breadth. Fitness classes for frequency, touch rugby and 5-aside for volume, and group outings for margin. Outings are worth pulling forward if the escrow rail lands early, since they are the strongest demonstration of it. Camera pilot at one or two padel venues, clip button, session reels.

Scale. Corporate wellness, sponsored slots, additional sports, geographic expansion, guaranteed minimums.

Later. Insurance attach, data products, adjacent categories, geographic expansion beyond Nairobi.

16Open questions

Things this document cannot resolve and that need decisions, data, or advice:

1. Custodian selection and terms. Which licensed partner, on what settlement cadence, at what cost per leg. The dual-rail architecture is settled; the counterparty is not, and it materially affects unit economics.
2. How much basketball is enough. Basketball proves the loop but will not fund it. The risk is over-investing in a vertical that cannot monetise; the threshold for moving to padel needs to be defined in advance rather than negotiated later.
3. Real off-peak fill rates. Everything in the venue pitch depends on a number nobody has yet. This should be measured within the first 60 days.
4. Whether venues will actually give up calendar control. Tier 3 integration assumes a level of trust that has to be earned and may not be forthcoming.
5. Deposit acceptability. Cultural willingness to pay before playing is an assumption, not a finding. Test it early and cheaply.
6. Organiser economics. What revenue share is enough to change behaviour, and does it survive contact with the unit economics.
7. When to move from basketball to padel. The trigger should be a proven coordination loop, not a calendar date, and the specific threshold needs defining.
8. Brand and positioning. Jasiri as competitive sport platform, as social discovery product, or as health and wellness platform. These attract different users, different sponsors and different venues, and the answer shapes everything from tone to feature priority.