Cofounder Feedback POA - January 2026

Date: 2026-01-11
Status: Draft - Strategic Planning
Context: Feedback received 2026-01-09 covering user profiles, privacy, engagement, and growth

---

Executive Summary

This POA addresses comprehensive cofounder feedback spanning user experience, privacy model, engagement mechanisms, and growth strategy. The feedback identifies both strengths (design quality, merchant integration) and critical questions about core value proposition, network effects, and user stickiness.

Key Strategic Questions to Resolve:

1. Primary value prop: Stranger connections vs. strengthening existing relationships?
2. Privacy model: How explicit vs. organic should stranger introductions be?
3. User engagement: What makes Lantern sticky without venues?
4. Growth strategy: How to avoid chicken-egg problem?

---

I. User Profile & Onboarding

Feedback Summary

• Current design is professional and aesthetically pleasing
• Suggestion: Shared interests drive connections (top 10 locations concept)
• Profile should include: lantern name (autogenerated username with optional custom), age (verification only), gender (TBD; collect only if necessary)
• Phone number (for fraud prevention and to limit re-signups by banned users)
• "Hang 10 lanterns" around your city (friends/family know you've been here)
• Discovery mode toggle (strangers vs. connections-only)
• Preference filters for who can wave

Action Items

Priority 1: Core Profile Features

• [ ] Define profile data model (lanternName autogen + optional custom username, age for verification, phone number for anti-fraud, gender TBD, preferences)

  • Status: Not started
  • Owner: TBD
  • Dependencies: Privacy model decision
  • Deliverable: Firestore schema document

• [ ] Design "Top 10 Locations" selection flow

  • Status: Not started
  • Owner: TBD
  • Question: How do users select? Search? Map interface? Browse categories?
  • Deliverable: Wireframes + user flow diagram

• [ ] Implement Discovery Mode toggle

  • Status: Not started
  • Owner: TBD
  • Technical: Add to user profile settings
  • UI: ProfileSettings.jsx enhancement
  • Deliverable: Working feature in dev environment

• [ ] Enhance Light Lantern form

  • Add short blurb (why you’re here) and a specific category when lighting
  • Status: Not started (interest/mood exist; add category)
  • File: src/components/LightLanternForm.jsx
  • Deliverable: Updated form + data model

Priority 2: Preference Filters

• [ ] Spec out preference system

  • Age range
  • Gender preferences
  • Distance preferences
  • Common interests threshold (how many shared locations?)
  • Status: Not started
  • Deliverable: Product spec document

• [ ] Wire up filters to match algorithm

  • Status: Blocked by preference spec
  • Technical: Cloud Functions for match calculation
  • Deliverable: Working match filtering

Priority 3: Testing & Validation

• [ ] Test value: Discovery mode on vs. off usage patterns
  • Status: Blocked by feature implementation
  • Method: A/B test or user interviews
  • Metric: Engagement rate, connection formation rate
  • Deliverable: Analysis report

---

II. Privacy & Stranger Connection Model

Feedback Summary

"If privacy is a key feature, what if Lantern is primarily a way to strengthen existing relationships with the possibility of making new ones?"

Key insight: Make stranger connections feel more organic rather than explicit dating-app-style matching.

Strategic Questions (MUST RESOLVE)

Q1: Primary Value Proposition

Options:

• A) Stranger-first: Discovery mode is default, meeting new people is primary value
• B) Relationship-first: Friends/family connections are primary, stranger connections are secondary benefit
• C) Hybrid: Equal weight to both use cases

Recommendation: Start with Option B (relationship-first) for three reasons:

1. Solves chicken-egg problem (value doesn't depend on large user base initially)
2. Reduces privacy concerns (strangers are opt-in, not default)
3. Creates organic growth via friend groups sharing

Decision needed by: 2026-01-18

Q2: Stranger Introduction Mechanism

Current state: Lit lantern → strangers can wave → ??? unclear what happens next

Options:

• A) Show aggregated data only: "People matching your taste profile enjoy X, Y, Z locations" (no individual profiles)
• B) Mutual opt-in reveal: Both users must wave/express interest before profiles shown
• C) Profile preview: Limited info visible before connection (age range, shared locations count)
• D) Venue-based matching: Match at the venue level based on interests; individual matching only if the user opts in (privacy-first default)

