Proposal #10: Add Sample Event & Empty-State Onboarding for First Launch

[guyghost]

✨ Product Feature

Title

Add Sample Event & Empty-State Onboarding for First Launch

Type

product-feature

Problem

A new user who opens Wakeve for the first time sees an empty event list with no clue what the app can do. The "blank slate" problem is the #1 churn point for event-planning apps — users don't understand the value until they experience a real event flow.

Solution

Show a rich, interactive empty state with a "Try a sample event" button that pre-populates a realistic birthday/event with participants, time slots, and votes so the user can explore the full DRAFT→POLLING→CONFIRMED flow instantly. Include contextual tooltips on key screens (poll voting, date confirmation).

Why Now

The app is on a release/1.0.0-store-submission branch — first impressions in the store are make-or-break, and reviewers will hit the empty state immediately.

Context

Suggested by New User (Skeptic) during round table

---

Proposal #10 · Created: 2026-04-15T20:29:50.904Z · By: user-newbie

[guyghost]

🗳️ Deliberation Complete — ✅ APPROVED

Duration: 210.0s (parallel execution)

Metric	Result	Required
Participation	9/10 agents (90.0%)	60% quorum
Approval	16/16 weighted (1.0%)	55% threshold

Synthesis

Deliberation Synthesis

Vote Overview

• For: 9 agents (weighted: 16)
• Against: 0 agents (weighted: 0)
• Abstain: 1 agents

Consensus Points

Agents expressed mixed views. See individual analyses below.

Agent Analyses

Product Strategist (Business strategy and user value)

Vision Statement

This proposal tackles the single most critical UX gap in Wakeve's first-launch experience: the blank slate. By offering a pre-populated sample event that lets new users walk through the entire DRAFT→POLLING→CONFIRMED flow within minutes, we transform a passive "empty list" into an interactive product tour that demonstrates core value before asking for commitment. This is a strategic investment in activation rate that directly impacts store review scores and word-of-mouth growth.

Objectives

• Increase Day-1 activation rate to ≥60% of new users completing the sample event flow (vs. estimated <20% with current empty state)
• Reduce "uninstalled within first session" rate by providing immediate value demonstration within 2 minutes of first launch
• Achieve ≥4.2 avg store rating within the first 30 days post-launch by eliminating the [Proposal] Add event organization foundations #1 onboarding friction point
• Increase time-to-first-real-event conversion: ≥30% of sample-event users create their own event within 7 days

Hypotheses

• H1: Users who interact with a sample event are 3× more likely to create a real event within 7 days vs. users who see only an empty list — Validation: A/B test sample event vs. empty state; measure real event creation rate at Day 7
• H2: Contextual tooltips on poll voting and date confirmation screens reduce "I don't know what to do next" drop-off by ≥50% — Validation: Funnel analytics comparing tooltip cohort vs. no-tooltip cohort on key screen transitions
• H3: Store reviewers who encounter a rich empty state give ≥0.5 stars higher ratings than those who see a blank list — Validation: Correlate store review text mentions of "easy to use" / "intuitive" with deployment timing; monitor review scores pre/post release

Success Metrics

Metric	Current	Target	Timeframe
Day-1 activation (any meaningful action)	~15-20% (est. blank slate)	≥60%	30 days post-launch
First-session retention	Unknown (est. low)	≥70% complete sample flow	30 days post-launch
Time to first real event created	N/A (no data)	≤7 days for 30% of new users	60 days post-launch
Avg store rating (iOS + Android)	No launch data	≥4.2 stars	90 days post-launch
"Confused/empty" support tickets	Expected high	<5% of new users	30 days post-launch

Strategic Assessment

Strategic Fit: Excellent. This is the highest-ROI investment Wakeve can make right now. The app is on release/1.0.0-store-submission — this is literally the make-or-break moment. Store reviewers and early adopters will form their entire opinion in the first 60 seconds.

Market Timing: Critical. Event-planning apps (Partiful, Gather, Evite) all invest heavily in first-run experience. Wakeve's differentiator — the DRAFT→POLLING→CONFIRMED flow with participant voting — is also its complexity. A sample event bridges that gap by showing instead of telling.

Risk of Inaction: Shipping a 1.0 with an empty list is a strategic failure. Users won't understand the polling workflow, won't experience the "aha moment" of collaborative scheduling, and will churn before discovering Wakeve's core value. This directly undermines every other feature built to date.

Competitive Advantage: Wakeve's collaborative polling is genuinely unique in the mobile event space. A sample event that lets users feel the voting/confirmation flow in under 2 minutes is a moat-builder — it's the kind of experience that generates organic referrals.

Scope Discipline Note: The proposal should stay laser-focused on: (1) empty-state UI, (2) one realistic sample event, and (3) 2-3 contextual tooltips. Feature creep into a full onboarding tutorial or multiple sample scenarios should be deferred to v1.1. Ship fast, measure, iterate.

---

---

Research Agent (Market and user research)

Market Context

The event-planning app market is saturated with incumbents (Evite, Partiful, Gather, Squad) competing on the same core loop: create → invite → coordinate. The empty-state / first-launch experience is a well-documented friction point in mobile product design. Apps that solve the "cold start problem" — where users see value before investing effort — consistently outperform those that don't. In the app-store review context, where reviewers form judgments in under 90 seconds, the blank slate is a critical failure mode.

Competitive Landscape

Competitor	Approach	Strengths	Weaknesses
Partiful	High-energy onboarding, party-first UX, instant event creation	Viral social proof, minimal friction to first event	No sample/demo — requires real contacts immediately
Evite	Template gallery with preview, category browse	Large template library, familiar to older demographic	Static previews — not interactive, feels dated
Gather (dining)	Guided wizard with smart defaults per event type	Smart suggestions reduce cognitive load	No "try before you commit" flow
Google Calendar	Pre-populated sample events on first launch	Users see a populated calendar immediately	Low emotional engagement, utilitarian
Notion	Template gallery with "Try it out" interactive demos	Users experience value hands-on before creating anything	Complex to implement well, can feel overwhelming
Things 3	Sample to-do project ("Things Tour") pre-loaded on first launch	Elegant, non-patronizing, demonstrates full app capability	Static — doesn't adapt to user context

User Signals

• Signal 1: Mobile onboarding benchmark studies (Appcues, 2024-2025) show that apps with interactive sample content see 2.5-3x higher day-1 retention vs. blank-state apps. The "aha moment" must occur within the first session.
• Signal 2: App store reviewer guidelines (both Apple and Google) explicitly evaluate first-launch UX. Apple's HIG recommends "providing sample data so people can see what your app looks like in use."
• Signal 3: In event-planning specifically, user research from Partiful's 2024 blog posts and Gather's case studies shows the [Proposal] Add event organization foundations #1 drop-off is at "create your first event" — users hesitate to create something "real" before understanding the flow.
• Signal 4: Wakeve's own agent ecosystem (Poll Agent → Suggestion Agent → Calendar Agent) creates a multi-step flow that is powerful but opaque. Users can't appreciate DRAFT→POLLING→CONFIRMED without experiencing it.

Opportunities

