Cold-Start & Coverage Strategy
Treat cold-start emptiness as a first-class product problem. The retention features that drive return (birthday, nearby, insights) are the ones most damaged by low density — this defines the seeding, platform-funded fallbacks, density-aware UX, and graceful empty states that keep the app alive before the network effect kicks in.
Status: Accepted (direction); implementation deferred
Date: June 2026
Decision: Treat cold-start emptiness as a first-class product problem. Several retention features (birthday, nearby, insights) feel empty when merchant density or user history is low — the exact state every new user and new geography starts in. This defines the coverage tactics (seeding, platform-funded fallbacks, density-aware UX, graceful empty states) that keep the app alive before the network effect kicks in.
Note on existing surfaces
The built Twin Birthday (social) and Nearby Alerts (bookmark geofencing) features are less cold-start-sensitive than their roadmap counterparts: Twin Birthday shows people (populated by users, not merchants), and Nearby Alerts only acts on shops the user already bookmarked. The emptiness risk here is specifically about the merchant-perk layers (birthday engine) and the server discovery surface (nearby) — the new, merchant-density-dependent parts.
TL;DR
The features that drive retention (birthday, nearby, insights) are the ones most damaged by low density — the state every new user/geography starts in. Four tactics bridge the gap: seed density before launch (city-by-city), platform-funded fallbacks (never a zero-perk birthday), density-aware UX (expand radius, switch to “discover” framing), and graceful empty states that capture demand (→ merchant sales leads). The chicken-and-egg is per-geography, so this is a permanent capability.
Context
The retention stack is balanced once full, but each surface has a density dependency:
| Feature | Feels empty when… | Cold-start severity |
|---|---|---|
| Nearby | few merchants near the user | High — “no places near you” kills the everyday hook on day one |
| Birthday | few merchants offer birthday perks | High — “no birthday gifts” on the user’s birthday is the worst possible miss |
| Insights | user has little spend/receipt history | Medium — thin data = thin summary; self-corrects over time |
| Points | few places to earn/redeem | Medium — balance feels useless if unspendable nearby |
| Tiers | no accumulated points | Low — everyone starts Bronze; expected |
The trap: the features that drive retention are the ones most damaged by emptiness. A new user in a low-density area sees “nothing near you, no birthday perks, no insights yet” and churns before the network is populated. Classic chicken-and-egg: features need density, density needs retained users, retention needs the features to work.
This is per-geography, not global — even a mature app re-enters cold-start every time it launches a new city. So it’s a permanent capability, not a one-time launch concern.
Decision
Four tactics, applied per feature, to bridge the gap until organic density arrives.
1. Seeding — populate before launch (per geography)
Don’t launch a geography until it clears a minimum density bar.
- Nearby: define a floor (e.g. N discoverable merchants within the typical radius) before the nearby tab is enabled for users in that area. Below the floor, the feature is hidden, not shown empty.
- Birthday: recruit a seed cohort of merchants with birthday perks at launch so every birthday in that geography has at least one gift. A birthday with zero perks is a churn event — the floor here is effectively “≥1 reliable perk per user.”
- Geo-gating: launch city-by-city rather than nationwide-thin. Concentrated density in one city beats sparse coverage everywhere.
2. Platform-funded fallbacks — befday backstops emptiness
When merchant supply is thin, befday itself provides the actionable state so the surface is never empty.
- Birthday backstop: a platform-funded birthday perk (befday points credit, or a partnered/sponsored gift) guarantees every user gets something on their birthday even if no local merchant participates. Funded from the befday float (the Model 3 reserve in cross-merchant funding).
- Nearby backstop: when actionable merchants are sparse, fill with points-earning opportunities or featured/sponsored merchants so the list isn’t blank.
- Cost control: these are capped, budgeted spends treated as CAC (acquisition cost), not unbounded liabilities — justified because a populated day-one experience is what converts the cohort.
3. Density-aware UX — adapt the surface to what exists
The UI changes shape based on available density instead of showing a broken version of the dense experience.
- Expand radius gracefully: if nothing is within walking distance, widen to driving distance and say so (“nearest befday spots — 12 km away”) rather than “nothing nearby.”
- Switch framing: in low density, nearby becomes “discover befday places” (exploration) rather than “use what you have” (transaction) — a different, still-useful job.
- Lead with what’s full: if nearby is thin but the user has points/birthday perks, lead with those surfaces instead. The retention stack is a portfolio — route the user to whichever driver is currently populated.
4. Graceful empty states — never a dead end
When a surface genuinely has nothing, the empty state does a job:
- Set expectation + capture intent: “No befday spots near you yet — notify me when one opens nearby” (turns emptiness into a push opt-in and a demand signal).
- Demand signal for sales: aggregated “users wanting coverage here” data feeds merchant acquisition — emptiness becomes a sales lead, closing the loop.
- Redirect, don’t dead-end: every empty state links to a populated surface (points wallet, receipt scanning, referral) so the session continues.
Per-feature application
| Feature | Seeding | Platform fallback | Density-aware UX | Empty state |
|---|---|---|---|---|
| Nearby | density floor before enable | featured/sponsored fill | expand radius; “discover” framing | “notify me when one opens” |
| Birthday | seed perk cohort per city | platform-funded perk (key) | widen eligible radius | n/a — fallback prevents empty |
| Insights | n/a (time-based) | sample/onboarding insight | “log more to see more” | encourage scanning |
| Points | seed earn/redeem merchants | platform earn opportunities | show usable-elsewhere | route to nearby/catalog |
The birthday platform-funded fallback is the single highest-priority backstop — a birthday with zero perks is the most damaging empty state in the entire stack (it’s the one day the user expects to be celebrated).
Data Model Impact (sketch)
Mostly reuses existing tables; adds coverage signals and budgeting.
| Table / column | Notes |
|---|---|
geographies / region config |
density floor + launch status per area (enable features when met) |
shops.is_discoverable, geo (lat/lng) |
already proposed in nearby; drives density counts |
coverage_requests |
new — captures “notify me / want coverage here” (user_id, geohash, requested_at) → demand signal for sales |
befday_program_settings.platform_birthday_fallback |
config — enable + cost cap for platform-funded birthday perks |
befday_funding_pool (float) |
from cross-merchant funding — source for platform fallbacks |
Density is computed from discoverable shops + geo (a count within radius), not stored as truth — same read-derived pattern as nearby.
Consequences
| Type | Consequence |
|---|---|
| Pro | Protects the retention stack’s weakest moment — the empty day-one / new-geography experience that otherwise churns users before density arrives. |
| Pro | Turns emptiness into signal (coverage requests → merchant sales leads), closing the chicken-and-egg loop. |
| Pro | Platform-funded fallbacks make the birthday promise reliable (never a zero-perk birthday), which is the brand’s core. |
| Pro | Density-aware UX means one codebase serves both sparse and dense geographies. |
| Con | Platform-funded fallbacks cost real money — must be capped and tracked as CAC, with discipline to avoid open-ended liability. |
| Con | City-by-city gating slows top-line “national availability” — a go-to-market tradeoff. |
| Con | Adds branching/complexity to feature UIs (density tiers, fallbacks, empty states) that must be designed and tested. |
Open Questions
- Density floor values: what’s the minimum merchant count / radius that flips nearby from “hidden” to “enabled” per geography type (urban vs rural)?
- Birthday fallback economics: what’s the per-user cap and total budget for platform-funded birthday perks, and what’s the gift (points credit vs sponsored partner)?
- Launch unit: city, postcode cluster, or radius-based — what’s the right geography unit to gate on?
- Sponsored fill: do we allow paid “featured” merchants in nearby during cold-start, and how is that labeled to stay honest?
- Graduation: when does a geography “graduate” off fallbacks (organic density sufficient), and is that automatic or manual?
- Coverage-request → sales: what’s the workflow that turns aggregated demand signals into actual merchant outreach?