System Requirements Document for remotion-render

1. Introduction

remotion-render is a developer tool for people who write video as code. A Remotion Developer brings their own Remotion composition — React-based programmatic video — and renders it into a finished video file while choosing the output parameters that define the result: resolution, fps, duration, and aspect ratio.

The product intent is narrow and deliberate: the developer's code is the film camera, and the four output parameters are first-class creative decisions rather than an afterthought buried in an export dialog. The tool exists so that a developer can go from "here is my composition" to "here is my rendered video at exactly the parameters I chose" in one continuous console, with the chosen parameters always visible as an instrument readout.

The audience is motion-graphics engineers, generative artists, and front-end developers who already treat Remotion compositions as their primary creative artifact and who expect output parameters to be directly and precisely controllable.

2. System Overview

remotion-render is delivered as a first-party custom web console. It has no account system: every surface is anonymously reachable, and the developer's work in a session is held in the console itself rather than behind a login. There is no sign-in, no registration, no invitation, and no provisioning step, because the accepted requirements establish no durable cross-session identity, no entitlement, and no value transfer that must remain bound to a returning participant.

The console is organized as a persistent three-zone layout: a left rail carrying the seven surfaces, a centre stage holding the generative preview canvas with a ruled metadata strip beneath it, and a right rail holding the active parameter editor with the Render action pinned to the bottom. The layout collapses to an icon rail at 768px and to a bottom tab bar at 375px, with the Render action migrating to a sticky footer.

The single accepted human actor is the Remotion Developer. The system itself performs the render execution and produces the output video; the developer initiates, configures, and reviews that work.

Current scope: rendering the developer's Remotion code; choosing output resolution; choosing output fps; choosing output duration; choosing output aspect ratio; viewing the rendered output.

Explicitly out of scope for the current horizon: account creation, sign-in, user profiles, teams, permissions, billing, project libraries, asset management, and any capability not listed above. No such capability is implied by the console layout or by the presence of a preview canvas.

2a. Product Interpretation and Delivery Boundary

Everything the developer does in remotion-render happens in the first-party console. The developer supplies Remotion code, sets four output parameters, triggers a render, and reviews the resulting video. All of these interactions are owned by the application's own surfaces; none of them is delegated to a provider surface or an external destination.

Access is anonymous throughout. The console does not gate any surface behind identity, because the accepted requirements describe a single-session rendering workflow with no returning-participant continuity requirement, no private durable state that must be owned by a specific person, and no commitment or entitlement that must remain bound to a particular developer. The Landing surface is the anonymous entry point and explains the product; the remaining surfaces are the working console.

The render execution itself is system work: the developer triggers it and observes its result, but the developer does not interact with the render engine directly. The engine's progress and outcome are surfaced to the developer on the Render Output surface.

The generative preview canvas is a procedural visual derived from the developer's currently selected parameter values. It stands in for "your composition" and is not a render of the developer's actual code; the actual rendered video appears on the Render Output surface.

2b. Source Content Inventory

Not applicable. No reference directive in this project declares a content_source, so no source content inventory is included.

2c. Page Content and Component Coverage

Landing

