Primary User
Peacock executives screening unreleased MicroMaker cuts on iPhone.
MICROMAKER
Updated 03/20 — Post-Meeting Revision
Screening App V2
A simple, solid iPhone app for Executives to screen vertical episodes the way they are meant to be watched.
01
Executive Summary
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.
Key priority: Seamless video playback is the single most important thing. Anything that stands in the way of fast, reliable video playback should be deferred until the core viewing experience is rock-solid.
| Date | Milestone | Outcome |
|---|---|---|
| 03/20 | Scope and architecture sign-off | v1 locked, deferred items removed from active build |
| 03/24 | UX flow sign-off | Core screens approved |
| 03/27 | First TestFlight build | End-to-end flow working |
| 04/02 | Internal screening ready | Team can use the app with real cuts |
| 04/17 | Exec-ready delivery | Polished build ready for Peacock executives |
02
Primary User and Use Cases
Secondary User
Internal Haymaker and MicroMaker stakeholders reviewing the same cuts before exec delivery.
- 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.
03
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.
04
MVP Scope
| Area | Included in v1 | Notes |
|---|---|---|
| Access | Yes | Unique invite code, validated server-side |
| Catalog | Yes | Small private catalog of series and episodes |
| Playback | Yes | Full-screen portrait playback with immediate auto-advance |
| Resume | Yes | Saved locally on the same device |
| Captions | Yes | Sidecar VTT support |
| Telemetry | Yes | Play, pause, and drop-off events with timestamps — stored server-side |
| Admin Interface | Yes | Simple admin for editing series/episode metadata and uploading episodes |
| API Server | Yes | Simple server hosting the API for video playback, metadata, and telemetry — backed by a relational database |
Out of scope for v1: accounts, search, recommendations, My List, deep links, feedback tools, and downloads.
05
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
06
Screen-by-Screen Experience
Invite Code Screen
Simple entry point with one field, one button, and a clear error state if the code does not work.
Browse View
Swipe up/down to browse between different series. Each series shows a poster, title, and description. (Deferred until multiple series are available.)
Series View
Swipe up/down to move between episodes within a series. Shows series title, description, and series poster. This is the default landing view for v1 (single series).
Playback Screen
Video fills the screen. Tap to pause, tap again to resume. Scrub bar shows position in the episode and allows seeking left/right.
07
Playback Behavior
| Behavior | v1 Requirement |
|---|---|
| Orientation | Portrait only |
| Episode transitions | Immediate auto-advance, no countdown or interstitial |
| Manual movement | Swipe up/down to switch episodes; scrub bar for seeking within an episode |
| Pause/Resume | Tap to pause, tap again to resume |
| Captions | Supported and available whenever delivered |
| Resume state | Saved locally on-device only |
| Quality bar | Must support stable viewing across 12+ episodes in one sitting |
The app borrows PineDrama's best behavior patterns: full-screen immersion, minimal chrome, and easy progression through a series.
08
Key Decisions (03/20 Meeting)
The following decisions were made in the 03/20 scope review meeting and are reflected throughout this updated spec:
| Topic | Decision |
|---|---|
| Platform | Cross-platform (iOS + Android). Framework TBD — researching Flutter, React Native, and alternatives. |
| Authentication | Unique invite code per user. User management = creating/revoking codes. |
| Video codec | H.265 (HEVC) preferred. Need to validate CDN compatibility — H.264 is the fallback. |
| Navigation | Browse View (swipe between series) + Series View (swipe between episodes). v1 launches with Series View only. |
| Playback controls | Tap to pause/resume. Scrub bar for position and seeking. |
| Telemetry | Play, pause, and drop-off events with episode + timestamp — stored server-side. |
| Backend | Simple API server + relational database for metadata and telemetry. |
| Thumbnails | Series poster only. No episode-level thumbnails. |
| Series metadata | Must include series title and series description (added to spec). |
| Admin | Simple admin interface in v1 for metadata editing and episode uploads. |
| UI components | Research component libraries for chosen framework, ideally with Figma counterparts for mockups. |
| MVP target | ~04/02 — bare-bones field screening + lightweight CMS for populating content. |
| Top priority | Seamless video playback above all else. Defer anything that blocks fast, reliable playback. |
09
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
10
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.
| Peacock Delivery Spec | What We Convert To | |
|---|---|---|
| File type | MOV | MP4 |
| Video codec | ProRes 422 HQ | H.265 (HEVC) |
| Resolution | 1080 x 1920 (9:16) | 1080 x 1920 (9:16) |
| Video bitrate | 50+ Mbps | 4–6 Mbps |
| Audio | LPCM, 24-bit, 48kHz | AAC, 128kbps, 48kHz |
| Captions | Sidecar .SCC file | Sidecar .VTT file |
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.
11
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.
| Event | Data Captured | Purpose |
|---|---|---|
| Session created | Invite code, timestamp | Shows that a valid invite code was used |
| Play | Episode ID, timestamp, playback position | Tracks when a user starts or resumes an episode |
| Pause | Episode ID, timestamp, playback position | Tracks when a user pauses |
| Drop-off | Episode ID, timestamp, playback position | Tracks where a user exits or abandons an episode |
| Episode completed | Episode ID, timestamp | Shows that a viewing run reached the end |
12
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.
13
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.
14
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.
Open research: Need to evaluate cross-platform frameworks (Flutter, React Native, etc.) based on video playback performance, available UI component libraries, and whether those libraries have Figma equivalents for high-fidelity mockups.
15
Timeline and Phased Delivery
| Date | Phase | Checkpoint |
|---|---|---|
| 03/17 to 04/02 | Phase 1 | Core app: invite code, catalog, playback, autoplay, captions, telemetry |
| 04/03 to 04/17 | Phase 2 | Polish, bug fixing, device QA, and exec readiness |
| After 04/17 | Phase 3 | Feedback tools and download exploration |
| Later phase | Phase 4 | CMS admin panel and broader content operations |
16
Milestones and Deliverables
| Milestone | Date | Deliverable |
|---|---|---|
| Scope lock | 03/18 | Final v1 feature list |
| UX lock | 03/20 | Approved wireframes or mockups |
| First TestFlight build | 03/27 | Working end-to-end beta build |
| Internal ready | 04/02 | Usable build with real episodes |
| Exec-ready release | 04/17 | Final polished TestFlight build |
Note: JB will be in Italy with family on 04/02 — flagging concern about availability to support team testing the app in the field during that week.
17
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.
18
Testing Plan
| Test Area | Owner |
|---|---|
| Backend testing (invite validation, signed URLs, telemetry endpoints) | Jonathan + Consulting Engineer |
| Binge-viewing QA (12–20 episode sessions on multiple iPhone models) | Jonathan / Team |
| Network testing (Wi-Fi, LTE, poor connectivity) | Jonathan + Consulting Engineer |
| Security testing (expired URLs rejected, revoked codes blocked) | Jonathan + Consulting Engineer |
| Caption rendering and toggle checks | Jonathan / Team |
| TestFlight install testing with non-team users before exec rollout | Jonathan / Team |
19
Open Questions
- Which cross-platform framework (Flutter, React Native, other) best supports video playback performance and has strong UI component libraries with Figma equivalents?
- Does H.265 (HEVC) work reliably across target CDN and device combinations, or should we fall back to H.264?
- Which iPhone and Android models/OS versions need to be supported for Peacock executives?
- Should each invite code allow one device only, or one backup device too?
- 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.
20
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:
- An exec receives an email invitation from us.
- They tap the link, which opens a free Apple app called "TestFlight" (one-time install, takes 30 seconds).
- Inside TestFlight, they tap "Install" and the Screening App appears on their home screen like any other app.
- 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.
21
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