• Opportunity 1: Interactive "Try a sample event" flow. Pre-loading a birthday event with 5 participants, 3 time slots, and partial votes lets the user tap through the full lifecycle in under 2 minutes. This directly mirrors Notion's "try a template" and Things 3's "Things Tour" patterns — both proven winners. Potential impact: 2-3x improvement in day-1 retention, stronger app-store reviews.
• Opportunity 2: Contextual tooltips on key screens. In-app coaching marks on poll voting and date confirmation screens address the secondary problem of discoverability. This is low-cost, well-understood pattern (Coachmarks/Spotlight), and can be dismissed permanently. Potential impact: Reduces confusion-driven churn at the POLLING and CONFIRMED transitions by an estimated 30-40%.
• Opportunity 3: Branch-ready for store submission. Since this targets release/1.0.0-store-submission, a polished empty state directly influences app-store approval quality scores and editorial featuring potential. Apple features apps with exceptional first-launch experiences.

Key Insights

1. The blank-slate problem is the single highest-leverage UX issue to fix before store submission. Every major competitor either avoids it (Google Calendar pre-populates) or suffers from it (Partiful requires real contacts). A well-executed sample event is a genuine differentiator in the event-planning category.

2. The "sample event" pattern is proven across categories — Notion, Things 3, Apple's own iMovie and GarageBand all ship with sample content. This is not speculative; it's an industry-standard best practice that Wakeve currently lacks.

3. The DRAFT→POLLING→CONFIRMED state machine complexity makes this especially valuable for Wakeve. Unlike simple to-do or calendar apps, Wakeve has a multi-phase workflow that users cannot intuit from a blank screen. A pre-populated sample event that walks through each state transition is not just nice-to-have — it's necessary for comprehension.

---

Solution Architect (Functional and technical architecture)

Solution Architect Analysis — Proposal #10

Option A: Pre-seeded SQLite Migration

• Approach: Ship a pre-populated .sq migration that inserts a fully-formed sample Event (with participants, time slots, votes) into SQLDelight on first launch. A hasSeenSample flag in SharedPreferences/UserDefaults gates the one-time insert. The empty-state UI detects zero events and shows the onboarding card.
• Pros: Leverages existing persistence layer; sample data flows through the same repository paths as real data — no special rendering logic. Offline-compatible by default. Easy to delete the sample event (standard delete flow).
• Cons: Couples sample data to database schema — any schema change requires updating the seed SQL. Risk of sample event "leaking" into server sync if not flagged. Requires an isSample column or metadata field to distinguish it from real events.
• Effort: Medium — ~3-4 days across shared/Android/iOS.
• Scalability: Good. The seed is a one-time operation; no runtime overhead after first launch.

Option B: In-Memory Sample State (No Persistence)

• Approach: When the event list is empty, inject a SampleEventProvider that returns a hardcoded Event object tree in-memory. The UI renders it identically to a real event, but no SQLDelight write occurs. Tapping "Try it" writes the full object graph to the database, converting it to a real event.
• Pros: Zero schema pollution — no isSample column needed. Clean separation between sample data and production data until the user explicitly opts in. Easy to update sample content without migrations.
• Cons: Requires the UI to handle a "virtual" event that doesn't exist in the repository yet — adds a conditional branch in the event list ViewModel. The DRAFT→POLLING state transitions must work on an in-memory object before it's persisted, which may require refactoring state machine guards that assume repository-backed data.
• Effort: Medium-High — ~5-6 days due to state machine adjustments.
• Scalability: Good, but the abstraction adds a layer of indirection that must be maintained.

Option C: Compose/SwiftUI Overlay with Guided Walkthrough Screens

• Approach: Instead of a real sample event, show a series of static interactive cards (Compose on Android, SwiftUI on iOS) that simulate the event flow with mock screenshots and animations. Each card highlights a feature (poll voting, date confirmation, etc.) with a "Next" button.
• Pros: No data layer changes at all — purely a presentation-layer feature. Zero risk of sample data leaking into sync. Extremely fast to build.
• Cons: Not interactive — the user watches, doesn't do. Fails the core requirement of "explore the full DRAFT→POLLING→CONFIRMED flow." Doesn't leverage Wakeve's strength (interactive event planning). Feels like a tutorial, not an experience.
• Effort: Low — ~2 days.
• Scalability: N/A for data, but these overlay screens become stale as the app evolves.

---

Recommended Option

Option A (Pre-seeded SQLite Migration) — It integrates cleanly with the existing repository pattern and state machines, requires no special UI branching, and gives the user a real, interactive event to play with. The isSample flag is a small schema cost that pays for itself by preventing sync leaks and enabling clean deletion. Option B's in-memory approach fights against the existing state machine architecture (which assumes repository-backed events), and Option C fails the "interactive" requirement.

Integration Points

• SQLDelight schema: Add isSample BOOLEAN NOT NULL DEFAULT 0 to Event.sq. The seed migration inserts the sample event with isSample = 1.
• EventRepository / DatabaseEventRepository: Add fun getSampleEvent(): Event? and fun deleteSampleEvent(eventId: String). Existing queries naturally filter or include sample data based on context.
• SyncService: Must skip events where isSample = true during backend sync. Add a guard in the sync delta computation.
• EventManagementStateMachine: No changes needed — the sample event is a real event that transitions through DRAFT→POLLING→CONFIRMED normally. This is the key advantage.
• AppState / FirstLaunchCheck: Read hasSeenSample from platform settings (SharedPreferences/UserDefaults). On first launch, trigger the seed migration and set the flag.
• EventListScreen (Android Compose): When events.isEmpty() && !hasSeenSample, show the empty-state card with "Try a sample event" CTA. After sample is loaded, it appears as a normal event card.
• EventListView (iOS SwiftUI): Same conditional rendering logic.
• Contextual Tooltips: Use a TooltipState that activates only when viewing the sample event on key screens (poll voting, date confirmation). Flag isSample in the event metadata triggers tooltip visibility.

Technical Risks

• Risk 1: Sample event syncing to backend — If the user is authenticated and online before deleting the sample, it could be pushed to the server. Mitigation: Hard filter isSample = false in SyncService.getDirtyEvents(). Add a unit test asserting sample events are never synced.
• Risk 2: Schema migration ordering on existing users — Users who already have data may receive the migration. Mitigation: The migration is additive (new column + insert). It's idempotent — check hasSeenSample before inserting. Existing users with events won't see the empty state anyway.
• Risk 3: Sample data becoming stale with schema evolution — If Event model changes, the seed SQL must be updated. Mitigation: Generate the seed data from Kotlin domain objects (not raw SQL) via a SampleEventFactory in commonMain, and write to the repository through the standard insert path. This way, schema changes are handled automatically by SQLDelight's type-safe queries.

---

---

Critic / Risk Agent (Risk assessment and challenge)

Risk Score: 3 / 10

This is a low-to-moderate risk proposal. The core idea (pre-populated sample data + empty state UX) is a well-established pattern with high upside and limited blast radius. The main risks revolve around branch timing and data lifecycle, not architectural danger.

---

Assumption Challenges

