Skip to content

Product Specification: VlogRoulette

The original product specification, translated from the Spanish it was delivered in. A historical record, kept as written — it is not updated as the product changes, which is what makes it useful.

Where the built product departs from it, and why, is in decisions.md; how it was built is in architecture.md. Two departures worth knowing before reading: gallery import was added despite the spec ruling it out, and silence trimming was built and then switched off.

1. Product vision

A social app that reduces the friction of making vlogs to zero. It combines the positive social pressure and urgency of apps like BeReal with an asynchronous video format. The core premise is to hand the burden of editing and assembly to the app itself: the user only records raw clips; the system delivers a finished mini-documentary to the group.

2. Main user flow (the weekly loop)

  1. Creating the circle — initial onboarding. A user creates a closed group and invites friends through a link or a unique code. The group sets the turn cadence (every 3, 5 or 7 days).
  2. The draw and the notification — system trigger. The server runs an RNG and selects a member. Everyone receives a push notification announcing the "vlogger of the week".
  3. Asynchronous capture — the user's only job. During their window, the chosen user opens the app at different moments of the day and records short clips (15-20 seconds per take at most). The interface is minimal: a record button, nothing else — no filters, no transitions, no timeline.
  4. Automatic rendering and upload — client-side processing. When the window closes, the app automatically compiles the clips saved locally, trims the silences, adds a light background audio track and exports the final file, which is uploaded to the server.
  5. The premiere and the reset — consumption and retention. The group is notified that the vlog is ready. After 24 hours of viewing, the cycle restarts and the API fires a new draw.

3. Functional specification (frontend / mobile app)

  • The "dumb" camera (clever underneath). The camera interface must block uploads from the camera roll to force authenticity. It must include a visual counter of accumulated time (e.g. "You have recorded 1:20 min of a 2:00 min maximum").
  • Auto-edit engine (core feature). The application must integrate lightweight algorithms (edge AI) to process media on the device:
  • VAD (Voice Activity Detection) to identify and automatically trim the dead air or silences at the start and end of each take.
  • Smart transitions: programmatic clean cuts or soft micro-transitions between clips.
  • Local storage management. Raw clips must be stored in a secure temporary directory inside the app sandbox. Once the final video is rendered and uploaded, the raw clips must be purged.

4. Technical architecture and backend

A "heavy" client (which takes on video processing) and a "light" server (which acts only as an orchestrator).

Infrastructure and orchestration

  • REST/GraphQL API. A lightweight backend service (Go, Rust or Python/FastAPI) whose only job is to manage the relational database (PostgreSQL) for users, groups, permissions and the state of the draw.
  • Portable deployment. The whole backend infrastructure packaged in containers and managed through Docker stacks, so it can migrate from a cheap VPS to sturdier clusters as the user base grows.

Storage and network (zero egress)

  • Avoid standard AWS S3. For hosting the final videos, target providers with free or ultra-low egress, such as Cloudflare R2.
  • Protection and delivery. Video delivery must be served through a CDN to absorb traffic spikes — when all the friends pile in to watch at once — without hitting the origin server.

Video generation and assembly (the pipeline)

The rendering flow on the mobile client must be deterministic. FFmpeg compiled for iOS/Android (or AVFoundation / MediaCodec) is recommended, to guarantee that re-encoding, loudness normalisation and audio track overlay do not desynchronise the final result before upload.

5. Edge cases to handle

  • Render failure / dead battery. If the phone shuts down during the final export, the app must keep the state and retry the automatic render (background task) as soon as it has power again.
  • The user records nothing. If the deadline arrives with 0 clips, the system fires a "strike" or penalty within the group's gamification and the turn passes immediately to another player.
  • Privacy permissions. Rendering locally means intensive CPU use for a short period (1-2 minutes) at the end of the week. The user must be informed through the interface so they do not abruptly close the app during that process.