Primary User
Peacock executives screening unreleased MicroMaker cuts on iPhone.
MICROMAKER
Presentation Draft
MicroMaker Screening App
A simple iPhone app for Peacock executives to screen MicroMaker vertical episodes the way they are meant to be watched: full-screen, portrait, and in sequence.
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.
Build Team
Jonathan Bulette — Product lead. Owns spec, scope, and delivery. AI-assisted development using Claude Code + Xcode with MCP integration.
Justin Poliachik — Consulting Engineer. Brought in to advise on iOS/Swift/SwiftUI architecture, ensure best practices for video playback and app structure, smooth the TestFlight onboarding for executives, and help build v1 with intentional foundations for the eventual consumer product. Engaged on a flat-fee retainer for v1, with an option for deeper engagement during later phases of app development.
Estimated Build Costs
| Item | Estimate |
|---|---|
| Consulting Engineer (Justin) — v1 retainer | $5,000 |
| AI development tokens (Claude API / Claude Code) | ~$200–$500 |
| Apple Developer Program (annual) | $99 |
| Cloudflare account setup (Workers Paid plan, R2, KV) | $5/mo + usage (~$10–$25/mo) |
| Total estimated v1 cost | ~$5,350–$5,700 |
The defining product behavior is uninterrupted sequential viewing. If the team has to choose between more features and more reliable playback, reliable playback wins.
| Date | Milestone | Outcome |
|---|---|---|
| 03/18 | Scope and architecture sign-off | v1 locked, deferred items removed from active build |
| 03/20 | 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 | Playback starts and completions only |
Out of scope for v1: accounts, search, recommendations, My List, deep links, feedback tools, downloads, Android, and a CMS admin panel.
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.
Catalog Screen
A small, visual library of available series. No search or feed logic.
Series Screen
Title summary, episode count, start or resume button, and a neat episode list.
Playback Screen
Video fills the screen. Controls appear only on tap and disappear again quickly.
07
Playback Behavior
| Behavior | v1 Requirement |
|---|---|
| Orientation | Portrait only |
| Episode transitions | Immediate auto-advance, no countdown or interstitial |
| Manual movement | Users can move to the next or previous episode inside the series |
| 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
Content and Navigation Model
Content is organized very simply: Series -> Episodes. The catalog remains small, so there is no need for search or recommendation logic in v1.
For launch, content is managed manually through a JSON catalog and private Cloudflare R2 uploads. This is acceptable for a small slate and keeps delivery lightweight.
Catalog -> Series Detail -> Full-Screen Player -> Auto-advance within the same series
09
v1 Telemetry
v1 only needs the minimum instrumentation required to prove that the app works and that reviewers are actually completing episode runs.
| Event | Purpose |
|---|---|
| Session created | Shows that a valid invite code was used |
| Playback started | Shows that a specific episode was opened |
| Episode completed | Shows that a viewing run likely reached the end of an episode |
10
Deferred Features
- Feedback tools: lightweight thumbs-up style reaction or flagging, to be explored later.
- Offline downloads: intentionally deferred because secure local storage adds complexity.
- CMS: later phase for content management, metadata, and publishing workflows.
- Full analytics: more detailed reporting can come after v1 proves the viewing behavior.
11
Technical Assumptions
- Native iPhone app built in Swift and SwiftUI.
- Distributed via TestFlight to a small internal group.
- Video stored in a private Cloudflare R2 bucket.
- Cloudflare Workers validate invite codes and generate signed video access.
- Workers KV stores invite codes, session data, and basic viewing logs.
12
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 |
13
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 |
14
Approval Process
- Product lead: owns scope and final priority calls.
- Creative lead: confirms that the app supports real screening behavior.
- Engineering owner: decides when scope must be reduced to protect delivery.
- Content owner: verifies uploads, thumbnails, episode order, and captions.
15
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.
16
Testing Plan
| Test Area | Owner |
|---|---|
| Backend testing (invite validation, signed URLs, telemetry endpoints) | Jonathan + Justin |
| Binge-viewing QA (12–20 episode sessions on multiple iPhone models) | Jonathan / Team |
| Network testing (Wi-Fi, LTE, poor connectivity) | Jonathan + Justin |
| Security testing (expired URLs rejected, revoked codes blocked) | Jonathan + Justin |
| Caption rendering and toggle checks | Jonathan / Team |
| TestFlight install testing with non-team users before exec rollout | Jonathan / Team |
17
Open Questions
- Which iPhone models and iOS versions need to be supported for Peacock executives?
- Should each invite code allow one device only, or one backup device too?
- Are episode-level thumbnails required for every title by April 2?
- Should captions be on by default?
18
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