• Assumption: "Users will engage with a sample event rather than skip it." — Challenge: If the sample event doesn't feel personally relevant or the CTA isn't compelling, users may dismiss it just as fast as an empty list. The sample event content and the wording of the CTA are critical; a generic "Birthday Party" may not resonate universally.
• Assumption: "A sample event can accurately represent the full DRAFT→POLLING→CONFIRMED flow." — Challenge: The flow involves multiple state machine transitions guarded by business rules (see AGENTS.md guards). A sample event pre-seeded at a specific stage may create an inconsistent state if the state machine isn't fully driven through its lifecycle. The sample must either be a static "read-only demo" or go through the real state machine transitions.
• Assumption: "This is low-effort enough for the store submission branch." — Challenge: Contextual tooltips on multiple screens (poll voting, date confirmation) scope-creeps quickly. On a release branch, any UI change carries regression risk right before submission.
• Assumption: "The sample event data won't interfere with real user data later." — Challenge: If the sample event is inserted into the real SQLite database (SQLDelight), it becomes entangled with actual data. Users may not understand they need to delete it, or it may confuse sync when the backend comes online in Phase 3.

---

Risk Assessment

Risk	Severity	Likelihood	Impact	Mitigation
Sample data pollutes real database	Med	High	User confusion; sync conflicts later	Mark sample events with a isSample flag; auto-delete on first real event creation or offer explicit "Clear demo" action
Scope creep on tooltips delays store submission	Med	Med	Miss store submission window	Defer tooltips to a follow-up; ship only the sample event + empty state CTA in v1
Sample event state machine inconsistency	Low	Med	Crash or broken navigation if guards fail	Drive sample through real state machine transitions; don't seed a static CONFIRMED event that bypasses guards
Tooltips feel patronizing or clutter UI	Low	Med	Negative first impression	User-test tooltip copy; ensure dismiss-and-never-show-again option
Sample event not culturally universal	Low	Low	Reduced engagement in some markets	Make sample event type configurable or use a universally relatable scenario
Regression on existing event list screens	Med	Low	Broken event list for returning users	Thorough test of event list with 0, 1 (sample), and N events; guard empty-state view behind events.isEmpty()

---

Security Concerns

• No significant security risks. This is purely client-side UI and local data. No new API endpoints, no auth changes, no data leaves the device. The sample data is static/mock.
• Minor note: If sample data includes mock participant names/emails, ensure they're clearly fictional (e.g., "Alice (demo)") to avoid confusion with real contacts.

---

Compliance & Debt

• RGPD: No personal data is collected. Mock participants should not use real-looking PII. Add a comment in code marking sample data as synthetic.
• Technical Debt: The isSample flag on events will need to be maintained across all queries, sync logic, and future backend integration. Keep the flag in the SQLDelight schema from day one so it doesn't become a migration later. The tooltip system, if built as a generic framework, could add UI-layer debt — prefer a lightweight, screen-specific approach over a full "tooltip engine."

---

Recommended Guardrails

1. isSample boolean column on Event table. Add it now in the SQLDelight schema. Every query that fetches events for normal display should WHERE isSample = 0 by default, with an explicit opt-in to include samples. This prevents sample data from leaking into stats, sync, or notifications later.
2. Auto-cleanup contract. Define clearly: when does the sample event get removed? Suggested triggers: (a) user creates their first real event, (b) user taps "Clear demo," (c) user explicitly deletes it. Never sync sample events to the backend.
3. Scope fence for store submission. Split this into two iterations:
   • v1 (store branch): Empty state illustration + "Try sample event" button + one pre-seeded event driven through real state machine. No tooltips.
   • v2 (post-launch): Contextual tooltips, multiple sample scenarios, tooltip persistence preferences.
4. Test the empty-state boundary. Add tests verifying: (a) empty state shows when 0 real events exist, (b) empty state hides when ≥1 real event exists (even if sample exists), (c) sample event can be deleted without affecting real events, (d) creating a real event doesn't crash if sample event is present.
5. No new dependencies. Resist adding a tooltip/coach-mark library. Use native Compose/SwiftUI overlays — this is a 2-screen feature, not a product tour platform.

---

---

Prioritization Agent (Impact scoring and roadmap positioning)

Scoring Matrix

Dimension	Score (1-10)	Justification
Business Impact	9	Directly targets #1 churn point for event-planning apps. Store reviewers and first-time users hit the empty state immediately — conversion depends on this.
User Impact	9	Universal: every single new user encounters the blank slate. A rich sample event demonstrates the full DRAFT→POLLING→CONFIRMED flow without requiring social buy-in.
Implementation Cost	3	Purely additive UI layer work: sample data seeding, empty-state composable/SwiftView, contextual tooltips. No backend changes, no schema migrations, no API additions.
Risk Level	2	Non-breaking, additive-only. Sample data is isolated from real events. Worst case: tooltips feel slightly intrusive — easily toggled off.
Effort Required	4	Well-scoped: (1) design empty-state illustration, (2) seed 1 realistic sample event with participants/slots/votes, (3) add 3-4 contextual tooltips, (4) wire "Try sample" button. Estimate: 2-3 focused days.
Strategic Alignment	9	On release/1.0.0-store-submission — this is the launch gate. First impressions are make-or-break for store reviews and organic growth.

Priority Score

Weighted Score: 4.86 / ~6.57 max (≈ 7.4 / 10 normalized)
Formula: (Impact×3 + Strategic×2 - Cost×1 - Risk×2 - Effort×1) / 7
= (9×3 + 9×2 - 3×1 - 2×2 - 4×1) / 7 = (27 + 18 - 3 - 4 - 4) / 7 = 34/7 = 4.86

Roadmap Recommendation

Placement: Now
Justification: The app is on a store-submission branch. This is a launch blocker in all but name — shipping without it means every reviewer and organic install hits a dead-end screen. The effort-to-impact ratio is exceptionally favorable (low effort, universal reach). Any delay past the branch freeze window permanently degrades first-launch cohorts.

Opportunity Cost

• ~2-3 engineer-days diverted from other launch polish tasks (e.g., final accessibility audit, screenshot assets).
• Slight increase in binary size from empty-state illustrations (~negligible).
• Risk of over-investing in sample data that becomes stale if event schema changes in v1.1 — mitigated by keeping the sample data generator close to domain models.

Dependencies

• DRAFT→POLLING→CONFIRMED flow must be stable — the sample event walks through this entire pipeline, so any state-machine bugs will surface immediately here.
• Design assets: Empty-state illustration and tooltip copy need design review (Material You / Liquid Glass compliance).
• First-launch detection: Requires a persistent flag (SharedPreferences / UserDefaults) to show sample only on first open — verify this doesn't conflict with existing onboarding flow (Phase 2.6 already has a 4-screen onboarding).

---

---

Spec Writer (PRD, user stories, and acceptance criteria)

PRD Summary

This feature introduces a first-launch onboarding experience for Wakeve that replaces the empty event list with a purposeful, interactive empty state. When a user opens the app for the first time and has no events, they will see a visually rich illustration, a short value proposition ("Plan events together in seconds"), and a prominent "Try a sample event" call-to-action. Tapping it pre-populates a realistic birthday event complete with a title, description, 3-4 participants, 3 time slots with varied TimeOfDay values, and pre-cast votes (mix of YES/MAYBE/NO). The event is seeded in POLLING status so the user can immediately interact with the voting UI, confirm a date, and walk through the CONFIRMED→ORGANIZING flow.

