Bananas 🍌

Where We Stand

Bananas — the MicroMaker screening app — shipped to Peacock on April 21, 2026. Phase 1 is complete and the app is in active daily use by the network. Phase 2 — viewer telemetry & user behavior intelligence, plus UI refinements — is now in scoping.

Status by Phase

What Shipped

On April 21, 2026, Aaron Rothman greenlit the first 14 episodes of Campus Confidential: Miami and invite emails went out at 7:09 PM to 29 Peacock executives, music rights organizations, and program ops contacts, plus 11 additional internal stakeholders. Salon Confessionals with Madison LeCroy is the next series in the pipeline (target air week of 7/6).

The shipped product is a superset of what the v1 spec (Section 3) describes. Notable deltas added during build:

• Cross-platform distribution — Android via Google Play alongside iOS TestFlight (the v1 spec was iOS-only).
• Admin interface — Aaron has direct control over episode permissions, chapter organization, and viewer status.
• Role-based content permissions — internal vs. network content gating. Team sees works-in-progress; network users see only Aaron-approved cuts.
• Chapter tier — added beneath Series to organize multi-storyline content (Chapter 1: Influencer Enemies, Chapter 2: Georgia).
• Episode title overlay — episode titles surfaced in playback chrome alongside series title and number.

What's Next

Section 2 lays out Phase 2 in detail. Two workstreams:

1. Viewer Telemetry & User Behavior Intelligence — richer playback events routed to an off-the-shelf analytics platform (Amplitude is the working assumption), with role-based filtering and per-episode drop-off views surfaced to producers. The headline deliverable.
2. UI refinements — a short list of playback affordances surfaced during Phase 1 screening.

The strategic purpose is to prove the team can ship a learning tool, not just a screening tool — building the case for Peacock to expand the partnership and unlock broader investment.

Phase 2 — Viewer Telemetry & User Behavior Intelligence + UI Refinements

Audience expands from the original ~10–30 exec cohort to (a) a broader Bravo/Peacock stakeholder pool and (b) a small consumer beta-tester cohort whose engagement data is the signal that actually matters.

2.1 Two Workstreams

2.2 Telemetry — Event Taxonomy

Phase 1 already accepts forward-compatible events. Phase 2 expands the set:

Timecode-to-script mapping (stretch). Every progress / pause / abandon event carries position_ms. If episode metadata includes a chapter or scene boundary table — and eventually word-timed transcripts from the captioning workflow — the dashboard can resolve any timestamp back to "which scene, which line." Capture the data unconditionally; treat the visualization as a stretch goal pending transcript availability.

2.3 Analytics Platform

Working recommendation: Amplitude. Off-the-shelf, supports custom event schemas, native funnel/flow/retention analysis, and cohort filtering by user property. Producers get a real UI without the team building a dashboard from scratch. Free tier likely sufficient at screening-cohort scale.

Routing — decision pending. Events can go to Amplitude (a) directly from the iOS / Android client via Amplitude's SDK, or (b) forwarded through the existing Cloudflare Worker. Working assumption: Worker-forwarded, because the Worker is the natural place to enrich events with the role tied to the invite code and dual-write to KV for our own retention.

Out of scope for Phase 2: building a custom dashboard. If Amplitude's stock views aren't sufficient, defer a custom view to Phase 3.

2.4 User Roles (extending the shipped system)

The shipped app already implements role-based content permissions — internal team members see works-in-progress; network users see only Aaron-approved cuts. That gate is in place. Phase 2 extends the role system in two ways: (1) adds a consumer_beta role for a small consumer test cohort, and (2) wires role into every telemetry event as a user property so analytics can be filtered by audience.

2.5 UI Refinements (working list — final list TBD)

2.6 Out of Scope for Phase 2

