Dramatix

Story video is slow to produce by hand. A twenty-segment story needs characters who stay consistent, dialogue that matches their mood, scenes that stay coherent, and audio that lines up with it all. Most pipelines make a human the glue between half a dozen tools; I wanted the story text itself to drive the whole production.

Two-stage generation kept the hard parts separate: scene images anchor the visual context first, then video, audio, and dialogue generate in a unified pass with retry and quality validation. A ModelRouter with per-provider adapters routes to Kling, Veo, Sora, or Gemini behind user-facing tiers (Spotlight, Limelight, Premiere), with capability detection and fallback so a tier promise survives a provider failure. Story parsing is LLM-driven: free-form text becomes structured characters, relationships, scenes, and dialogue in one transaction.

The backend is serverless on AWS Lambda (Python + FastAPI + Mangum), with an SQS job queue and DLQ for workers and versioned REST plus WebSocket progress streaming. The continuity engine keeps a long story coherent: each character's emotional state, last action, and rolling plot summary are cached in Redis and persisted in PostgreSQL, and stale segments propagate when the story drifts. Flutter is the client (go_router, flutter_bloc), with Firebase Auth, FCM push, and Stripe + IAP credit monetization per tier. Content moderation sits at both doors: regex and ML input filtering, output scanning, and a human review queue. Data residency is eu-central-1 with a 30-day hard delete. Terraform owns the VPC, RDS, Lambda, SQS, ElastiCache, and API Gateway; GitHub Actions runs the Flutter build, Python tests, and terraform plan/apply.

The moderation queue was an afterthought. I would design the review workflow alongside the generation pipeline, because screening borderline content before it is produced is cheaper than cleaning it up after. I would also move the tier-to-provider mapping into the database so pricing changes do not need a deploy.