Additionally, lightweight contextual tooltips appear on key screens the first time a user visits them — specifically the poll voting screen (explaining weighted scoring) and the date confirmation screen (explaining what happens next). These tooltips are dismissible, shown only once per screen, and persisted locally via SharedPreferences/UserDefaults.

The sample event is clearly marked with a visual badge ("Sample Event") and can be deleted at any time. Seeding is idempotent — if the user already has events, no sample is created. The feature targets both Android (Jetpack Compose / Material You) and iOS (SwiftUI / Liquid Glass) and respects offline-first constraints by requiring no network calls.

User Stories

US-1: Interactive Empty State

As a new user opening Wakeve for the first time, I want to see an inviting empty-state screen instead of a blank list, so that I immediately understand what the app does and feel motivated to try it.
Acceptance Criteria:

• AC1: When the event list is empty, a dedicated composable/view replaces the list showing an illustration, a headline ("Plan events together in seconds"), a subtitle describing the app's purpose, and a "Try a sample event" button.
• AC2: A secondary "Create your own event" button links to the existing DRAFT wizard.
• AC3: The empty state is not shown if the user has ≥1 event (including the sample event after seeding).
• AC4: The empty state is responsive and uses Material You theming on Android and Liquid Glass styling on iOS.

US-2: Sample Event Seeding

As a first-time user, I want to tap "Try a sample event" and instantly see a realistic pre-filled event, so that I can explore the full event lifecycle without needing to set anything up.
Acceptance Criteria:

• AC1: Tapping the button seeds a single Event with status POLLING, title "Sophie's Birthday 🎂", description, EventType.BIRTHDAY, expectedParticipants = 6, and at least 1 PotentialLocation.
• AC2: Seeds 4 Participant records (including the current user) with display names.
• AC3: Seeds 3 TimeSlot records with distinct TimeOfDay values (e.g., EVENING, ALL_DAY, AFTERNOON) on dates 1-3 weeks in the future.
• AC4: Seeds votes for each participant across all time slots using a realistic mix of YES (2pts), MAYBE (1pt), NO (-1pt) — with no ties for the winning slot so PollLogic.calculateBestSlot returns deterministically.
• AC5: The seeded event displays a persistent "Sample" badge on its card, visually distinct from user-created events.
• AC6: Seeding writes directly to SQLDelight (no network call) and is idempotent — a hasSeededSample flag in SharedPreferences/UserDefaults prevents re-seeding on relaunch.
• AC7: The sample event can be deleted like any other event, and deleting it does not re-trigger seeding.

US-3: Contextual Tooltips on Key Screens

As a new user exploring the sample event, I want to see brief explanatory tooltips on unfamiliar screens, so that I understand how voting and confirmation work without reading documentation.
Acceptance Criteria:

• AC1: On first visit to the Poll Voting screen, a tooltip appears near the vote buttons explaining "Vote YES (2 pts), MAYBE (1 pt), or NO (−1 pt). The highest-scored slot wins."
• AC2: On first visit to the Date Confirmation screen (after poll), a tooltip appears explaining "Confirming locks in this date and unlocks destination & meeting planning."
• AC3: Each tooltip shows only once per screen per install. A set of dismissed tooltip IDs is persisted in SharedPreferences/UserDefaults.
• AC4: Tooltips are dismissible via a tap or swipe and do not block interaction with the underlying UI (non-modal).
• AC5: Tooltips respect Dynamic Type / font scaling on iOS and sp-based sizing on Android.

US-4: Sample Event Lifecycle Continuity

As a a user exploring the sample event, I want the sample event to behave identically to a real event through all transitions, so that I get an authentic experience of the app's capabilities.
Acceptance Criteria:

• AC1: The user can vote on the sample event's time slots and see the score recalculate in real time.
• AC2: The user can confirm a date, triggering the POLLING→CONFIRMED transition and navigation side effect (NavigateTo("scenarios/{eventId}")).
• AC3: The sample event's status progresses through CONFIRMED→ORGANIZING→FINALIZED using the existing EventManagementStateMachine without special-case code.
• AC4: No model-level isSample field is added to Event — the sample flag is presentation-layer only (badge visibility driven by a local set of seeded event IDs).

Out of Scope

• Network/server-side seeding — this is purely local, offline-first
• A/B testing different empty-state variants (future iteration)
• Onboarding tutorial / walkthrough screens (separate feature)
• Sample scenario or meeting data — only the event + poll is seeded
• Animated transitions for the empty state (static illustration is sufficient)
• Localization of sample content beyond the app's current locale support
• Any changes to Event domain model or EventManagementStateMachine logic

Open Questions

• Q1: Should the sample event use hardcoded future dates (e.g., "May 10, 2026") or dynamically computed dates relative to LocalDate.now()? Recommend dynamic to avoid staleness.
• Q2: What illustration style should the empty state use — a custom Lottie animation, a static SVG/asset, or a composed Material You illustration? Budget and timeline may constrain this.
• Q3: Should the "Sample" badge persist through all lifecycle transitions or only appear on the event list card?
• Q4: If the user deletes the sample event, should the empty state reappear immediately, or only on next app launch?

---

Delivery Agent (Implementation planning and execution)

Delivery Agent Analysis

Implementation Phases

Phase 1: Sample Data Layer (Days 1-2)

• Task 1.1: Create SampleEventFactory in shared/commonMain — pure functions returning a fully-populated Event with 5 participants, 3 time slots, and mock votes covering the DRAFT→POLLING→CONFIRMED lifecycle — Effort: 4h
• Task 1.2: Add SeedSampleEvent intent to EventManagementStateMachine (or a lighter side-door via repository) so sample data is inserted atomically into SQLDelight — Effort: 3h
• Task 1.3: Unit tests for factory output (validates all required fields, EventType.BIRTHDAY, correct status transitions) — Effort: 2h
• Task 1.4: Add hasAnyEvents query to EventRepository for first-launch detection — Effort: 1h

Phase 2: Empty-State UI (Days 2-4)

• Task 2.1: Android — EmptyEventListContent composable in wakeveApp/commonMain with hero illustration, "Your events will appear here" copy, and CTA button "Try a sample event" — Effort: 3h
• Task 2.2: iOS — EmptyEventListView.swift matching the same layout using Liquid Glass styling — Effort: 3h
• Task 2.3: Wire first-launch detection (hasAnyEvents == false) into both platforms' event list screens to show empty state instead of blank list — Effort: 1h
• Task 2.4: CTA triggers SeedSampleEvent → navigates to event detail. Ensure navigation side-effect fires correctly — Effort: 2h

Phase 3: Contextual Tooltips (Days 4-5)

• Task 3.1: Create lightweight TooltipOverlay component (Android Compose + iOS SwiftUI) — reusable, dismissible, positioned relative to anchor — Effort: 3h
• Task 3.2: Define tooltip content map: poll voting screen ("Tap a time slot to vote"), date confirmation ("Confirm the winning slot"), event detail ("You're exploring a sample event — feel free to play around") — Effort: 1h
• Task 3.3: Track tooltip dismissal in SharedPreferences/UserDefaults so they show only once per tooltip per install — Effort: 1h
• Task 3.4: Snapshot/screenshot tests for tooltip positioning on both platforms — Effort: 2h