Recommendation: Option B + Option C, with D as default discovery surface — show minimal info (age range, "3 shared locations", distance), require mutual interest before revealing identities; prioritize venue-level discovery.

Decision needed by: 2026-01-18

Action Items

Priority 1: Clarify Privacy Model

• [ ] Document privacy model decision

  • Status: Pending strategic decision
  • Owner: Cofounders
  • Deliverable: docs/features/PRIVACY_MODEL.md

• [ ] Create user-facing privacy explainer

  • Status: Blocked by privacy model decision
  • Where: Onboarding flow, Settings page, FAQ
  • Deliverable: Copy + UI designs

• [ ] Define Frens sharing semantics

  • Sharing your lantern shows your presence at a specific venue to Frens
  • Reciprocity optional: a Fren can see your venue without sharing theirs
  • Visibility limited strictly to venue-level presence (no identity/history)
  • Deliverable: Spec + UX flows

Priority 2: Implement Recommended Model

• [ ] Build aggregated location recommendations

  • "People with similar taste enjoy these spots"
  • No individual user data exposed
  • Status: Not started
  • Technical: Analytics Cloud Function
  • Deliverable: Feature spec + implementation

• [x] Implement mutual-interest matching

  • Both users must wave before connection
  • Show minimal profile preview before connection
  • Status: Completed
  • Technical: Wave send + accept create connection; preview via WaveManager
  • Deliverable: Updated wave flow

---

III. Lit Lantern Status & User Flow Clarity

Feedback Summary

"Waiting for connections..." - what does that mean? What's the significance of someone waving at me? What happens then?

Issue: Current flow is unclear. Users don't understand:

1. What "waiting for connections" means
2. What waving accomplishes
3. Whether they can use their phone for other things while waiting
4. What the end result of a connection is

Action Items

Priority 1: Clarify User Flow

• [ ] Document complete lit lantern → wave → connection flow

  • Status: Not started
  • Owner: TBD
  • Questions to answer:
    • Can users lock screen and get notifications? (Should be YES)
    • What info is exchanged when someone waves?
    • What happens after mutual wave?
    • How do users actually connect (chat? meet in person? exchange contact?)
  • Deliverable: User flow diagram + feature spec

• [ ] Rewrite copy on lit lantern screen

  • Status: Blocked by flow clarification
  • Current: "Waiting for connections..."
  • New: TBD based on actual functionality
  • File: src/screens/dashboard/Dashboard.jsx
  • Deliverable: Updated copy + UI

Priority 2: Background Notifications

• [ ] Implement background wave notifications

  • Status: Not started
  • Technical: Firebase Cloud Messaging
  • Web requires explicit user permission (like location); request permission in onboarding
  • User can light lantern, use phone normally, get notified on wave (after allowing notifications)
  • Deliverable: Working notification system

• [ ] Add notification permission flow to onboarding

  • Status: Blocked by FCM implementation
  • Update copy to explain why notifications improve experience
  • Deliverable: Updated onboarding

Priority 3: Post-Wave Actions

• [x] Design what happens after mutual wave
  • Options:
    • Open in-app chat
    • Exchange contact info (phone/social)
    • Suggest meeting spot (nearby shared location)
  • Status: Completed (in-app chat on acceptance)
  • Deliverable: Implemented via Chat component; spec optional

---

IV. Nearby Vibes - Identity Verification

Feedback Summary

"How do I know who is waving at me and if I actually want to initiate a conversation with them? Stranger danger. How to vet someone without having to first give away your own identity?"

Critical safety/UX issue: Current design may expose users to unwanted interactions without enough information to make informed decisions.

Action Items

Priority 1: Preview Information

• [ ] Define what info is visible before mutual match

  • Age range (not exact age)
  • Distance approximate ("less than 0.5 miles away")
  • Number of shared Top 10 locations (not which ones)
  • Gender (if user has set preference filters)
  • Status: Not started
  • Owner: TBD
  • Deliverable: Privacy-safe profile preview spec

• [x] Implement profile preview UI

  • Status: Completed
  • Where: When someone waves, show preview card
  • User can accept/decline wave based on preview
  • Deliverable: UI component + backend support

Priority 2: Safety Features