• Information and state: The anonymous first impression of remotion-render. A full-bleed near-black canvas (#07070A) carrying a live generative particle/fluid field in teal-to-mint (#7CE7D0), densest in the right two-thirds, leaving the left third as quiet dark space. Into that left third, flush-left and bleeding slightly past the 12-column grid, sits one oversized headline in Space Grotesk at clamp(44px, 9vw, 132px): "Your code, rendered." stacked in three tight lines, with "rendered" set in coral (#FF6B4A). Beneath the headline, a single ruled metadata strip in IBM Plex Mono reads "1920 × 1080 · 60 FPS · 12.5s · 16:9" with digits ticking over live. Beneath the strip, one coral outlined button labelled "Open the console", pinned directly beneath the strip, not centred and not floating.
• Primary action: Open the console — enters the working console at the Code surface.
• Supporting actions: None. The Landing surface carries no parameter controls and no render action.
• Domain entities: The four output parameters (resolution, fps, duration, aspect ratio) appear here only as read-only display values in the metadata strip; they are not editable on this surface.
• Component responsibilities:
  • Generative hero canvas: renders the continuous slow particle/fluid field; its tempo and colour drift respond to the currently selected fps and aspect ratio values so the first screen is never the same twice.
  • Hero headline: oversized flush-left Space Grotesk display line, with the final word in coral.
  • Ruled metadata strip: four aligned label/value pairs (RESOLUTION / FPS / DURATION / RATIO) in IBM Plex Mono with tabular numerals, ticking live.
  • Console entry button: single coral outlined button that enters the console.
• States:
  • Loading: the generative canvas initializes; the headline and metadata strip render immediately and are never blocked by canvas initialization.
  • Empty: not applicable — the Landing surface has no collection or list.
  • Success: the developer reads the product intent and enters the console.
  • Error: if the generative canvas fails to initialize, the surface falls back to a composed still frame of the field; the headline, metadata strip, and console entry button remain fully readable and operable.
  • Recovery: the canvas retries initialization on the next visit; the developer is never blocked from entering the console.

Code

• Information and state: The surface where the Remotion Developer supplies the Remotion code to be rendered. A monospace code block with syntax colouring drawn from the palette (teal keywords, coral strings, muted comments) occupies the centre stage, with the ruled metadata strip beneath it showing the four current parameter values. The right rail holds the active parameter editor context.
• Primary action: Submit or point to the Remotion code for rendering.
• Supporting actions: Edit the supplied code; clear the supplied code; move to any parameter surface via the left rail.
• Domain entities: The Remotion composition source (the developer's code); the four output parameter values currently in effect.
• Component responsibilities:
  • Code entry block: accepts and displays the developer's Remotion code with palette-derived syntax colouring.
  • Submission control: commits the supplied code as the composition to be rendered.
  • Ruled metadata strip: four aligned label/value pairs in IBM Plex Mono with tabular numerals, always in view.
  • Left rail: navigation among the seven surfaces.
• States:
  • Loading: the code entry block initializes; the metadata strip renders immediately.
  • Empty: no code supplied yet — the code entry block shows an empty editable region with a prompt to supply Remotion code; the render action is unavailable until code is supplied.
  • Success: code is accepted as the composition to be rendered; the developer can proceed to set parameters or trigger a render.
  • Error: supplied code cannot be accepted as a Remotion composition — the surface states the failure plainly and keeps the developer's input intact so it can be corrected and resubmitted.
  • Recovery: the developer edits the code in place and resubmits; no input is discarded on failure.

Resolution

• Information and state: The surface for choosing the render output resolution. A ruled row with a left-hand label column and a right-hand value column presents the resolution control; the current value is set in IBM Plex Mono 20px with tabular numerals. The centre stage shows the generative preview canvas with the ruled metadata strip beneath it, so the developer sees the current resolution in context.
• Primary action: Choose the output resolution.
• Supporting actions: Return to the Code surface; move to any other parameter surface; trigger a render from the pinned Render action.
• Domain entities: Output resolution (width × height); the four output parameter values currently in effect.
• Component responsibilities:
  • Resolution control: ruled row with label column and value column; commits the chosen resolution.
  • Preview canvas: generative field whose frame reflects the current parameter set.
  • Ruled metadata strip: four aligned label/value pairs, with the RESOLUTION pair reflecting the current choice.
  • Render action: coral action pinned to the bottom of the right rail on desktop, sticky footer bar on mobile.
• States:
  • Loading: the control initializes with the current resolution value; the preview canvas initializes independently.
  • Empty: no resolution explicitly chosen — the control shows the current effective value rather than an empty field.
  • Success: the chosen resolution is committed; the metadata strip's RESOLUTION value updates with a 120ms value-flip in the mono digits and a single 600ms light sweep across the active panel.
  • Error: a chosen resolution cannot be applied — the surface states the failure plainly and retains the previously effective resolution so the developer is never left without a valid value.
  • Recovery: the developer chooses another resolution; the previous valid value remains in effect until a new one is accepted.

FPS

• Information and state: The surface for choosing the render output fps. A ruled row with a left-hand label column and a right-hand value column presents the fps control; the current value is set in IBM Plex Mono 20px with tabular numerals. The centre stage shows the generative preview canvas, whose flow tempo visibly shifts with the chosen fps.
• Primary action: Choose the output fps.
• Supporting actions: Return to the Code surface; move to any other parameter surface; trigger a render from the pinned Render action.
• Domain entities: Output fps; the four output parameter values currently in effect.
• Component responsibilities:
  • FPS control: ruled row with label column and value column; commits the chosen fps.
  • Preview canvas: generative field whose flow tempo responds live to the chosen fps.
  • Ruled metadata strip: four aligned label/value pairs, with the FPS pair reflecting the current choice.
  • Render action: coral action pinned to the bottom of the right rail on desktop, sticky footer bar on mobile.
• States:
  • Loading: the control initializes with the current fps value; the preview canvas initializes independently.
  • Empty: no fps explicitly chosen — the control shows the current effective value rather than an empty field.
  • Success: the chosen fps is committed; the metadata strip's FPS value updates with a 120ms value-flip, the preview canvas flow tempo shifts, and a single 600ms light sweep crosses the active panel.
  • Error: a chosen fps cannot be applied — the surface states the failure plainly and retains the previously effective fps.
  • Recovery: the developer chooses another fps; the previous valid value remains in effect until a new one is accepted.

Duration

• Information and state: The surface for choosing the render output duration. A ruled row with a left-hand label column and a right-hand value column presents the duration control; the current value is set in IBM Plex Mono 20px with tabular numerals. The centre stage shows the generative preview canvas with the ruled metadata strip beneath it.
• Primary action: Choose the output duration.
• Supporting actions: Return to the Code surface; move to any other parameter surface; trigger a render from the pinned Render action.
• Domain entities: Output duration; the four output parameter values currently in effect.
• Component responsibilities:
  • Duration control: ruled row with label column and value column; commits the chosen duration.
  • Preview canvas: generative field reflecting the current parameter set.
  • Ruled metadata strip: four aligned label/value pairs, with the DURATION pair reflecting the current choice.
  • Render action: coral action pinned to the bottom of the right rail on desktop, sticky footer bar on mobile.
• States:
  • Loading: the control initializes with the current duration value; the preview canvas initializes independently.
  • Empty: no duration explicitly chosen — the control shows the current effective value rather than an empty field.
  • Success: the chosen duration is committed; the metadata strip's DURATION value updates with a 120ms value-flip and a single 600ms light sweep crosses the active panel.
  • Error: a chosen duration cannot be applied — the surface states the failure plainly and retains the previously effective duration.
  • Recovery: the developer chooses another duration; the previous valid value remains in effect until a new one is accepted.

Aspect Ratio

• Information and state: The surface for choosing the render output aspect ratio. The selector is a set of four outlined rectangles that actually render the ratio — 16:9, 9:16, 1:1, 2.39:1 — rather than text chips. The centre stage shows the generative preview canvas, whose frame reshapes with a 400ms morph when a ratio is selected.
• Primary action: Choose the output aspect ratio.
• Supporting actions: Return to the Code surface; move to any other parameter surface; trigger a render from the pinned Render action.
• Domain entities: Output aspect ratio; the four output parameter values currently in effect.
• Component responsibilities:
  • Aspect ratio selector: four outlined rectangles, each drawn at its true ratio; commits the chosen ratio.
  • Preview canvas: generative field whose frame morphs over 400ms to the chosen ratio.
  • Ruled metadata strip: four aligned label/value pairs, with the RATIO pair reflecting the current choice.
  • Render action: coral action pinned to the bottom of the right rail on desktop, sticky footer bar on mobile.
• States:
  • Loading: the selector initializes with the current ratio indicated; the preview canvas initializes independently.
  • Empty: no ratio explicitly chosen — the current effective ratio is indicated rather than no selection.
  • Success: the chosen ratio is committed; the preview canvas frame morphs over 400ms, the metadata strip's RATIO value updates with a 120ms value-flip, and a single 600ms light sweep crosses the active panel.
  • Error: a chosen ratio cannot be applied — the surface states the failure plainly and retains the previously effective ratio.
  • Recovery: the developer selects another ratio; the previous valid ratio remains in effect until a new one is accepted.

Render Output

• Information and state: The surface that presents the rendered video produced using the supplied Remotion code and the selected settings. The rendered video occupies the centre stage, with the ruled metadata strip beneath it showing the exact four parameter values the render was produced at, so the developer can confirm the output matches the chosen parameters.
• Primary action: Review the rendered video.
• Supporting actions: Return to the Code surface to change the composition; move to any parameter surface to change settings and render again.
• Domain entities: The rendered video; the four output parameter values the render was produced at.
• Component responsibilities:
  • Rendered video player: presents the rendered video produced from the supplied code and selected settings.
  • Ruled metadata strip: four aligned label/value pairs in IBM Plex Mono with tabular numerals, showing the parameter values the render was produced at.
  • Render action: coral action pinned to the bottom of the right rail on desktop, sticky footer bar on mobile, available for a subsequent render.
• States:
  • Loading: a render is in progress — the surface indicates that the render is running and does not present a video until one exists.
  • Empty: no render has been produced yet — the surface states that no rendered output exists and points the developer back to supplying code and settings.
  • Success: the rendered video is presented, with the metadata strip showing the parameter values it was produced at.
  • Error: the render fails — the surface states the failure plainly, retains the supplied code and the selected parameter values so nothing must be re-entered, and offers a retry.
  • Recovery: the developer retries the render with the retained code and settings, or returns to the Code or parameter surfaces to change them and render again.

3. Functional Requirements

FR-1 — Render Remotion code (provenance: explicit) As a Remotion Developer, I should be able to render my Remotion code, so that my composition becomes a finished video.

• Actor: Remotion Developer.
• Trigger/input: The developer supplies Remotion code on the Code surface and triggers a render from the pinned Render action.
• Observable result/state change: A rendered video is produced from the supplied code and presented on the Render Output surface.
• Access state: Anonymous; no identity required.
• Material failure/recovery: If the supplied code cannot be accepted as a Remotion composition, or if the render fails, the failure is stated plainly, the supplied code and selected parameter values are retained, and the developer can correct and retry.
• Continuation: After a successful render, the developer can review the output, change the code, change parameters, and render again.

FR-2 — Choose output resolution (provenance: explicit) As a Remotion Developer, I should be able to choose the output resolution, so that my rendered video is produced at the dimensions I need.

• Actor: Remotion Developer.
• Trigger/input: The developer sets the resolution on the Resolution surface.
• Observable result/state change: The chosen resolution is committed and reflected in the ruled metadata strip's RESOLUTION value; the next render is produced at that resolution.
• Access state: Anonymous; no identity required.
• Material failure/recovery: If a chosen resolution cannot be applied, the failure is stated plainly and the previously effective resolution remains in effect.
• Continuation: The developer can change the resolution again or proceed to render.

FR-3 — Choose output fps (provenance: explicit) As a Remotion Developer, I should be able to choose the output fps, so that my rendered video plays at the frame rate I need.

• Actor: Remotion Developer.
• Trigger/input: The developer sets the fps on the FPS surface.
• Observable result/state change: The chosen fps is committed and reflected in the ruled metadata strip's FPS value; the preview canvas flow tempo visibly shifts; the next render is produced at that fps.
• Access state: Anonymous; no identity required.
• Material failure/recovery: If a chosen fps cannot be applied, the failure is stated plainly and the previously effective fps remains in effect.
• Continuation: The developer can change the fps again or proceed to render.

FR-4 — Choose output duration (provenance: explicit) As a Remotion Developer, I should be able to choose the output duration, so that my rendered video runs for the length I need.

• Actor: Remotion Developer.
• Trigger/input: The developer sets the duration on the Duration surface.
• Observable result/state change: The chosen duration is committed and reflected in the ruled metadata strip's DURATION value; the next render is produced at that duration.
• Access state: Anonymous; no identity required.
• Material failure/recovery: If a chosen duration cannot be applied, the failure is stated plainly and the previously effective duration remains in effect.
• Continuation: The developer can change the duration again or proceed to render.

FR-5 — Choose output aspect ratio (provenance: explicit) As a Remotion Developer, I should be able to choose the output aspect ratio, so that my rendered video is framed the way I need.

• Actor: Remotion Developer.
• Trigger/input: The developer selects a ratio from the four outlined rectangles on the Aspect Ratio surface.
• Observable result/state change: The chosen ratio is committed and reflected in the ruled metadata strip's RATIO value; the preview canvas frame morphs over 400ms to the chosen ratio; the next render is produced at that ratio.
• Access state: Anonymous; no identity required.
• Material failure/recovery: If a chosen ratio cannot be applied, the failure is stated plainly and the previously effective ratio remains in effect.
• Continuation: The developer can select another ratio or proceed to render.

FR-6 — Review the rendered output (provenance: required_inference) As a Remotion Developer, I should be able to review the rendered video together with the parameter values it was produced at, so that I can confirm the output matches the settings I chose.

• Actor: Remotion Developer.
• Trigger/input: A render completes after the developer triggers it from the pinned Render action.
• Observable result/state change: The rendered video is presented on the Render Output surface with the ruled metadata strip showing the four parameter values it was produced at.
• Access state: Anonymous; no identity required.
• Material failure/recovery: If the render fails, the failure is stated plainly, the supplied code and selected parameter values are retained, and a retry is offered.
• Continuation: The developer can return to the Code or parameter surfaces, adjust, and render again.
• Necessity: This is the observable result of FR-1; without it the developer cannot see the outcome of the render they initiated.

FR-7 — Keep chosen parameters in view (provenance: required_inference) As a Remotion Developer, I should be able to see my currently chosen resolution, fps, duration, and aspect ratio at all times while working in the console, so that I always know what the next render will be produced at.

• Actor: Remotion Developer.
• Trigger/input: The developer is on any console surface.
• Observable result/state change: The ruled metadata strip shows four aligned label/value pairs (RESOLUTION / FPS / DURATION / RATIO) in IBM Plex Mono with tabular numerals, reflecting the current values.
• Access state: Anonymous; no identity required.
• Material failure/recovery: Not applicable — the strip is a read-only reflection of committed values and cannot itself fail independently of the parameter surfaces.
• Continuation: The developer continues configuring or renders.
• Necessity: The four parameter choices are the product's core decisions; keeping them observable is required for the developer to confirm what a render will produce.

4. User Personas

Remotion Developer

Product context. The Remotion Developer writes video as code. Their composition is a Remotion project — React-based programmatic video — and they think of their code as the camera. They come to remotion-render with a composition already in mind and a specific output in mind: a particular resolution, a particular frame rate, a particular length, a particular frame. They are comfortable with numbers as creative material and expect to set them precisely rather than pick from a coarse preset list.

Primary goal. To turn their Remotion code into a rendered video produced at exactly the output parameters they chose.

Distinct accepted responsibilities.

• Supplying the Remotion code that is to be rendered (Code surface).
• Choosing the output resolution (Resolution surface).
• Choosing the output fps (FPS surface).
• Choosing the output duration (Duration surface).
• Choosing the output aspect ratio (Aspect Ratio surface).
• Triggering the render and reviewing the resulting video against the parameters it was produced at (Render Output surface).

Relevant inputs and decisions. The developer's inputs are their Remotion composition source and four numeric or ratio selections. Their decisions are which resolution, which fps, which duration, and which aspect ratio the output should carry — and, after reviewing a render, whether to accept the output or change the code or parameters and render again.

Interactions with other accepted participants. The Remotion Developer is the only accepted human actor in remotion-render. There is no second human participant, no approver, no reviewer, and no recipient whose acceptance gates the work. The developer's counterpart in the workflow is the system's render execution, which they trigger and whose result they observe.

Observable success. A rendered video appears on the Render Output surface, presented alongside the four parameter values it was produced at, matching the developer's chosen resolution, fps, duration, and aspect ratio.

What makes this role's work different. The developer's work is not form-filling. Each of the four parameters is a creative decision that changes the artifact, and the console treats them that way: the preview canvas's flow tempo responds to the chosen fps, its frame morphs to the chosen aspect ratio, and the parameter values are always visible as an instrument readout. The developer's loop is configure → render → inspect → reconfigure, and the console is built to keep that loop tight and legible.

5. Core User Flows

Flow 1 — First visit and entry into the console

1. The Remotion Developer arrives at the Landing surface anonymously. No sign-in is requested and none is available.
2. The full-bleed near-black canvas (#07070A) carries a live generative particle/fluid field in teal-to-mint (#7CE7D0), densest in the right two-thirds. The oversized flush-left headline "Your code, rendered." sits in the canvas's quiet left third, with "rendered" in coral (#FF6B4A).
3. Beneath the headline, the ruled metadata strip reads "1920 × 1080 · 60 FPS · 12.5s · 16:9" with the digits ticking over live, so the developer immediately understands that resolution, fps, duration, and aspect ratio are the product's material.
4. The developer selects the coral outlined button "Open the console" pinned directly beneath the strip.
5. Observable result: the developer enters the working console at the Code surface, with the three-zone layout in place — left rail, centre preview stage with the ruled metadata strip beneath it, and right parameter rail with the coral Render action pinned to the bottom.
6. Continuation: the developer proceeds to supply their Remotion code (Flow 2).

Failure and recovery: if the generative canvas fails to initialize, the Landing surface falls back to a composed still frame of the field. The headline, metadata strip, and console entry button remain fully readable and operable, and the developer is never blocked from entering the console.

Flow 2 — Supplying Remotion code

1. The Remotion Developer is on the Code surface with the console layout in place.
2. The developer enters or points to their Remotion composition in the code entry block, which displays it with palette-derived syntax colouring — teal keywords, coral strings, muted comments.
3. The developer submits the code as the composition to be rendered.
4. Observable result: the code is accepted as the composition to be rendered. The ruled metadata strip beneath the preview continues to show the four current parameter values.
5. Continuation: the developer moves to the parameter surfaces to set the output (Flows 3–6), or triggers a render directly if the current parameters are already what they want.

Failure and recovery: if the supplied code cannot be accepted as a Remotion composition, the surface states the failure plainly and keeps the developer's input intact. The developer edits the code in place and resubmits; nothing is discarded.

Flow 3 — Choosing the output resolution

1. The Remotion Developer is in the console and moves to the Resolution surface via the left rail.
2. The surface presents a ruled row with a left-hand label column and a right-hand value column; the current resolution is set in IBM Plex Mono 20px with tabular numerals.
3. The developer chooses the output resolution.
4. Observable result: the chosen resolution is committed. The metadata strip's RESOLUTION value updates with a 120ms value-flip in the mono digits, and a single 600ms light sweep crosses the active panel. The next render will be produced at that resolution.
5. Continuation: the developer moves to another parameter surface or triggers a render.

Failure and recovery: if the chosen resolution cannot be applied, the surface states the failure plainly and the previously effective resolution remains in effect, so the developer is never left without a valid value. The developer chooses another resolution.

Flow 4 — Choosing the output fps

1. The Remotion Developer moves to the FPS surface via the left rail.
2. The surface presents a ruled row with a left-hand label column and a right-hand value column; the current fps is set in IBM Plex Mono 20px with tabular numerals.
3. The developer chooses the output fps.
4. Observable result: the chosen fps is committed. The metadata strip's FPS value updates with a 120ms value-flip, the preview canvas's generative flow tempo visibly shifts to reflect the new frame rate, and a single 600ms light sweep crosses the active panel. The next render will be produced at that fps.
5. Continuation: the developer moves to another parameter surface or triggers a render.

Failure and recovery: if the chosen fps cannot be applied, the surface states the failure plainly and the previously effective fps remains in effect. The developer chooses another fps.

Flow 5 — Choosing the output duration

1. The Remotion Developer moves to the Duration surface via the left rail.
2. The surface presents a ruled row with a left-hand label column and a right-hand value column; the current duration is set in IBM Plex Mono 20px with tabular numerals.
3. The developer chooses the output duration.
4. Observable result: the chosen duration is committed. The metadata strip's DURATION value updates with a 120ms value-flip and a single 600ms light sweep crosses the active panel. The next render will be produced at that duration.
5. Continuation: the developer moves to another parameter surface or triggers a render.

Failure and recovery: if the chosen duration cannot be applied, the surface states the failure plainly and the previously effective duration remains in effect. The developer chooses another duration.

Flow 6 — Choosing the output aspect ratio

1. The Remotion Developer moves to the Aspect Ratio surface via the left rail.
2. The surface presents four outlined rectangles that actually render the ratio — 16:9, 9:16, 1:1, 2.39:1 — rather than text chips.
3. The developer selects one of the four rectangles.
4. Observable result: the chosen ratio is committed. The preview canvas frame morphs over 400ms to the chosen ratio rather than swapping, the metadata strip's RATIO value updates with a 120ms value-flip, and a single 600ms light sweep crosses the active panel. The next render will be produced at that ratio.
5. Continuation: the developer moves to another parameter surface or triggers a render.

Failure and recovery: if the chosen ratio cannot be applied, the surface states the failure plainly and the previously effective ratio remains in effect. The developer selects another ratio.

Flow 7 — Rendering and reviewing the output

1. The Remotion Developer has supplied Remotion code on the Code surface and has set resolution, fps, duration, and aspect ratio on their respective surfaces. The ruled metadata strip shows all four current values.
2. The developer triggers the render from the coral Render action pinned to the bottom of the right rail on desktop, or from the sticky footer bar on mobile.
3. The system executes the render using the supplied code and the four selected parameter values. The developer does not interact with the render engine directly.
4. Observable result: the rendered video is presented on the Render Output surface, with the ruled metadata strip beneath it showing the exact four parameter values the render was produced at — so the developer can confirm the output matches the settings they chose.
5. Continuation: the developer reviews the video. If it is what they wanted, the flow is complete. If not, they return to the Code surface to change the composition or to a parameter surface to change a setting, and render again.

Failure and recovery: if the render fails, the Render Output surface states the failure plainly, retains the supplied code and the selected parameter values so nothing must be re-entered, and offers a retry. The developer either retries with the retained code and settings or returns to the Code or parameter surfaces to change them and render again.

In-progress state: while a render is running, the Render Output surface indicates that the render is in progress and does not present a video until one exists. If no render has been produced yet, the surface states that no rendered output exists and points the developer back to supplying code and settings.

6. Visuals Colors and Theme

Muse and headline. Refik Anadol — data made physical: a render console where the frame is the artwork. The product's own parameters are the animation, and the console reads as an instrument rather than a settings form.

Mode. Dark mode only.

Colour tokens by role:

Colour discipline. Colour is used like light, not like fill. 85% of the surface is dark; the hero canvas glows; the coral appears on exactly one control at a time. Coral is never used for text on dark ground — it is a fill only, with #07070A text on top. Body text on #07070A and #101018 clears WCAG AA at 16px.

Typography.

• Headings: Space Grotesk at 500/600, tight tracking (−0.02em), sentence case with occasional uppercase micro-labels. Numbers in headings use the same face at tabular weight.
• Body: IBM Plex Mono.
• Scale: 1.25 modular — 132 / 72 / 44 / 28 / 20 / 16 / 13.
• Hero display: clamp(44px, 9vw, 132px) with tight leading (0.94), so the words read as an object, not a sentence.
• Section titles: clamp(28px, 3.2vw, 44px).
• Panel labels: 13px uppercase, +0.14em tracking, IBM Plex Mono.
• Parameter values: all parameter values (1920, 60, 12.5s, 16:9) set in IBM Plex Mono 20px with tabular numerals so digits never jitter as they change.

Shape language. Soft-edged rectilinear panels with 10px radii floating over a full-bleed canvas, hairline 1px borders at rgba(242,240,236,0.10), and a single 1px inner highlight on active panels. No cards-on-cards and no pill soup: controls are ruled rows with a left-hand label column and a right-hand value column, separated by 1px dividers. The aspect-ratio selector is a set of outlined rectangles that actually show the ratio (16:9, 9:16, 1:1, 2.39:1) rather than text chips.

Spacing rhythm. A consistent ruled-row rhythm: label column left, value column right, 1px dividers between rows, generous vertical breathing room around the preview stage so the canvas reads as the artwork and the controls read as the instrument.

Imagery style. No stock photography and no device mockups. Imagery is the product's own output: a real-time generative canvas (particle/fluid render derived procedurally, not from user code) that stands in for "your composition", plus monospace code blocks with syntax colouring drawn from the palette (teal keywords, coral strings, muted comments). Diagrams are thin luminous strokes on dark — a frame-timeline ruler, an aspect-ratio rectangle diagram, a frame-count grid. Every visual element is either generative output or a precise schematic; nothing decorative.

Layout. A three-zone console that never becomes a generic dashboard. Left rail (240px on desktop, collapsed to a 56px icon rail at 768px, bottom tab bar at 375px) carries the seven surfaces: Landing, Code, Resolution, FPS, Duration, Aspect Ratio, Render Output. Centre stage is the persistent generative preview canvas with a ruled metadata strip beneath it (four aligned label/value pairs: RESOLUTION / FPS / DURATION / RATIO). Right rail (320px) holds the active parameter editor, with the coral Render action pinned to the bottom of that rail on desktop and to a sticky footer bar on mobile. The Landing hero breaks the console grid entirely: full-bleed canvas, one oversized headline flush-left, no centred stack.

Readability at every viewport. Headlines, wordmarks, labels, numbers, and controls stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling (for example font-size: clamp(...) with its mobile size) to fit, and no other element covers any part of them. Imagery, decoration, and motion may be cropped, bled off an edge, or overlapped as the direction asks, as long as they cover no readable text or control.

7. Signature Design Concept

The first screen is a render already running.

The Landing surface is a full-bleed near-black canvas (#07070A) carrying a live generative particle/fluid field in teal-to-mint (#7CE7D0). The field is never centred and never symmetrical: its densest region sits in the right two-thirds, leaving the left third as quiet dark space.

Into that left third, flush-left and bleeding slightly past the 12-column grid, sits one oversized headline in Space Grotesk at clamp(44px, 9vw, 132px): "Your code, rendered." stacked in three tight lines, with the word "rendered" set in coral (#FF6B4A) so the accent lands on the verb rather than on a button.

Beneath the headline, a single ruled metadata strip in IBM Plex Mono reads "1920 × 1080 · 60 FPS · 12.5s · 16:9" with the digits ticking over live, as if a render were already running. Directly beneath the strip — not centred, not floating — sits one coral outlined button: "Open the console".

There is no gradient blob, no centred headline-plus-subtext-plus-blue-button stack, and no illustration. The generative field is the hero, and the headline sits inside its negative space. The field's tempo and colour drift respond live to the currently selected fps and aspect ratio, so the first screen is never the same twice and the product's own parameters are the animation.

8. Interaction Model & Motion Direction

Interaction Model: Animated Motion Tempo: cinematic Hero Dimensionality: webgl

Landing Hero Motion Brief

• Focal subject. A real-time generative particle/fluid field drifting across a full-bleed near-black canvas (#07070A) in teal-to-mint (#7CE7D0), densest in the right two-thirds, with the oversized flush-left headline occupying the quiet left third.
• Input → transformation → outcome thesis. The developer's currently selected fps and aspect ratio values drive the field: changing fps visibly shifts the flow's tempo, and changing aspect ratio reshapes the canvas frame with a 400ms morph. The outcome is that the first screen is never the same twice, and the product's own parameters are the animation — the hero demonstrates the product's premise rather than describing it.
• Motion vocabulary. One continuous slow generative flow (particle/fluid field, ~40s loop, no visible restart) with colour drift driven by the current parameter values; scroll-linked parallax at a 0.15 ratio on the hero headline and the metadata strip; a 120ms value-flip in the mono digits when a parameter changes; a single 600ms light sweep across the active panel.
• Composed first frame. The field's densest region already occupying the right two-thirds, the headline fully set in the left third with "rendered" in coral, the ruled metadata strip reading "1920 × 1080 · 60 FPS · 12.5s · 16:9" with digits mid-tick, and the coral outlined "Open the console" button pinned beneath the strip. Nothing is centred; nothing is symmetric.
• Reduced-motion state. Under prefers-reduced-motion, the canvas freezes on a composed still frame, the digits swap instantly with no value-flip, and no light sweeps occur. The headline, metadata strip, and console entry button remain fully readable and operable.

Landing Hero 3D Scene Brief — DIRECTION-DERIVED

The hero dimensionality is webgl, so the hero is a real-time WebGL scene rather than a static image or a CSS approximation.

• The crafted object. A single continuous particle/fluid field — a compact real-time system of luminous points and advected flow, not a scene of multiple objects. It is the product's defining state made visible: a composition plus numeric parameters becoming a moving image.
• What it shows. The field's flow tempo is bound to the currently selected fps and its frame geometry to the currently selected aspect ratio, so the scene's behaviour is a direct readout of the developer's parameter values. It is never decorative motion: it is data-linked or it is absent.
• Composition. The field's densest region sits in the right two-thirds of the viewport; the left third stays quiet dark space for the headline. The scene is never centred and never symmetrical.
• Colour. Luminous teal-to-mint (#7CE7D0) currents on the near-black ground (#07070A), with the single hot coral (#FF6B4A) reserved for the active/selected state and the primary Render action — never for text on dark.
• Reduced-motion state. The scene freezes on a composed still frame; no continuous flow, no morph, no sweeps.

9. Non-Functional Requirements

NFR-1 — Anonymous access throughout (provenance: explicit via Planning Scope access contract) Every surface — Landing, Code, Resolution, FPS, Duration, Aspect Ratio, and Render Output — is reachable without identity. No sign-in, registration, invitation, or provisioning step exists. Rationale: the accepted requirements establish no durable cross-session identity, no entitlement, and no value transfer that must remain bound to a returning participant.

NFR-2 — Responsive console layout (provenance: explicit via creative direction) The three-zone console collapses to a 56px icon rail at 768px and to a bottom tab bar at 375px, with the coral Render action migrating from the right rail to a sticky footer. The console never reflows into a generic card grid.

NFR-3 — Readable text and controls at every viewport (provenance: explicit via creative direction) Headlines, wordmarks, labels, numbers, and controls stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling to fit, with no other element covering any part of them.

NFR-4 — Reduced-motion compliance (provenance: explicit via creative direction) Under prefers-reduced-motion, the generative canvas freezes on a composed still frame, parameter digits swap instantly with no value-flip, and no light sweeps occur. All content and controls remain fully readable and operable.

NFR-5 — Colour contrast (provenance: explicit via creative direction) Body text on #07070A and #101018 clears WCAG AA at 16px. Coral (#FF6B4A) is never used for text on dark ground; it is a fill only, with #07070A text on top.

NFR-6 — Data-linked motion (provenance: explicit via creative direction) Generative motion must respond to the developer's actual parameter values. Decorative particles that do not respond to parameter values are prohibited; motion is data-linked or absent.

NFR-7 — Tabular numerals for parameter values (provenance: explicit via creative direction) All parameter values are set in IBM Plex Mono 20px with tabular numerals so digits never jitter as they change.

NFR-8 — Render failure preserves developer input (provenance: required_inference) When a render fails, the supplied Remotion code and the selected parameter values are retained so nothing must be re-entered, and a retry is offered. Rationale: without retention, a failed render would force the developer to reconstruct their composition and settings, making the render lifecycle unusable.

10. Tech Stack

• Frontend: React, delivered as a first-party custom web console.
• Real-time hero rendering: WebGL, with React Three Fiber and Drei for the generative particle/fluid hero scene, as required by the creative direction's webgl hero dimensionality.
• Backend: Python with FastAPI, handling render submission and render execution coordination.
• Storage: Not specified by the user. No durable developer-owned state is required by the accepted requirements; the console holds the current session's code and parameter values.
• Containerization: Docker with docker-compose for local and single-host deployment.
• Orchestration: Kubernetes is not required by the accepted requirements and is not included.

11. Assumptions and Constraints

Assumptions

• A-1 (required_inference) — The developer's Remotion code is supplied to the console as source text or as a reference to it, and the console accepts it as the composition to be rendered. The accepted requirement states that the developer "can render my code" without specifying the submission mechanism; the Code surface's entry block is the minimum mechanism that makes the requirement usable.
• A-2 (required_inference) — The rendered video is presented for review within the console on the Render Output surface. The accepted requirement establishes that a render produces output; presenting that output is the minimum observable result that makes the render lifecycle complete.
• A-3 (required_inference) — The four parameter values remain visible while the developer works in the console, via the ruled metadata strip. The accepted requirements make all four parameters first-class decisions; keeping them observable is required for the developer to know what the next render will produce.
• A-4 (required_inference) — The generative preview canvas is a procedural visual derived from the developer's parameter values and is not a render of the developer's actual code. The creative direction specifies this explicitly ("a real-time generative canvas (particle/fluid render derived procedurally, not from user code) that stands in for 'your composition'").

Constraints

• C-1 — No account system, sign-in, registration, invitation, or provisioning exists. All surfaces are anonymous.
• C-2 — No permissions, roles, or differentiated visibility exist. There is a single accepted human actor and no shared product state requiring differentiated control.
• C-3 — The seven surfaces are fixed: Landing, Code, Resolution, FPS, Duration, Aspect Ratio, Render Output. No additional surfaces are introduced.
• C-4 — The generic indigo/blue-on-white SaaS template is forbidden. The ground is #07070A and the primary is teal #7CE7D0.
• C-5 — Inter, Roboto, Arial, Helvetica, Open Sans, Lato, Poppins, and system-ui are forbidden for headings and body. Space Grotesk and IBM Plex Mono only.
• C-6 — Gradient-blob hero backgrounds, purple-to-pink SaaS gradients, and centred headline-plus-subtext-plus-button stacks are forbidden.
• C-7 — A grid of identical hover-lift cards is forbidden. Parameter controls are ruled rows; the only lifted surface is the active panel.
• C-8 — Stock photography, device mockups, 3D glass panels, and floating translucent cards are forbidden.
• C-9 — Pure #FFFFFF text on #07070A is forbidden; use #F2F0EC. Coral text on dark ground is forbidden; coral is a fill only, with #07070A text on top.
• C-10 — Cropping, clipping, or overlapping any label, number, control, or headline at 375px, 768px, or 1280px is forbidden.

12. Glossary

• Remotion — A framework for creating videos programmatically using React. A Remotion composition is React code that describes a video.
• Remotion Developer — The single accepted human actor in remotion-render: a developer who writes Remotion code and renders it with chosen output parameters.
• Composition — The developer's Remotion code, treated as the source that is rendered into a video.
• Resolution — The output dimensions of the rendered video, expressed as width × height (for example 1920 × 1080).
• FPS — Frames per second; the output frame rate of the rendered video.
• Duration — The output length of the rendered video.
• Aspect Ratio — The proportional relationship between the output video's width and height, chosen from 16:9, 9:16, 1:1, and 2.39:1.
• Render — The system process that turns the supplied Remotion code plus the four selected parameter values into a finished video.
• Ruled metadata strip — The persistent readout beneath the preview canvas showing four aligned label/value pairs (RESOLUTION / FPS / DURATION / RATIO) in IBM Plex Mono with tabular numerals.
• Generative preview canvas — The real-time procedural particle/fluid field that stands in for "your composition" and whose tempo and frame respond to the developer's selected fps and aspect ratio. It is not a render of the developer's code.
• Console — The three-zone working layout of remotion-render: left rail, centre preview stage, right parameter rail.