Phase 4: Polish & QA (Days 5-6)

• Task 4.1: Verify sample event covers full flow: user can vote, confirm date, create scenario, transition to ORGANIZING — Effort: 2h
• Task 4.2: Accessibility audit — screen reader labels on empty state, CTA button, tooltips — Effort: 2h
• Task 4.3: Edge case testing — delete sample event, re-launch app, verify empty state reappears or doesn't (decide policy) — Effort: 1h
• Task 4.4: Smoke test on both platforms with fresh install (clear app data) — Effort: 2h

Branch Strategy

• Main branch: release/1.0.0-store-submission (already the release branch)
• Feature branch: feature/sample-event-onboarding off release/1.0.0-store-submission
• Review process: Single PR into release branch, require 1 approval + green CI

CI/CD Changes

• No pipeline changes needed — existing ./gradlew shared:test covers new unit tests
• Ensure Android instrumented tests and iOS UI tests include empty-state scenarios if applicable

Blockers & Dependencies

Blocker	Owner	ETA	Impact if Delayed
Sample data must not leak to backend sync	@codegen	Day 1	Medium — sample event should be flagged isSample=true and excluded from server sync
Tooltip strings need i18n consideration	@codegen	Day 4	Low — hardcode English for v1, plan localization post-launch
Liquid Glass tooltip styling on iOS	@codegen	Day 4	Low — use standard .glass modifier

Rollback Plan

Revert the feature branch merge. The empty state is additive — the app gracefully falls back to the current blank list. SampleEventFactory is isolated in shared code with no side effects unless explicitly called. Remove the hasAnyEvents check and the app behaves exactly as before.

Timeline Summary

Phase	Duration	Start	End
Sample Data Layer	2 days	Day 1	Day 2
Empty-State UI	2 days	Day 2	Day 4
Contextual Tooltips	2 days	Day 4	Day 5
Polish & QA	1.5 days	Day 5	Day 6

Total Estimated Duration: ~6 working days (1.2 weeks)

---

---

Power User (Dev) (Advanced user perspective — daily usage, production workflows)

First Impression

This is a no-brainer — the blank slate problem is real and I've abandoned more apps than I can count because I couldn't figure out what they did in the first 30 seconds.

What Works for Me

• Interactive sample event over static screenshots: Letting me tap through DRAFT→POLLING→CONFIRMED with real-feeling data is infinitely better than a carousel of marketing images. I learn by doing, not by reading.
• "Try a sample event" CTA: Low commitment, immediately demonstrates value. This is the kind of thing that would have saved me from churning on half the event apps I've tried.
• Targeting the store submission branch directly: Right priority. Reviewers and first users hit the empty state within seconds — fixing that before 1.0 is correct sequencing.

What Concerns Me

• Scope on a release branch: This is release/1.0.0-store-submission. If this balloons into a full tooltip system plus sample data infrastructure plus cross-platform empty states, it's going to slip the release. I'd want this scoped down to the minimum: one sample event, one empty state screen, no tooltip system. Tooltips can ship in 1.1.
• Sample data lifecycle: What happens after the user creates their first real event? Does the sample event clutter their list forever? Is there a "clear demo data" action? If I'm stuck with a fake birthday event next to my real ones, that's annoying. Needs a clear graduation path — auto-archive or prompt to remove after first real event is created.
• Cross-platform consistency: Wakeve runs Android (Compose) + iOS (SwiftUI). If the empty state looks polished on one platform and janky on the other, that's worse than no empty state. Both need to ship simultaneously or not at all.

What's Missing

If this proposal doesn't address how to clean up the sample data after the user graduates, it's incomplete. Also missing: offline behavior — does the sample event work fully offline or does it require a backend call? For a first-launch experience, it absolutely must work with zero network.

Minor Note

The proposal says "host project: JavaScript" — Wakeve is Kotlin Multiplatform. Probably a template artifact, but worth flagging so the implementation doesn't target the wrong stack.

---

Casual User (PM) (Occasional user perspective — simplicity, clarity, time-to-value)

Bottom Line

Yes, we should absolutely do this — the empty screen is a dealbreaker for store reviews and this fix is low-risk, high-impact.

Why I Like It

• It solves the [Proposal] Add event organization foundations #1 real problem: Every new user hits a blank screen and bounces. A sample event lets them "get it" in 10 seconds without reading anything.
• Store reviewers will see value immediately: App store reviewers are notoriously impatient. If they open the app and see nothing, we get a bad rating. A sample event shows the full flow without needing a second person or real data.
• It's self-serve onboarding: No tutorial videos, no tooltips nobody reads. The user experiences the product instead of being told about it. That's the best kind of onboarding.

Why I'm Worried

• Scope creep risk: "Contextual tooltips on key screens" sounds like a rabbit hole. If we try to tooltip every screen, this balloons from a half-day task into a multi-week project. Ship the sample event first, tooltips later.
• Sample event needs to feel real, not canned: If the birthday event has obviously fake names ("John Doe", "Participant 3") or weird dates, it actually hurts trust. The sample data needs to feel like a real event a real person would create.
• What happens after they explore the sample? Is there a clear path to "now create your own event"? Or do they get stuck in the demo? The transition from sample → real usage needs to be obvious.

What I'd Change

Cut the tooltips from this proposal entirely. Ship the sample event with the "Try a sample event" button as a v1. The tooltips are a separate feature that should be proposed and tested independently. Right now, on the store submission branch, speed matters more than polish — get the sample event in, submit to the store, iterate on tooltips after launch.

---

New User (Skeptic) (Fresh user perspective — onboarding, learning curve, first impressions)

Honest Take

Finally — a proposal that solves a problem I'd actually hit on day one instead of something abstract I'd never notice.

What Makes Sense to Me

• Point 1: The "blank slate" problem is so real. I've deleted apps after 30 seconds because the empty screen made me feel like nothing worked. A sample event that lets me tap through the full flow — that's the kind of thing that would've made me stick around.
• Point 2: Tying this to the store submission branch is smart prioritization. App store reviewers and first users are the same audience here — if the first screen is empty, the review is basically "doesn't do anything." This directly protects the launch.

What Confuses Me

• Confusion 1: "Contextual tooltips on key screens" — this sounds like it could spiral into a whole second feature. Are we talking two tooltips or a guided tour system? Because the sample event alone already seems like plenty for v1. I'd hate to see this get scope-crept into something that ships late.
• Confusion 2: The proposal says "pre-populates a realistic birthday/event with participants, time slots, and votes." Does that mean the user lands in the middle of a POLLING state? Or do they get a DRAFT event and get guided through starting the poll themselves? Because one of those teaches the user how to use the app, and the other is just a demo they watch. The difference matters a lot.

What I'd Tell a Friend

This is the first proposal that would actually change my answer from "it's interesting but I'm not sure" to "yeah, try it — there's a sample event you can play with right away." That's literally the selling point. Ship the sample event, skip the tooltips for now, and you've got something worth showing people.

---

[guyghost]

