MarginX
What works today, how a job runs, and what happens next — verified against the current codebase.
Hook, offer, audience, framework, emotional angle, editing rhythm, visual style, and persuasion tactics — plus a 0–100 quality score for the source video.
Built scene by scene — either generated from scratch, or assembled from your own footage where you already own the right shot.
Engineering in one line: containers for web API, background worker, database, queue, and edge server — deployable to a single host, with media on local disk or cloud object storage.
Initial payment to begin the build.
ReceivedDue now — unlocks the rest of the work on the roadmap.
RequestedAfter complete product delivery and source code handover.
PendingThe 25% kickoff is received. The video proof of concept is achieved — full pipeline live from upload through finished video. Kindly release the next 50% so we can start the remaining work on the roadmap. The final 25% remains due on complete product delivery and source codes.
25% received → 50% due now → 25% on deliveryNine steps in order — scroll down the list
Source video, optional brief, optional brand assets. Pick by hand or let the system choose.
Technical details, audio, still frames, and the real cut points between shots — the basis for pacing.
Spoken audio becomes text. A silent video is fine — the system simply carries on.
A vision model reads on-screen text from the frames — captions, price tags, calls to action.
Six analyses — Marketing, Story, Copywriting, Editing, Visual, Sales Psychology — into one report plus a 0–100 score. The core IP.
Picks the right assets, expands your one-line brief, and writes the scene-by-scene plan with prompts.
The job stops here on purpose. Read the analysis, edit any scene, choose voice, ratio, length, model — preview before committing.
The explicit paid step. Narration first, then scenes, checks, lip-sync, audio, captions, assembly.
The finished video, individual scene clips, and a full export of the analysis and every prompt used.
This is the part most people assume is one API call — and it isn't. Rendering is a small pipeline of its own:
Every asset gets a text description — your tags if you wrote them, otherwise an automatic one. That text becomes a numeric "meaning fingerprint" (an embedding) stored in the database. When a job doesn't name specific assets, the system searches by meaning and attaches the closest matches, up to a configured limit. The chosen assets are recorded on the job, so you can see what the planner was given.
Two design points: there is exactly one definition of what an asset "says", shared by search and planner. And everything degrades safely — any failure falls back to simply passing along the attached assets. A job never fails because an optional convenience broke.
House rules you write once in Settings — read on every job by both the brief refiner and the planner, so they shape the story, not just the shots.
Every job keeps its full analysis, plan, prompts, per-stage timings, and error details. Nothing is thrown away — a job can be re-run or re-generated from its record.
Semantic search is built and tested but currently switched off in the running configuration. It is a configuration flag, not a rewrite — turning it on costs one small embedding call per asset at upload time, plus a one-command backfill for assets uploaded while it was off. It matters most once a library grows past a few dozen assets, because at that point the whole library no longer fits into a single planning request.
The system does not learn across jobs. It does not notice that your last three ads performed better with a particular hook and adjust. Each job is analysed fresh. Cross-job learning is a future capability, not a current one.
| What it does | Model | Provider |
|---|---|---|
| Understanding the source and the brief | ||
| Marketing analysis (all six), scene planning, writing generation prompts, fitting the script to length | Claude Sonnet 4.5 | Anthropic |
| Expanding your one-line brief into a structured brief | GPT-4o | OpenAI |
| Transcribing the source video's speech | Whisper | OpenAI |
| Reading on-screen text; describing assets; checking a generated face | GPT-4o mini | OpenAI |
| Asset "meaning fingerprints" for semantic search | text-embedding-3-small | OpenAI |
| Creating the video | ||
| Video generation (current default) | Seedance 1 Pro | ByteDance, via fal.ai |
| Video generation (selectable alternatives) | Kling v3 Pro · Kling v3 Turbo · Veo 3.1 · MiniMax Hailuo 2.3 Pro | via fal.ai |
| Cast reference portraits and opening frames | FLUX schnell | via fal.ai |
| Editing a start frame while holding the same actor | FLUX.1 Kontext | via fal.ai |
| Voice, sound, and faces | ||
| Narrator voiceover (20 selectable voices) | Kokoro | via fal.ai |
| Lip-sync for presenter scenes | sync-lipsync v2 | via fal.ai |
| Photoreal presenter avatars (optional) | HeyGen | HeyGen |
| Music bed, room ambience, sound effects | Stable Audio | via fal.ai |
Two model families read the brief on purpose. The analysis and the plan are both Claude's work, so your own stated intent is read independently by a different model family (GPT-4o) rather than by the same model that then plans from it. A deliberate check, not an accident of history.
Seedance became the default from a head-to-head test on real production content, not marketing claims. A scene asking for "looking directly at camera" came back from Kling with the subject's eyes closed; Seedance followed the instruction best of every model tried. Every earlier job used Kling — that test changed the default.
Model choice is not just a quality question. Each model constrains the work differently — max shot length, whether shots can share a generation, and how much direction a prompt can carry (one caps at 512 characters, another allows 20,000). The system knows each model's capabilities rather than assuming.
The video model is swappable per job and per scene. You're never locked to one engine.
You can already regenerate a scene, preview it, trim its start and end, swap in your own footage, rewrite its prompt or voiceover, and pick a different model for just that scene.
Missing: a real editor — a timeline where scenes are reordered and retimed visually, audio as its own layer, and frame-accurate edits, fixed by hand or described and done by the AI.
Adding a video model is a configuration entry, not a rebuild, and Veo 3.1 is already integrated and selectable. We tried Google's image-editing model and rejected it — it refused every photoreal person request.
Next: keep evaluating new video models, and upgrade the reasoning models behind analysis and planning beyond Claude Sonnet 4.5.
The account model already distinguishes admin from user, and active from suspended — the database is ready. Nothing enforces or exposes that yet: no admin screens, no admin-only actions.
The work is the interface and permission checks: see all accounts and jobs, suspend an account, inspect a failed job, without touching the database directly.
Every job records how long each stage took and how many attempts it needed — a useful foundation — but nothing records what each job cost in AI calls.
The work: meter every model call (model, job, account) and surface per-job and per-account cost, so pricing, quotas, and margin are visible instead of estimated.
Today all AI access runs on our keys, configured once for the whole system.
The work: let an account supply its own keys, stored encrypted, and have every model call for its jobs use them — a prerequisite for larger customers, and a natural pair with usage tracking (#4).
Already in: automatic quality checks with re-rolls on bad clips, reference portraits holding one actor across scenes, chained start frames, pacing cut to the voiceover, seam handling, layered ambience.
Next: systematic side-by-side testing of models and settings, higher-resolution output, better motion and lighting consistency, closing the gap to filmed footage.
Today the brief and every scene edit are typed.
The work: speak the ad you want, or say what to change, and have the system transcribe and act on it. Transcription already exists in the system — this wires it to the input side.
Today there is exactly one pipeline — the nine-step flow every job runs through, from upload to delivery.
The work: add more pipelines so different kinds of jobs get stages that fit them — other formats, lengths, and creative types each running their own tailored flow. Pipelines are planned as configuration entries, not a rebuild: adding one means defining its stages, not rewriting the engine.
Many behaviours already exist as configuration flags, not hard-coded product choices — but there is no proper settings UI for admin or user to turn them on, off, or tune them.
Example today: semantic search is built and tested but switched off in the running configuration. Turning it on is a flag, not a rewrite — one small embedding call per asset at upload, plus a one-command backfill for assets uploaded while it was off. It matters most once a library grows past a few dozen assets, when the whole library no longer fits in a single planning request.
The work: settings screens for admin (system-wide flags, feature toggles, defaults) and user (account-level preferences), so capabilities like semantic search, model defaults, limits, and similar options can be configured without touching code or the database by hand.