Reelry brings script planning, visuals, audio, and video assembly into one browser workflow. I designed and built the product, including its generation pipeline, accounts, and payments.
These notes describe the engineering behind that workflow. Product behavior was checked against reelry.app on 6 September 2026. For current plans and generation options, use the product website; prices and provider choices can change.
Review the plan before paying for generation
The user starts with a topic or script, then reviews the proposed hook and scene plan. Paid video generation begins after approval.
Separating planning from rendering gives the user a useful decision point. Changing a script is different from discarding a finished video. The interface needs to make clear which action starts paid work, what is being generated, and where to find the result.
Background jobs instead of a long browser request
A generation run can involve several external services. A request may time out, a provider may rate-limit a job, or an output may need another attempt. I used Inngest background functions to separate that work from the initial web request.
I divided the pipeline into named steps with stored results. This simplified outline shows the dependency between stages; it omits validation, status updates, and provider-specific handling:
const script = await step.run("write-script", () =>
generateScript({ topic, brandVoice })
);
const frames = await step.run("generate-frames", () =>
generateFrames({ script, palette, styleId })
);
const animated = await step.run("animate-frames", () =>
animateFrames(frames)
);
With checkpointed steps, completed work can be reused when a later step is retried. The important boundary is the provider call: if a provider accepted a job before the connection failed, retry handling also needs to account for that external job. A workflow engine does not make every side effect automatically safe to repeat.
The named stages also give the interface something more useful to display than an indefinite spinner. A user can see which part of the run is being processed. Inngest documents its execution and retry model here.
Different generation modes, one library
The current product offers Animated Art and Cinematic workflows, alongside an option to use the user’s own photos.
Animated Art combines generated images, optional motion, narration, and text with video assembly. Cinematic produces video scenes with native audio. Script generation uses Claude; configured visual providers, ElevenLabs narration where enabled, Veo for Cinematic, and Shotstack assembly perform different parts of the work. Providers and fallbacks can vary by run.
I kept the finished-video library separate from those implementation choices. The user needs to review and download a reel, regardless of which generation mode produced it.
Brand controls with room for variation
Animated Art can reuse a saved palette and visual style. A mascot reference is optional, and a saved voice applies when narration is enabled.
Those settings guide generation; they do not guarantee an identical character or visual result in every scene. The review flow matters because generated output still needs judgment.
Downloads and reminders, not automatic publishing
The current publishing flow is manual. Reelry exports a vertical MP4 and can send a reminder for a planned posting slot. The user uploads the file in TikTok, Instagram, or YouTube, where they can choose the final cover, caption, and platform-native sound.
This is a deliberate boundary between producing a file and publishing a post. Reelry’s calendar should not be described as an automatic social-publishing integration.
Accounts and credit billing
Reelry groups product data around organizations. Supabase handles authentication and database access policies. Those policies need to match membership and role rules; privileged server credentials still require their own careful handling.
Paid generation uses credits, with payments handled through Polar. The webhook work includes checking signatures, recording processed events, and handling repeated or out-of-order deliveries. The aim is to reconcile a payment with the right account without granting the same purchase twice.
I keep changing plan prices out of these engineering notes. The useful implementation lesson is to separate payment events, account entitlements, and generation jobs so each can be inspected when something goes wrong.
What this build demonstrates
Reelry is an example of connecting AI services to a usable product: review before paid work, visible job progress, downloadable output, accounts, and billing. It is not evidence of a particular client revenue result or a guaranteed generation time.
See Reelry’s production screenshots, or tell me about the workflow you want to build.