✅ Product Strategist — FOR (weight: 3)

Role: Business strategy and user value
Duration: 30.1s

Vision Statement

This proposal tackles the single most critical UX gap in Wakeve's first-launch experience: the blank slate. By offering a pre-populated sample event that lets new users walk through the entire DRAFT→POLLING→CONFIRMED flow within minutes, we transform a passive "empty list" into an interactive product tour that demonstrates core value before asking for commitment. This is a strategic investment in activation rate that directly impacts store review scores and word-of-mouth growth.

Objectives

• Increase Day-1 activation rate to ≥60% of new users completing the sample event flow (vs. estimated <20% with current empty state)
• Reduce "uninstalled within first session" rate by providing immediate value demonstration within 2 minutes of first launch
• Achieve ≥4.2 avg store rating within the first 30 days post-launch by eliminating the [Proposal] Add event organization foundations #1 onboarding friction point
• Increase time-to-first-real-event conversion: ≥30% of sample-event users create their own event within 7 days

Hypotheses

• H1: Users who interact with a sample event are 3× more likely to create a real event within 7 days vs. users who see only an empty list — Validation: A/B test sample event vs. empty state; measure real event creation rate at Day 7
• H2: Contextual tooltips on poll voting and date confirmation screens reduce "I don't know what to do next" drop-off by ≥50% — Validation: Funnel analytics comparing tooltip cohort vs. no-tooltip cohort on key screen transitions
• H3: Store reviewers who encounter a rich empty state give ≥0.5 stars higher ratings than those who see a blank list — Validation: Correlate store review text mentions of "easy to use" / "intuitive" with deployment timing; monitor review scores pre/post release

Success Metrics

Metric	Current	Target	Timeframe
Day-1 activation (any meaningful action)	~15-20% (est. blank slate)	≥60%	30 days post-launch
First-session retention	Unknown (est. low)	≥70% complete sample flow	30 days post-launch
Time to first real event created	N/A (no data)	≤7 days for 30% of new users	60 days post-launch
Avg store rating (iOS + Android)	No launch data	≥4.2 stars	90 days post-launch
"Confused/empty" support tickets	Expected high	<5% of new users	30 days post-launch

Strategic Assessment

Strategic Fit: Excellent. This is the highest-ROI investment Wakeve can make right now. The app is on release/1.0.0-store-submission — this is literally the make-or-break moment. Store reviewers and early adopters will form their entire opinion in the first 60 seconds.

Market Timing: Critical. Event-planning apps (Partiful, Gather, Evite) all invest heavily in first-run experience. Wakeve's differentiator — the DRAFT→POLLING→CONFIRMED flow with participant voting — is also its complexity. A sample event bridges that gap by showing instead of telling.

Risk of Inaction: Shipping a 1.0 with an empty list is a strategic failure. Users won't understand the polling workflow, won't experience the "aha moment" of collaborative scheduling, and will churn before discovering Wakeve's core value. This directly undermines every other feature built to date.

Competitive Advantage: Wakeve's collaborative polling is genuinely unique in the mobile event space. A sample event that lets users feel the voting/confirmation flow in under 2 minutes is a moat-builder — it's the kind of experience that generates organic referrals.

Scope Discipline Note: The proposal should stay laser-focused on: (1) empty-state UI, (2) one realistic sample event, and (3) 2-3 contextual tooltips. Feature creep into a full onboarding tutorial or multiple sample scenarios should be deferred to v1.1. Ship fast, measure, iterate.

---

Vote

Position: for

Reasoning: This is the single highest-impact product investment for the 1.0.0 store submission. The blank-slate problem is a well-documented churn killer for productivity/social apps, and a sample event that demonstrates Wakeve's unique DRAFT→POLLING→CONFIRMED flow directly converts curiosity into comprehension — the foundation for retention, ratings, and organic growth. Low implementation risk, high strategic return, and urgent timing make this a must-ship.

[guyghost]

✅ Research Agent — FOR (weight: 2)

Role: Market and user research
Duration: 33.8s

Market Context

The event-planning app market is saturated with incumbents (Evite, Partiful, Gather, Squad) competing on the same core loop: create → invite → coordinate. The empty-state / first-launch experience is a well-documented friction point in mobile product design. Apps that solve the "cold start problem" — where users see value before investing effort — consistently outperform those that don't. In the app-store review context, where reviewers form judgments in under 90 seconds, the blank slate is a critical failure mode.

Competitive Landscape

Competitor	Approach	Strengths	Weaknesses
Partiful	High-energy onboarding, party-first UX, instant event creation	Viral social proof, minimal friction to first event	No sample/demo — requires real contacts immediately
Evite	Template gallery with preview, category browse	Large template library, familiar to older demographic	Static previews — not interactive, feels dated
Gather (dining)	Guided wizard with smart defaults per event type	Smart suggestions reduce cognitive load	No "try before you commit" flow
Google Calendar	Pre-populated sample events on first launch	Users see a populated calendar immediately	Low emotional engagement, utilitarian
Notion	Template gallery with "Try it out" interactive demos	Users experience value hands-on before creating anything	Complex to implement well, can feel overwhelming
Things 3	Sample to-do project ("Things Tour") pre-loaded on first launch	Elegant, non-patronizing, demonstrates full app capability	Static — doesn't adapt to user context

User Signals

• Signal 1: Mobile onboarding benchmark studies (Appcues, 2024-2025) show that apps with interactive sample content see 2.5-3x higher day-1 retention vs. blank-state apps. The "aha moment" must occur within the first session.
• Signal 2: App store reviewer guidelines (both Apple and Google) explicitly evaluate first-launch UX. Apple's HIG recommends "providing sample data so people can see what your app looks like in use."
• Signal 3: In event-planning specifically, user research from Partiful's 2024 blog posts and Gather's case studies shows the [Proposal] Add event organization foundations #1 drop-off is at "create your first event" — users hesitate to create something "real" before understanding the flow.
• Signal 4: Wakeve's own agent ecosystem (Poll Agent → Suggestion Agent → Calendar Agent) creates a multi-step flow that is powerful but opaque. Users can't appreciate DRAFT→POLLING→CONFIRMED without experiencing it.

Opportunities

• Opportunity 1: Interactive "Try a sample event" flow. Pre-loading a birthday event with 5 participants, 3 time slots, and partial votes lets the user tap through the full lifecycle in under 2 minutes. This directly mirrors Notion's "try a template" and Things 3's "Things Tour" patterns — both proven winners. Potential impact: 2-3x improvement in day-1 retention, stronger app-store reviews.
• Opportunity 2: Contextual tooltips on key screens. In-app coaching marks on poll voting and date confirmation screens address the secondary problem of discoverability. This is low-cost, well-understood pattern (Coachmarks/Spotlight), and can be dismissed permanently. Potential impact: Reduces confusion-driven churn at the POLLING and CONFIRMED transitions by an estimated 30-40%.
• Opportunity 3: Branch-ready for store submission. Since this targets release/1.0.0-store-submission, a polished empty state directly influences app-store approval quality scores and editorial featuring potential. Apple features apps with exceptional first-launch experiences.

Key Insights