• [ ] Add blocking/reporting functionality

  • Status: In progress (UI implemented; backend rules TBD)
  • Users can block other users
  • Report inappropriate behavior
  • Technical: Firestore security rules, admin dashboard
  • Deliverable: Safety feature set

• [ ] Implement trust indicators

  • Account age
  • Number of successful connections
  • Mutual friends (if using social login)
  • Status: Not started (requires research)
  • Deliverable: Trust system spec

• [ ] SOS button + safe sites integration

  • Immediate local audio/video recording on activation
  • Share real-time GPS to emergency contacts (opt-in)
  • Partner safe sites (e.g., LGBTQ centers, domestic violence shelters)
  • Meet-ups encouraged within venues for safety (cameras, staff, public)
  • Deliverable: Safety mechanics spec + implementation plan

Priority 3: Documentation

• [ ] Create user safety guide
  • Exists: docs/USER_SECURITY_GUIDE.md
  • Action: Review and enhance for stranger connection use case
  • Add section on vetting potential connections
  • Deliverable: Updated security guide

---

V. Sponsored Nearby - Limited Offers

Feedback Summary

"For limited offers - should there be a way for users to see how many offers have already been claimed?"

Good UX suggestion: Prevent user frustration from traveling to claimed-out offers.

Action Items

Priority 2: Offer Claim Visibility

• [ ] Add claim counter to sponsored offers

  • Show "12 of 50 claimed" or "38 remaining"
  • Status: Not started
  • UI: Update OfferCard component
  • Backend: Track claims in Firestore
  • File: src/components/OfferCard.jsx (if exists) or create
  • Deliverable: Claim tracking feature

• [ ] Implement real-time claim updates

  • Status: Not started
  • Use Firestore real-time listeners
  • Update offer status live as users claim
  • Deliverable: Real-time offer sync

• [ ] Add "offer expired" or "sold out" states

  • Status: Not started
  • Visual indication when offer is no longer available
  • Remove from map or gray out
  • Deliverable: Expired offer handling

• [ ] Explore POS integration for redemption tracking

  • Optional merchant POS integration to validate redemptions
  • Enables accurate claim counters and fraud prevention
  • Deliverable: Technical feasibility + pilot plan

---

VI. UI Elements - Status Icon

Feedback Summary

"Green radio button in the top right - Assume this is a status icon - I tried to tap on it"

UX issue: User expected icon to be interactive but it's not (or behavior unclear).

Action Items

Priority 3: Status Icon Clarity

• [ ] Audit top-right status icon
  • Current file: Check src/screens/dashboard/Dashboard.jsx or layout component
  • Questions:
    • What is this icon showing? (Online status? Connection status?)
    • Should it be tappable?
    • If tappable, what should happen?
  • Status: Not started
  • Deliverable: Decision + implementation or removal

---

VII. User Engagement & Stickiness

Feedback Summary

"What's the addictive, sticky value proposition that will get users to engage and keep coming back?"

Critical strategic issue: Without stickiness, app won't achieve network effects. Feedback includes 14 specific engagement ideas.

Strategic Framework: The Two-Sided Marketplace Problem

The Chicken-Egg Problem

Issue: If primary value is venue offers, we need users to attract venues AND venues to attract users.

Traditional solution: Heavy capital investment (Uber model - subsidize both sides)

Recommended solution: Make primary value user-centric, not venue-dependent

Engagement Strategies Analysis

Tier 1: Implement First (Relationship-First Model)

These support the "strengthen existing relationships" primary value prop:

1. Friend Groups / Usernames

   • [ ] Implement friend groups functionality
   • [ ] Enable group lantern lighting ("our crew was here")
   • [ ] Share groups via invite codes or QR
   • [ ] Show when friends have lit lanterns (discovery feed)
   • Why first: Provides immediate value without venue network, drives organic growth
   • Status: Not started
   • Deliverable: Friends feature spec + implementation

2. Taste Profile & Recommendations

   • [ ] "95% of people who light up Midnight Bean also light up Rusty Anchor Pub"
   • [ ] Location similarity algorithm
   • [ ] "Try this next" recommendations
   • Why first: Helps users discover new places, provides value immediately
   • Status: Not started
   • Deliverable: Recommendation engine