• Custom-built dashboard (use Amplitude's UI for v2)
• Full transcript-to-timecode visualization (capture the data; defer the view)
• DRM / screen-recording prevention (still deferred from v1)
• CMS admin panel (still deferred — Phase 3+ candidate)
• Offline downloads (still deferred)
• Subtitle content delivery (content team workstream, not the app)

2.7 Timeline

Working schedule for Phase 2. Aggressive but achievable; assumes the telemetry routing decision (Worker-forwarded vs. direct) lands by end of W1.

2.8 Implementation Plan

Sequenced for fastest demoable telemetry. Each step gates on the prior.

1. Lock final UI tweak list. Jon consolidates scattered notes; decide UI1 vs. UI2 gesture conflict.
2. Stand up Amplitude trial. Define event and user-property schema; confirm free-tier limits cover expected volume.
3. Decide telemetry routing. Worker-forwarded vs. direct-from-client. Default Worker-forwarded.
4. Extend invite-code issuance with role. Worker change; existing codes default to stakeholder (Peacock execs) or internal (team).
5. Extend Worker /telemetry endpoint. Accept new event types, attach role from session token, dual-write to KV and Amplitude.
6. Instrument the iOS and Android clients. Wire pause/resume/seek/progress/advance/abandon/background/foreground events without regressing playback continuity.
7. Generate title-safe overlay template. Static asset; deliver to editorial.
8. Build the UI refinements. Ship behind the same TestFlight + Google Play cadence.
9. Build Amplitude views for producers. Per-episode drop-off curve, continuation funnel, role-filtered cohort views.
10. Issue consumer-beta invite codes. Small initial pool. Confirm events tag correctly.
11. End-to-end validation against acceptance criteria.
12. Demo session with Peacock. The actual deliverable.

2.9 Acceptance Criteria

2.10 Open Questions

1. Final UI tweak list (Jon to consolidate).
2. Amplitude pricing tier given expected event volume.
3. Direct-from-client vs. Worker-forwarded telemetry routing.
4. Size and source of consumer-beta cohort (who, how recruited).
5. Will scene boundaries / transcripts be available in time to demo timecode-to-script mapping?
6. App-kill detection: how much fidelity can we realistically get?
7. Engagement / commercial structure for Phase 2 (handled separately, not part of this spec).

Executive Summary

Editor's note (added 04/30/2026): at the time of writing, the app was unnamed. It later shipped as Bananas 🍌. References below to "the MicroMaker Screening App" and the line about a future "consumer-facing app (Bananas)" both refer to what is now Bananas — the screening tool and the planned consumer product converged under one brand.

The MicroMaker Screening App is a native iPhone app that allows Peacock executives to review MicroMaker vertical cuts in the right viewing context: on a phone, in portrait, with full-screen playback and immediate progression from one episode to the next.

v1 is intentionally narrow. A user enters a personal invite code, opens a private catalog, chooses a series, and watches episodes in sequence. The product is meant for internal screening first, not public release or consumer growth — but v1 is being built with clear line of sight toward a consumer-facing app (Bananas), so architecture decisions now should not paint us into a corner.

My recommendation is to engage a "Consulting Engineer" to advise on cross-platform architecture, ensure best practices for video playback and app structure, and help build v1 with intentional foundations for the eventual consumer product. I have 2 candidates in mind.

We can use AI coding tools to execute on the code base, with oversight and testing at each phase. Note that cost considerations should include a retainer fee for the Consulting Engineer, AI tokens, and robust video hosting on a service like Cloudflare.

Primary User and Use Cases

• Watch multiple episodes in sequence to judge story arc, pacing, and cliffhanger strength.
• Review newly delivered episodes as they are uploaded week to week.
• Resume quickly on the same device without needing an account or new setup.

Design Principles

• Portrait-first. The app should feel native to vertical viewing, not like a TV app reduced to phone size.
• Binge-first. Watching 12 or more episodes in a row is central to the product.
• Minimal interface. Content should dominate the screen, with controls only when needed.
• Simple navigation. Users should move from code entry to playback in just a few taps.
• Secure by default. Unreleased cuts must stay protected behind server validation.

MVP Scope

Out of scope for v1: accounts, search, recommendations, My List, deep links, feedback tools, and downloads.

Core User Flows

First Launch

Open app -> enter invite code -> code is validated -> catalog appears

Start Watching

Catalog -> choose series -> choose episode or resume -> full-screen playback -> next episode starts automatically

Return Visit

Open app -> session still valid -> continue from same series and episode on the same device

Screen-by-Screen Experience

Playback Behavior

Key Decisions (03/20 Meeting)

The following decisions were made in the 03/20 scope review meeting and are reflected throughout this updated spec:

Content and Navigation Model

Content is organized simply: Series -> Episodes. Two navigation views are planned:

• Browse View: Swipe up/down to move between different series. Each series shows a poster, title, and description. (Deferred — activates when multiple series are available.)
• Series View: Swipe up/down to move between episodes within a series. This is the primary view for v1 since we're launching with a single series.

Series and episode metadata (titles, descriptions, posters) are stored in a relational database and managed through the admin interface. Video files are stored in Cloudflare R2.

Thumbnails exist at the series level only (a series poster) — there are no episode-level thumbnails.

Invite Code -> Series View (swipe between episodes) -> Full-Screen Player -> Auto-advance within series

Video Format

Peacock delivers editorial cuts as high-quality production masters. We convert these to a mobile-optimized format before uploading them to the app.

The conversion reduces file size by roughly 90% with no visible quality loss on a phone screen. H.265 (HEVC) is the preferred codec for better compression efficiency at equivalent quality. CDN compatibility with H.265 is still being evaluated — if delivery issues arise, H.264 remains the fallback. Captions are converted from SCC (a broadcast format) to VTT, so users can toggle captions on and off in the app.

For v1, this conversion is done manually using a simple script before uploading episodes. An automated pipeline is planned for a later phase.

v1 Telemetry

Telemetry events are stored server-side and associated with the user's invite code. The goal is to understand viewing behavior — especially where users drop off within episodes.

Admin Interface

A simple, password-protected admin interface where a producer or team member can manage content in the app without any technical knowledge. This covers two main functions:

Episode Upload

• Video file — the mobile-optimized MP4 (transcoded from the Peacock master)
• Episode number
• Title
• Caption file — the VTT sidecar (optional)

Metadata Management

• Series title and series description
• Series poster — the single thumbnail/poster image per series (no episode-level thumbnails)
• Edit or update metadata for existing series and episodes

The admin interface handles uploading files to storage and updating the relational database automatically. No command line, no code, no developer involvement. Changes appear in the app on the next refresh.

Deferred Features

• Browse View: swiping between multiple series — deferred until more than one series is available.
• Feedback tools: lightweight thumbs-up style reaction or flagging, to be explored later.
• Offline downloads: intentionally deferred because secure local storage adds complexity.
• Full CMS: the simple admin interface covers v1 needs; a more complete CMS with publishing workflows is a later phase.
• Analytics dashboard: telemetry data is being collected server-side from v1 — a reporting UI comes later.

Technical Assumptions

• Cross-platform app targeting both iOS and Android. Development framework TBD — evaluating Flutter, React Native, and other options for best fit with video playback and available UI component libraries.
• Distributed via TestFlight (iOS) and equivalent method (Android) to a small internal group.
• Video stored in a private Cloudflare R2 bucket, encoded in H.265 (HEVC) — pending CDN compatibility validation.
• Simple API server handling invite code validation, video delivery, and telemetry.
• Relational database storing series metadata, episode metadata, invite codes, and telemetry events.
• Each user gets a unique invite code — user management is handled through code creation/revocation.

Timeline and Phased Delivery

Milestones and Deliverables

Verification and Acceptance Criteria

• Valid invite codes unlock the app cleanly; invalid codes fail cleanly.
• Videos are not publicly exposed and require valid access.
• Users can watch 12 consecutive episodes without a critical playback failure.
• The app remembers where a user left off on the same device.
• Captions work on all episodes intended for exec review.
• Telemetry records starts and completions with invite-code association.

Testing Plan

Open Questions

1. Which cross-platform framework (Flutter, React Native, other) best supports video playback performance and has strong UI component libraries with Figma equivalents?
2. Does H.265 (HEVC) work reliably across target CDN and device combinations, or should we fall back to H.264?
3. Which iPhone and Android models/OS versions need to be supported for Peacock executives?
4. Should each invite code allow one device only, or one backup device too?
5. Should captions be on by default?

Resolved from Prior Draft

• Episode-level thumbnails? — No. Series poster only, no episode thumbnails.
• iOS only? — No. Targeting both iOS and Android via cross-platform framework.
• CMS admin panel deferred? — A simple admin interface is now included in v1 scope.

How Executives Get the App

TestFlight (iOS) is Apple's official system for sharing apps privately before they go live on the App Store. Think of it like a private screening link — but for an app instead of a video.

Here's how it works for iPhone users:

1. An exec receives an email invitation from us.
2. They tap the link, which opens a free Apple app called "TestFlight" (one-time install, takes 30 seconds).
3. Inside TestFlight, they tap "Install" and the Screening App appears on their home screen like any other app.
4. From that point on, they just open it and use it — it looks and feels like a normal app. TestFlight stays in the background.

When we push updates or fixes, TestFlight automatically notifies them and the app updates with one tap. No App Store review process, no public listing, no waiting. We control exactly who has access and can revoke it at any time.

Android distribution will follow a similar private-testing model (e.g., Firebase App Distribution or Google Play internal testing). The specifics depend on which cross-platform framework is selected.

For v1, private distribution is the right method because the app is for a small, known group (~10–30 people), not the general public.

Recommended Next Artifacts

• Annotated wireframes for the core screens
• API contract for invite validation and signed video delivery
• JSON catalog template for manual content operations
• QA checklist for binge-viewing and TestFlight release

Rollout Narrative

The build ran approximately five weeks from creative kickoff to network rollout. Key inflection points:

• Mar 24 — Creative walkthrough; Campus Confidential: Miami scoped as a microdrama series with three storylines at the University of Miami.
• Mar 25 — MicroMaker Slack workspace created; #app-development channel becomes the coordination hub.
• Mar 29 — First internal feedback (Caroline Bomback): app generally works, bugs around scrolling lag and audio/video sync.
• Mar 30 — First exec-side feedback (Aaron Rothman): app works well, requested a next-episode navigation arrow.
• Apr 6 — Lisa hits a "No episodes available" screen — early signal that permissions need attention before network rollout.
• Apr 10 — Peacock security review passed. Drew Baumann's SECURITY.pdf earned the confidence of Brandon and Thalia on Peacock tech.
• Apr 13 — Rollout planning day: Josh confirms exec list, Ronica's chapter/permission feedback shapes the feature roadmap, Drew ships episode title overlay + responsive episode drawer.
• Apr 14 — Peacock confirms 6/15 air target for Campus Confidential, 7/6 for Salon Confessionals.
• Apr 21 — Peacock invites sent at 7:09 PM PT. 29 Peacock recipients with personalized invite codes; iOS via TestFlight, Android via Google Play.
• Apr 22–24 — Chapter 1 distributed via FineCut as parallel channel; Chapter 2 (eps 115–130) uploaded; Aaron granted admin permissions.
• Apr 29 — App in active daily use by network; performance monitoring ongoing.

The dual-track delivery workflow that emerged: post team exports → internal QC by Ronica's team → executive approval by Aaron → app permission toggle → invite emails → FineCut parallel delivery (with notification to the full distribution list).