1. The blank-slate problem is the single highest-leverage UX issue to fix before store submission. Every major competitor either avoids it (Google Calendar pre-populates) or suffers from it (Partiful requires real contacts). A well-executed sample event is a genuine differentiator in the event-planning category.

2. The "sample event" pattern is proven across categories — Notion, Things 3, Apple's own iMovie and GarageBand all ship with sample content. This is not speculative; it's an industry-standard best practice that Wakeve currently lacks.

3. The DRAFT→POLLING→CONFIRMED state machine complexity makes this especially valuable for Wakeve. Unlike simple to-do or calendar apps, Wakeve has a multi-phase workflow that users cannot intuit from a blank screen. A pre-populated sample event that walks through each state transition is not just nice-to-have — it's necessary for comprehension.

Vote

Position: for

Reasoning: The empty-state problem is the most impactful UX gap for a 1.0.0 store submission. Market evidence strongly supports interactive sample content as a retention and review driver, and competitors in the event-planning space have not solved this well — giving Wakeve a differentiation opportunity at minimal implementation cost.

[guyghost]

✅ Solution Architect — FOR (weight: 3)

Role: Functional and technical architecture
Duration: 51.5s

Solution Architect Analysis — Proposal #10

Option A: Pre-seeded SQLite Migration

• Approach: Ship a pre-populated .sq migration that inserts a fully-formed sample Event (with participants, time slots, votes) into SQLDelight on first launch. A hasSeenSample flag in SharedPreferences/UserDefaults gates the one-time insert. The empty-state UI detects zero events and shows the onboarding card.
• Pros: Leverages existing persistence layer; sample data flows through the same repository paths as real data — no special rendering logic. Offline-compatible by default. Easy to delete the sample event (standard delete flow).
• Cons: Couples sample data to database schema — any schema change requires updating the seed SQL. Risk of sample event "leaking" into server sync if not flagged. Requires an isSample column or metadata field to distinguish it from real events.
• Effort: Medium — ~3-4 days across shared/Android/iOS.
• Scalability: Good. The seed is a one-time operation; no runtime overhead after first launch.

Option B: In-Memory Sample State (No Persistence)

• Approach: When the event list is empty, inject a SampleEventProvider that returns a hardcoded Event object tree in-memory. The UI renders it identically to a real event, but no SQLDelight write occurs. Tapping "Try it" writes the full object graph to the database, converting it to a real event.
• Pros: Zero schema pollution — no isSample column needed. Clean separation between sample data and production data until the user explicitly opts in. Easy to update sample content without migrations.
• Cons: Requires the UI to handle a "virtual" event that doesn't exist in the repository yet — adds a conditional branch in the event list ViewModel. The DRAFT→POLLING state transitions must work on an in-memory object before it's persisted, which may require refactoring state machine guards that assume repository-backed data.
• Effort: Medium-High — ~5-6 days due to state machine adjustments.
• Scalability: Good, but the abstraction adds a layer of indirection that must be maintained.

Option C: Compose/SwiftUI Overlay with Guided Walkthrough Screens

• Approach: Instead of a real sample event, show a series of static interactive cards (Compose on Android, SwiftUI on iOS) that simulate the event flow with mock screenshots and animations. Each card highlights a feature (poll voting, date confirmation, etc.) with a "Next" button.
• Pros: No data layer changes at all — purely a presentation-layer feature. Zero risk of sample data leaking into sync. Extremely fast to build.
• Cons: Not interactive — the user watches, doesn't do. Fails the core requirement of "explore the full DRAFT→POLLING→CONFIRMED flow." Doesn't leverage Wakeve's strength (interactive event planning). Feels like a tutorial, not an experience.
• Effort: Low — ~2 days.
• Scalability: N/A for data, but these overlay screens become stale as the app evolves.

---

Recommended Option

Option A (Pre-seeded SQLite Migration) — It integrates cleanly with the existing repository pattern and state machines, requires no special UI branching, and gives the user a real, interactive event to play with. The isSample flag is a small schema cost that pays for itself by preventing sync leaks and enabling clean deletion. Option B's in-memory approach fights against the existing state machine architecture (which assumes repository-backed events), and Option C fails the "interactive" requirement.

Integration Points

• SQLDelight schema: Add isSample BOOLEAN NOT NULL DEFAULT 0 to Event.sq. The seed migration inserts the sample event with isSample = 1.
• EventRepository / DatabaseEventRepository: Add fun getSampleEvent(): Event? and fun deleteSampleEvent(eventId: String). Existing queries naturally filter or include sample data based on context.
• SyncService: Must skip events where isSample = true during backend sync. Add a guard in the sync delta computation.
• EventManagementStateMachine: No changes needed — the sample event is a real event that transitions through DRAFT→POLLING→CONFIRMED normally. This is the key advantage.
• AppState / FirstLaunchCheck: Read hasSeenSample from platform settings (SharedPreferences/UserDefaults). On first launch, trigger the seed migration and set the flag.
• EventListScreen (Android Compose): When events.isEmpty() && !hasSeenSample, show the empty-state card with "Try a sample event" CTA. After sample is loaded, it appears as a normal event card.
• EventListView (iOS SwiftUI): Same conditional rendering logic.
• Contextual Tooltips: Use a TooltipState that activates only when viewing the sample event on key screens (poll voting, date confirmation). Flag isSample in the event metadata triggers tooltip visibility.

Technical Risks

• Risk 1: Sample event syncing to backend — If the user is authenticated and online before deleting the sample, it could be pushed to the server. Mitigation: Hard filter isSample = false in SyncService.getDirtyEvents(). Add a unit test asserting sample events are never synced.
• Risk 2: Schema migration ordering on existing users — Users who already have data may receive the migration. Mitigation: The migration is additive (new column + insert). It's idempotent — check hasSeenSample before inserting. Existing users with events won't see the empty state anyway.
• Risk 3: Sample data becoming stale with schema evolution — If Event model changes, the seed SQL must be updated. Mitigation: Generate the seed data from Kotlin domain objects (not raw SQL) via a SampleEventFactory in commonMain, and write to the repository through the standard insert path. This way, schema changes are handled automatically by SQLDelight's type-safe queries.

---

Vote

Position: for
Reasoning: Option A is architecturally clean — it uses the existing repository and state machine infrastructure without special-case rendering. The only material risk (sync leak) is trivially mitigated with a filter guard. The store-submission timeline favors a solution that reuses proven paths rather than inventing new abstractions.

[guyghost]

✅ Critic / Risk Agent — FOR (weight: 3)

Role: Risk assessment and challenge
Duration: 40.0s

Risk Score: 3 / 10

This is a low-to-moderate risk proposal. The core idea (pre-populated sample data + empty state UX) is a well-established pattern with high upside and limited blast radius. The main risks revolve around branch timing and data lifecycle, not architectural danger.

---

Assumption Challenges