3. Lit Lantern History ("Passport Stamps")

   • [ ] Visual history of all places you've lit
   • [ ] "You and UserX were both at Red Rocks in July 2024"
   • [ ] Badges for special events/locations
   • Why first: Creates personal value, conversation starters, nostalgia
   • Status: Not started
   • Technical: Store lantern history with timestamps
   • Deliverable: History feature + UI

Tier 2: Implement Next (Gamification)

These add stickiness but require Tier 1 foundation:

4. Status & Levels System

   • [ ] Points for desired behaviors:
     • Creating groups
     • Sharing app / referrals
     • Lanterns lit
     • Lit lantern streaks
   • [ ] Levels unlock features or better offers
   • [ ] Public status indicators
   • Concern: Must provide meaningful status, not just vanity metrics
   • Status: Not started
   • Deliverable: Gamification system spec

5. Streaks & Rewards

   • [ ] "10 day lit lantern streak unlocks X"
   • [ ] Daily engagement incentive
   • Concern: Requires daily engagement value (what is it?)
   • Status: Blocked by core value prop clarity
   • Deliverable: Streak system

6. Top Locations / Events Leaderboard

   • [ ] "Taylor Swift Concert (150k lanterns lit)"
   • [ ] Historical event data
   • [ ] FOMO driver ("I was there!")
   • Status: Not started
   • Deliverable: Events leaderboard feature

Tier 3: Implement Later (Advanced Features)

These require significant user base:

7. Discover Weekly

   • [ ] Sunday morning digest: new matches, offers, places to try
   • Status: Not started
   • Requires: Email/push notification system
   • Deliverable: Weekly digest feature

8. Notifications for New Matches/Offers

   • [ ] Real-time or daily summary
   • Status: Not started
   • Technical: FCM + notification preferences
   • Deliverable: Notification system

"Seven Deadly Sins" Analysis

Question from cofounder: Which sins could Lantern check?

Current analysis:

• Envy: ✓ Seeing others' cool locations, events, passport stamps
• Pride: ✓ Public status, levels, being first at hot new spot
• Sloth: ✓ Easy discovery of nearby things to do (minimal effort)
• Gluttony: Partial - offers for food/drink experiences
• Lust: Partial - if romantic connections emerge (not primary)
• Greed: ? - Free offers, points, rewards
• Wrath: ✗ Not applicable

Action item:

• [ ] Deliberately design for Envy & Pride
  • Make passport stamps beautiful and shareable
  • Create visible status symbols (badges, levels)
  • Public leaderboards
  • "I was there" flex for major events
  • Status: Not started
  • Deliverable: Social sharing features

Action Items - Engagement

Priority 1: Foundation

• [ ] Choose primary value prop (see Section II)

  • Decision needed by: 2026-01-18

• [ ] Implement Tier 1 features:

  • [ ] Friend groups
  • [ ] Taste profile recommendations
  • [x] Lit lantern history (Recent Activity + archived chats implemented)
  • Target completion: Q1 2026

Priority 2: Gamification

• [ ] Design points & status system

  • Status: Not started
  • Deliverable: Full gamification spec

• [ ] Implement Tier 2 features:

  • [ ] Status & levels
  • [ ] Streaks (if daily value prop is clear)
  • Target completion: Q2 2026

Priority 3: Research

• [ ] User research: What makes users return?
  • Method: Interviews + usage analytics
  • Question: Do users return for friends, discovery, offers, or something else?
  • Status: Blocked by MVP launch
  • Deliverable: Research report

---

VIII. Loyalty Program & Direct Marketing

Feedback Summary

"Loyalty Program and Direct Marketing for Venues - Could be a good way to foster user and venue engagement"

Action Items

Priority 2: Venue Tools

• [ ] Design merchant dashboard for direct marketing

  • Push notifications to users who've lit their lantern
  • Targeted offers based on user preferences
  • Status: Not started
  • Related: docs/business/MERCHANT_INTEGRATION_POA.md
  • Deliverable: Merchant marketing feature spec

• [ ] Implement loyalty tracking

  • Track repeat visits to same venue
  • Reward loyal customers
  • Status: Not started
  • Deliverable: Loyalty system

---

IX. QR Code Friend Linking

Feedback Summary

"Scan a friend's QR code to link your lanterns?"

