Case study · OnReplay
At a glance
| Role | Sole engineer and product owner |
| Period | December 2025 to present, about 2,500 commits |
| Product | Consumer web app, paid per render, 8 languages |
| Stack | AWS serverless (Lambda, Step Functions, DynamoDB, Batch), Expo / React, Astro, Stripe |
| AI | Gemini, Kling, Grok, OpenAI, Veo, Sora, HeyGen |
| Scale | 30 themed worlds, 140 Lambda functions, about 3,200 marketing pages |
Traction
Since the first film in January 2026, OnReplay has delivered 3,121 films to 2,065 creators.
| Metric | Value |
|---|---|
| Creators who received a film | 2,065 |
| Registered accounts | 11,083 |
| Films delivered | 3,121 |
| AI-animated clips in delivered films | 7,767 |
| Photos transformed by AI | 9,541 |
| Finished film delivered | 791 minutes, about 13 hours |
| Paid renders delivered successfully | 98% |
| Films made in a language other than English | 32% |
Volume has grown every quarter, from 531 films in Q1 to 1,373 in Q3, on the same pipeline.
The product
A user picks a themed "world" (a wedding, a family Christmas, a superhero comic, a pet tribute), uploads a few photos, and minutes later receives a short film starring their own faces, animated and scored. Each render costs credits, bought as packs or a subscription.
The hard part is not calling a model. It is turning slow, metered, sometimes failing AI services into something a paying customer experiences as reliable, with failures recovered automatically and no human in the loop.
Architecture
Four repositories on one AWS account, with no servers to manage. Every request is a Lambda, state lives in DynamoDB and S3, and the one long-running job, rendering a film, is a Step Functions workflow that hands video assembly to low-cost Spot compute.
The AI rendering pipeline
All photo transformations finish before any video job starts, so cheap failures surface before expensive ones. Each clip is keyed by photo and scene, so a re-run only pays for what failed. Limits such as the 60-minute wait window are code constants checked by tests, so they cannot silently drift.
How AI is used
Every film uses at least three generative models, and none is trusted to be available: each step has a fallback and a cost ceiling.
| Step | Models | Fallback |
|---|---|---|
| Restyle each photo into the world | Gemini | Grok, then OpenAI, with a softened prompt in between |
| Write the motion prompt for each clip | GPT-4o | A hand-written default |
| Animate each image into a clip | Kling, with Veo, Sora and HeyGen for A/B tests | Grok |
| Stitch, score and watermark the film | ffmpeg, no model | On-demand compute if Spot is unavailable |
What running this in production taught me:
- Retrying the same provider rarely helps. A content-moderation rejection is deterministic, so the system switches provider or softens the prompt instead.
- Fallbacks can quietly double your costs. Per-film cost tracking caught one fallback path doing exactly that within a day, so cost now gates every fallback.
- Provider errors are often misleading. "Rate limited" sometimes meant "out of prepaid credit". Each error type is classified so the system retries, reroutes or alerts as appropriate.
One pipeline, 30 products
Each themed world is configuration and prompts, not new code, so a new world ships without touching the orchestration. Ten worlds also let users pick from a catalogue of 105 scenes.
The AI models were never the weak point; configuration was. Automated checks now fail the build whenever a world is incomplete, so every world reaches customers fully wired, down to the scenes each user picks.
Making it reliable
Most of the work after launch went into making third-party AI behave like dependable infrastructure. Each fix below came from a real production incident.
| Problem | Fix |
|---|---|
| Large albums lost scenes when the video provider hit its concurrency limit | A shared slot counter that queues jobs instead of dropping them |
| Slow renders were reported as failures | A longer wait window and up to two automatic re-runs that reuse finished clips, never charging twice |
| The provider ran out of prepaid credit and the error looked like a rate limit | Explicit error classification plus a balance monitor that alerts before credit runs out |
| A fallback path doubled the cost per photo | The fallback was removed by design, and cost is now tracked per film |
| Cloud Spot capacity dried up and stalled video assembly | Automatic overflow to on-demand compute, plus a stuck-queue monitor |
The pattern: never just retry harder. Make the failure visible, classify it, cap what it can cost, and add a test so it cannot return.
Monetization and growth
Revenue. Users buy credit packs or a subscription through Stripe, in three currencies, with self-serve cancellation. New accounts get one free film. Prices are defined once and checked automatically across all three codebases.
Acquisition. The marketing site generates about 3,200 SEO pages in eight languages from the same 30 worlds, plus a keyword-driven blog. Eight free single-photo tools act as a funnel into the paid app, and every step is tracked in PostHog.
Outcomes
In ten months, working alone, I shipped and now operate a paid consumer AI product that has delivered 3,121 films to 2,065 creators.
- Shipped: 30 themed worlds, a Stripe credit and subscription business, a marketing engine in eight languages, and an admin backoffice with revenue and production dashboards.
- Reliable: provider outages, content rejections and capacity shortages are handled automatically, and customers are never charged twice for a failed film.
- Lean: fixed infrastructure cost stays in the tens of dollars a month. The variable cost is AI usage, which is tracked per film.
My lessons for teams building on generative AI:
- Treat every model call as a flaky, metered external dependency, and never let a retry or fallback spend money you did not budget for.
- Keep prompts and product configuration in data, and test that the configuration is complete.
- Build the admin and debugging views early. They paid for themselves the first time a customer wrote in.