CEO Plan: Member-Created Events¶
Generated by /plan-ceo-review on 2026-06-04 Branch: master | Mode: SELECTIVE EXPANSION Repo: rakletadmin/rakletv3 Source design doc: member-created-events-design.md Source office-hours session: 2026-06-04 (same day, immediately preceding)
Review Posture¶
SELECTIVE EXPANSION — hold the office-hours lean scope as baseline, surface expansion opportunities one at a time, let CEO cherry-pick under the mid-July hiking-club deadline pressure.
Vision¶
10x Check¶
The 10x version of member-created events is "two-sentence event submission" with an AI parsing layer. Member types "Saturday Oct 12, 9am hike at Crater Lake rim trail. $25, max 20 people, intermediate difficulty" — AI fills the structured form — member confirms and submits. Total submission time drops from 6-10 minutes to 60 seconds, making Raklet categorically faster than Meetup for the submission flow.
This was proposed as Cherry-pick #1. Decision: deferred to TODOS. Rationale: validate base demand first; add the moat once submission patterns are visible.
Platonic Ideal (referenced but not selected)¶
The platonic ideal of Raklet's events product 12 months from now: distributed orgs run their entire event lifecycle inside Raklet — submission, approval, marketing, attendance, payment, post-event communication, repeat-attendance loops, member retention. Member-created events with mandatory approval is the on-ramp to that vision, not the full vision.
Scope Decisions¶
| # | Proposal | Effort (CC) | Decision | Reasoning |
|---|---|---|---|---|
| 1 | AI-assisted submission ("describe your event") | ~3-5 days | DEFERRED | Validate base demand first, add moat in v1.5 |
| 2 | Auto-approve trusted creators (move v2→v1) | ~1-2 days | DEFERRED | Mandatory-approval first; let admin behavior inform v1.5 |
| 3 | "Create another like this" duplication | ~30 min | DEFERRED | Members can manually re-fill; not blocking |
| 4 | Recurring events in v1 | ~3-5 days | DEFERRED | Approval semantics for series-vs-instance unresolved; deadline risk |
| 5 | Submission analytics dashboard | ~30 min | DEFERRED | Rely on App Insights / GA4 for first 30 days |
| 6a | Tagged rejection reasons | ~30 min | DEFERRED | Polish; admin can free-text reject in v1 |
| 6b | "Request changes" admin action (between approve and reject) | ~1 day | DEFERRED | Third admin action for revision requests; meaningful UX |
| 6c | Member event marketing kit (share card + email template on approval) | ~1-2 days | DEFERRED | Growth-tier polish; validate adoption first |
Strategic Decisions Locked In¶
| Decision | Value |
|---|---|
| 90-day post-launch success threshold | 4-metric stack (revised after codex challenge): (1) hiking-club converted + active by day 60, (2) >=3 other paying orgs have a member submit, (3) repeat-leader ratio >50% in adopting orgs, (4) >=1 customer reports reduced Meetup usage |
| Kill signal | Fewer than 2 paying orgs use feature by day 60 — pause v1.5, do customer research |
| Validation customer | Hiking-club prospect, mid-July board decision |
Accepted Scope Additions (added to v1 plan)¶
NONE. All 6 expansion proposals deferred. Lean v1 scope from office-hours is unchanged.
Deferred to TODOS.md¶
All 8 line items above (1-6c) carry forward as P1-P2 TODOS for v1.5 / fast-followers. Each should be revisited based on 30-day usage data from the v1 launch.
Specifically the 3 deferred items most likely to ship as fast-followers within 60 days of v1 launch: - Item #2 — auto-approve trusted creators. Likely escalates to P0 if hiking-club admin reports approval-queue fatigue in week 2-3 of trial. - Item #3 — "Create another like this". Likely escalates if repeat-submission ratio in the v1 data is >40%. - Item #1 — AI-assisted submission. The product-marketing headline for v1.5; tied to the company-wide AI-adoption push.
Skipped Entirely¶
None — every proposal was deemed worth tracking, just not worth shipping in v1.
Review Findings to Resolve Before /plan-eng-review¶
These were surfaced during the review pass below and need CEO-level decisions, not engineering decisions.
- Approval-queue SLA / escalation policy (Section 2 finding) — what happens to a pending submission if no admin ever reviews it?
- Edit-after-approval revision policy (Section 3 + 4 finding) — can a member edit a published event without re-review? This is the brand/security question.
- Mobile-first vs desktop-first design choice (Section 11 finding) — hike leaders submit from phones; admins approve from laptops.
(These decisions are made in the chat-mode of this review and folded into the design doc.)