Action Items

Priority 2: QR Friend Add

• [ ] Implement QR code generation for users

  • Each user has unique QR code
  • Status: Not started
  • Technical: Generate QR with user ID

• [ ] Implement QR scanner

  • Camera permission flow
  • Scan friend's code → instant connection
  • Status: Not started
  • Deliverable: QR friend-add feature

---

X. Growth Strategy

Feedback Summary

Multiple growth-related questions:

1. Monetization strategy?
2. Competitive moat?
3. Market at major events
4. Early market activation strategy

Critical Questions (MUST RESOLVE)

Q3: Monetization Strategy

Options:

• A) Commission on venue offers (like Groupon) - 15-30% of offer value
• B) Venue subscription - Monthly fee for merchant dashboard access
• C) Freemium user model - Basic free, premium features for users
• D) Hybrid - Venue fees + optional user premium

Current state: No defined monetization

Recommendation: Start with Option B (venue subscription) because:

• Predictable revenue
• Aligns incentives (venues want engaged users, not just offer clickers)
• Easier to implement than transaction tracking
• Can layer commission model later

Decision needed by: 2026-02-01

Q4: Competitive Moat

Current assets:

• Beautiful design (per cofounder feedback)
• Privacy-first approach (if we commit to it)
• Dual use case (friends + strangers)

Potential moats:

• Network effects (more users = more value)
• Venue relationships (exclusive offers)
• Data moat (taste profile algorithms improve with scale)
• Brand (first mover in "privacy-first location sharing")

Action needed:

• [ ] Document competitive analysis

  • Status: Not started
  • Competitors: Zenly (shut down), Find My Friends, Foursquare, dating apps
  • Deliverable: Competitive analysis document

• [ ] Define defensible moat strategy

  • Status: Blocked by competitive analysis
  • Deliverable: Moat strategy document

Q5: Early Market Activation

Cofounder suggestion: "Should we tell users in a new market the number of active users that need to sign up before we start targeting venues for offers?"

Pros:

• Creates urgency and FOMO
• Encourages organic sharing (users recruit friends to hit threshold)
• Gives us signal of which venues to target (user activity shows preferences)

Cons:

• Highlights small user base (could discourage signups)
• Creates expectation of venue offers (what if we pivot away from that?)
• Pressure to deliver on promise

Recommendation: Yes, but with twist:

• Frame as "Help us bring Lantern to your favorite spots"
• Show progress bar: "125 of 500 users needed to launch venue partnerships in Denver"
• Let users vote on which venues they want to see first
• Builds excitement, shows traction, gives us data

Action items:

• [ ] Design early market activation strategy

  • Status: Not started
  • Deliverable: Go-to-market strategy document

• [ ] Implement market progress UI

  • Show active user count in new markets
  • Venue voting feature
  • Status: Not started
  • Deliverable: Market activation features

Action Items - Growth

Priority 1: Strategy Decisions

• [ ] Make monetization decision (Q3)

  • Deadline: 2026-02-01
  • Owner: Cofounders

• [ ] Document competitive moat strategy (Q4)

  • Deadline: 2026-02-15
  • Deliverable: Strategy document

Priority 2: Event Marketing

• [ ] Create event marketing plan

  • Target major events (concerts, festivals, conferences)
  • On-site signup incentives (merch discounts, exclusive offers)
  • Status: Not started
  • Note: Requires capital for incentives
  • Deliverable: Event marketing playbook

• [ ] Merchant POS partnerships (optional)

  • Integrate with POS providers to track offer redemptions
  • Strengthen Sponsored Nearby and loyalty accuracy
  • Deliverable: Partnership outreach + integration roadmap

• [ ] Build event partnership pipeline

  • Research upcoming major events in target markets
  • Reach out to event organizers
  • Status: Not started
  • Deliverable: Event partnership pipeline

Priority 3: Market Activation

• [ ] Implement early market activation features
  • User count progress
  • Venue voting
  • Status: Not started
  • Deliverable: Features deployed

---

XI. Next Steps & Decision Timeline

Critical Path Decisions (Block Everything Else)

Decision	Owner	Deadline	Status
Primary value prop: Stranger-first vs. Relationship-first	Cofounders	2026-01-18	Not started
Privacy model: How to vet strangers safely	Cofounders	2026-01-18	Not started
Lit lantern → wave → connection flow: What actually happens?	Product	2026-01-25	Not started