• Assumption: "Users will engage with a sample event rather than skip it." — Challenge: If the sample event doesn't feel personally relevant or the CTA isn't compelling, users may dismiss it just as fast as an empty list. The sample event content and the wording of the CTA are critical; a generic "Birthday Party" may not resonate universally.
• Assumption: "A sample event can accurately represent the full DRAFT→POLLING→CONFIRMED flow." — Challenge: The flow involves multiple state machine transitions guarded by business rules (see AGENTS.md guards). A sample event pre-seeded at a specific stage may create an inconsistent state if the state machine isn't fully driven through its lifecycle. The sample must either be a static "read-only demo" or go through the real state machine transitions.
• Assumption: "This is low-effort enough for the store submission branch." — Challenge: Contextual tooltips on multiple screens (poll voting, date confirmation) scope-creeps quickly. On a release branch, any UI change carries regression risk right before submission.
• Assumption: "The sample event data won't interfere with real user data later." — Challenge: If the sample event is inserted into the real SQLite database (SQLDelight), it becomes entangled with actual data. Users may not understand they need to delete it, or it may confuse sync when the backend comes online in Phase 3.

---

Risk Assessment

Risk	Severity	Likelihood	Impact	Mitigation
Sample data pollutes real database	Med	High	User confusion; sync conflicts later	Mark sample events with a isSample flag; auto-delete on first real event creation or offer explicit "Clear demo" action
Scope creep on tooltips delays store submission	Med	Med	Miss store submission window	Defer tooltips to a follow-up; ship only the sample event + empty state CTA in v1
Sample event state machine inconsistency	Low	Med	Crash or broken navigation if guards fail	Drive sample through real state machine transitions; don't seed a static CONFIRMED event that bypasses guards
Tooltips feel patronizing or clutter UI	Low	Med	Negative first impression	User-test tooltip copy; ensure dismiss-and-never-show-again option
Sample event not culturally universal	Low	Low	Reduced engagement in some markets	Make sample event type configurable or use a universally relatable scenario
Regression on existing event list screens	Med	Low	Broken event list for returning users	Thorough test of event list with 0, 1 (sample), and N events; guard empty-state view behind events.isEmpty()

---

Security Concerns

• No significant security risks. This is purely client-side UI and local data. No new API endpoints, no auth changes, no data leaves the device. The sample data is static/mock.
• Minor note: If sample data includes mock participant names/emails, ensure they're clearly fictional (e.g., "Alice (demo)") to avoid confusion with real contacts.

---

Compliance & Debt

• RGPD: No personal data is collected. Mock participants should not use real-looking PII. Add a comment in code marking sample data as synthetic.
• Technical Debt: The isSample flag on events will need to be maintained across all queries, sync logic, and future backend integration. Keep the flag in the SQLDelight schema from day one so it doesn't become a migration later. The tooltip system, if built as a generic framework, could add UI-layer debt — prefer a lightweight, screen-specific approach over a full "tooltip engine."

---

Recommended Guardrails

1. isSample boolean column on Event table. Add it now in the SQLDelight schema. Every query that fetches events for normal display should WHERE isSample = 0 by default, with an explicit opt-in to include samples. This prevents sample data from leaking into stats, sync, or notifications later.
2. Auto-cleanup contract. Define clearly: when does the sample event get removed? Suggested triggers: (a) user creates their first real event, (b) user taps "Clear demo," (c) user explicitly deletes it. Never sync sample events to the backend.
3. Scope fence for store submission. Split this into two iterations:
   • v1 (store branch): Empty state illustration + "Try sample event" button + one pre-seeded event driven through real state machine. No tooltips.
   • v2 (post-launch): Contextual tooltips, multiple sample scenarios, tooltip persistence preferences.
4. Test the empty-state boundary. Add tests verifying: (a) empty state shows when 0 real events exist, (b) empty state hides when ≥1 real event exists (even if sample exists), (c) sample event can be deleted without affecting real events, (d) creating a real event doesn't crash if sample event is present.
5. No new dependencies. Resist adding a tooltip/coach-mark library. Use native Compose/SwiftUI overlays — this is a 2-screen feature, not a product tour platform.

---

Vote

Position: for

Reasoning: This addresses a real UX gap with a proven pattern (sample data for first-launch). The risks are manageable — primarily around data lifecycle and scope creep on a release branch — and the mitigations are straightforward (schema flag, scope split). The upside for store reviewers and first-time users significantly outweighs the low architectural risk. Just keep the store-submission scope tight: sample event + empty state, defer tooltips.

[guyghost]

⏸️ Prioritization Agent — ABSTAIN (weight: 2)

Role: Impact scoring and roadmap positioning
Duration: 49.6s

Scoring Matrix

Dimension	Score (1-10)	Justification
Business Impact	9	Directly targets #1 churn point for event-planning apps. Store reviewers and first-time users hit the empty state immediately — conversion depends on this.
User Impact	9	Universal: every single new user encounters the blank slate. A rich sample event demonstrates the full DRAFT→POLLING→CONFIRMED flow without requiring social buy-in.
Implementation Cost	3	Purely additive UI layer work: sample data seeding, empty-state composable/SwiftView, contextual tooltips. No backend changes, no schema migrations, no API additions.
Risk Level	2	Non-breaking, additive-only. Sample data is isolated from real events. Worst case: tooltips feel slightly intrusive — easily toggled off.
Effort Required	4	Well-scoped: (1) design empty-state illustration, (2) seed 1 realistic sample event with participants/slots/votes, (3) add 3-4 contextual tooltips, (4) wire "Try sample" button. Estimate: 2-3 focused days.
Strategic Alignment	9	On release/1.0.0-store-submission — this is the launch gate. First impressions are make-or-break for store reviews and organic growth.

Priority Score

Weighted Score: 4.86 / ~6.57 max (≈ 7.4 / 10 normalized)
Formula: (Impact×3 + Strategic×2 - Cost×1 - Risk×2 - Effort×1) / 7
= (9×3 + 9×2 - 3×1 - 2×2 - 4×1) / 7 = (27 + 18 - 3 - 4 - 4) / 7 = 34/7 = 4.86

Roadmap Recommendation

Placement: Now
Justification: The app is on a store-submission branch. This is a launch blocker in all but name — shipping without it means every reviewer and organic install hits a dead-end screen. The effort-to-impact ratio is exceptionally favorable (low effort, universal reach). Any delay past the branch freeze window permanently degrades first-launch cohorts.

Opportunity Cost

• ~2-3 engineer-days diverted from other launch polish tasks (e.g., final accessibility audit, screenshot assets).
• Slight increase in binary size from empty-state illustrations (~negligible).
• Risk of over-investing in sample data that becomes stale if event schema changes in v1.1 — mitigated by keeping the sample data generator close to domain models.

Dependencies

• DRAFT→POLLING→CONFIRMED flow must be stable — the sample event walks through this entire pipeline, so any state-machine bugs will surface immediately here.
• Design assets: Empty-state illustration and tooltip copy need design review (Material You / Liquid Glass compliance).
• First-launch detection: Requires a persistent flag (SharedPreferences / UserDefaults) to show sample only on first open — verify this doesn't conflict with existing onboarding flow (Phase 2.6 already has a 4-screen onboarding).

---

Vote

Position: for
Reasoning: Normalized score of ~7.4/10 reflects a rare combination of universal user reach (every new user), low implementation risk (additive UI only), and launch-critical timing (1.0.0 store submission branch). The blank-slate problem is the single highest-leverage UX fix available pre-launch — not doing it would be a measurable missed conversion opportunity.