Sprint Planning Recommendation

Sprint 1 (Jan 13-26): Clarify Strategy

• Cofounders: Decide primary value prop & privacy model
• Product: Map complete user flows
• Engineering: Audit current implementation vs. intended flows

Sprint 2 (Jan 27 - Feb 9): Foundation Features

• Implement friend groups
• Implement taste profile recommendations
• Implement lit lantern history / passport stamps
• Add background notifications for waves

Sprint 3 (Feb 10-23): Safety & Clarity

• Implement profile previews
• Add blocking/reporting
• Rewrite all user-facing copy for clarity
• Implement QR friend linking

Sprint 4 (Feb 24 - Mar 9): Engagement

• Design gamification system
• Implement status/levels (Phase 1)
• Build recommendation engine v1

Documentation Deliverables

• [ ] docs/features/PRIVACY_MODEL.md - Privacy approach document
• [ ] docs/features/ENGAGEMENT_STRATEGY.md - Comprehensive engagement plan
• [ ] docs/features/FRIEND_GROUPS.md - Friend groups feature spec
• [ ] docs/features/TASTE_PROFILE.md - Taste profile & recommendations spec
• [ ] docs/features/GAMIFICATION.md - Points, levels, streaks system
• [ ] docs/business/MONETIZATION_STRATEGY.md - Revenue model
• [ ] docs/business/COMPETITIVE_ANALYSIS.md - Competitor research
• [ ] docs/business/GTM_STRATEGY.md - Go-to-market plan

---

XII. Open Questions for Cofounder Discussion

1. Value Prop: Are we strengthening existing relationships or helping people meet strangers? (Can't be 50/50 - one must be primary)

2. Privacy Trade-off: How much stranger-matching info do we reveal before mutual interest? (Spectrum: nothing → aggregate data → preview → full profile)

3. Monetization: Venue subscription, commission, user freemium, or hybrid?

4. Capital Requirements: Event marketing needs budget for incentives. What's our capital situation?

5. Timeline: When do we want to test these features with real users? (Suggests feature priority)

6. Market Strategy: One city at a time (dense network) or multiple cities in parallel (broader coverage)?

7. Core Metric: What's our North Star metric? (DAU? Lanterns lit? Connections made? Offer redemptions?)

8. Identity fields: Should we collect gender now or defer? Final stance on anonymized, autogenerated username vs. user-set custom name.

9. Verification flows: Age verification method and phone number verification requirements (and vendor options).

---

XIII. Risks & Mitigation

Risk 1: Value Prop Confusion

Risk: Users don't understand what Lantern is for (friends? strangers? offers?)

Mitigation:

• Make primary use case crystal clear in onboarding
• User research to validate messaging
• Clear copy throughout app

Risk 2: Chicken-Egg Problem

Risk: Can't attract venues without users, can't attract users without venues

Mitigation:

• Make primary value user-centric (friends, discovery, history)
• Venue offers are bonus, not core value
• Launch relationship-first features first

Risk 3: Safety Incidents

Risk: Stranger connections lead to harassment, safety issues, PR crisis

Mitigation:

• Robust blocking/reporting from day 1
• Privacy-safe profile previews
• Clear safety guidelines for users
• Ability to disable stranger discovery entirely
• Build trust systems over time

Risk 4: Feature Bloat

Risk: Trying to implement all 14+ engagement ideas leads to unfocused product

Mitigation:

• Tier features (Tier 1 → 2 → 3)
• Ship iteratively
• Validate each feature before building next
• Use feature flags for gradual rollout

Risk 5: Monetization Misalignment

Risk: Choosing wrong monetization strategy locks us into bad incentives

Mitigation:

• Start with simplest model (venue subscription)
• Reserve right to change before scaling
• Talk to potential merchant partners early
• Test willingness to pay before building billing

---

Appendix: Cofounder Feedback Reference

[Original feedback preserved here for reference - omitted for brevity in this POA]

---

Document owner: Cofounders
Last updated: 2026-01-11
Next review: After strategic decisions (2026-01-18)
Status: Draft - awaiting cofounder alignment on critical decisions