DEV Community: Justin Koo

I cut two dozen free spec trailers for founders. The silence taught me more than the replies.

Justin Koo — Sat, 26 Sep 2026 18:47:10 +0000

A few weeks ago I started cutting unsolicited 40–60 second trailers for small products and sending them to the founders. Free, no strings. The whole portfolio is public — twenty-plus specs, every one made from the product's own public UI.

Most of them got silence.

That silence is the interesting part. Here's what actually separated the ones that got replies from the ones that didn't — and none of it is about video quality, because I got better at the craft during the silent stretch and the reply rate didn't move.

What didn't matter

Polish. My early specs had rough cuts. The replies didn't correlate with the cleanest renders.
Length. 40s vs 60s vs 90s — no visible difference in response.
Music, motion, captions. Founders never mentioned them. Not once.

Founders don't grade your editing. They grade whether you understood their product.

What did matter

1. The spec must run on their real UI, not a mockup.

Every reply I've gotten came on a spec cut from the product's own playground, docs, or public demo. When I built "similar enough" scenes instead — silence. The difference is legible within three seconds: a founder knows their own pixels. Real UI says "I did the homework." A lookalike says "I have a template."

2. Reach out the same week they said the need out loud.

The replies clustered around founders who had publicly asked for exactly this thing that week — a post looking for a videographer, a launch thread, a "we need demo videos" tweet. The identical spec sent three weeks later, or to a founder who'd said nothing, sank. Timing isn't a growth hack; it's a filter for who has the problem right now.

3. One sentence of offer, not a menu.

My early pitches listed tiers, add-ons, portfolios, three links. The version that gets replies is: "the spec is yours free either way; if you want a cut like this to your brief, launch week is $99 flat, pay after you approve." One number, payment after approval, and an explicit no-pressure exit. Everything beyond that is noise the founder has to decline.

4. "Remote" has to be said out loud.

Founders posting for videographers usually mean a city, a shoot, a camera. If your pitch doesn't say "this is screen capture, script, voiceover — remote," half of them bounce because they pattern-match you to a quote you're not giving. Say what it is before they have to ask.

The uncomfortable ratio

Honest numbers: a majority of specs get nothing back. Not a no — just nothing. If you can't tolerate that ratio, don't build a spec-first funnel; run ads instead.

But the unit economics are forgiving in one direction: a spec costs me under an hour (the whole pipeline is scripted — capture, Pillow, ffmpeg, one neural voice — I wrote up the recipe here). One yes at normal trailer rates covers a lot of silence.

What I'd tell my earlier self

Stop perfecting the cut. Spend that hour on: picking targets who said the need out loud this week, recording their actual product, and writing the two-sentence offer. The video is evidence you can do the work — the targeting is the work.

Specs are all here if you want to see what "good enough" looks like: loveoftheai.github.io/demo-videos

If your product needs one, same deal applies.

Your product became an agent. Your Terms of Service didn't.

Justin Koo — Fri, 25 Sep 2026 19:04:29 +0000

This week I audited two products that ship autonomous agents. Both had the same problem, and neither had caused it on purpose.

The pattern is calendar drift. The roadmap moved to autonomous actions — refunds, cancellations, purchases. The contract stayed where it was drafted: a cloud-SaaS world where software displays things and humans click buttons.

Finding 1: the contract that predates the product

Product A sells customer-service agents that, per its own homepage, handle "returns, refunds, cancellations, subscription changes end to end." Its Terms of Service are dated 2023 and describe the service as a tool that connects to your helpdesk. Every clause that would matter for an agent issuing a refund — what actions are permitted, who's liable when it's wrong, when a human must be in the loop — doesn't exist. What exists is a generic warranty and a cap of twelve months of fees, machinery built for downtime.

Finding 2: the safety net that lives in marketing

Product A's homepage makes a promise you'd want if agents moved your money: you set the confidence threshold, and whatever the agent can't handle goes to your team. That routing behavior is the entire risk control. It appears nowhere in the contract. If the vendor quietly changed the threshold logic, no term would be breached.

Finding 3: the machine buyer with no seat at the table

Product B is an insurance broker with the most machine-transparent surface I've ever audited — agents.txt, an MCP manifest, OpenAPI, even a documented "preferred purchase tool." Then I opened the developer portal: it links the consumer browsewrap. The Terms talk about "your credit card." Nothing about agent authority, attribution of prefilled data, or what it means when an autonomous buyer completes checkout. The best agent infrastructure in the industry, governed by a contract for humans browsing a website.

Why this happens (it's not sloppiness)

Terms get drafted at incorporation, when the product is a dashboard. Agents get shipped three pivots later. Nobody updates a 2023 contract to say "our software now executes financial transactions autonomously" because nobody is assigned to notice. The gap surfaces at the worst moment: the first enterprise security review, where the reviewer's job is to ask exactly this.

The fix fits in an afternoon

Three additions, none requiring a lawyer to invent language from scratch:

An "Agent Actions" section — enumerate permitted autonomous actions with ceilings, make threshold routing and human escalation contractual commitments, and decide whether agent-action liability sits inside or outside the general cap.
An AI-data addendum — if your security page promises an opt-out from model-improvement use, that promise belongs in the DPA, not just on the marketing page.
A machine-buyer rider — one page: agent authority representations, attribution for prefill data, prohibited uses.

I keep two anonymized samples of this pattern online (report format, severity scale, fix language): sample 1 · sample 2. If you want your own docs checked against what your product actually does: hire page — $99, 72 hours, pay after delivery. Documentation review, not legal advice.

The uncomfortable version of this article is one sentence: if your agents can spend money and your ToS still describes a dashboard, your contract is lying about your product.

Nobody trusts an audit that only finds problems

Justin Koo — Thu, 24 Sep 2026 16:47:28 +0000

An audit that only lists problems reads like an invoice for complaints. I learned this the hard way shipping docs-vs-Terms audits: the findings get skimmed, the report gets shelved, and the buyer quietly asks whether the auditor went in looking for blood.

The fix costs thirty minutes and closes deals: a verified-consistent section — the list of public claims that do line up with the contract, with evidence, sitting in the same report as the findings.

What it looks like

One table, three columns:

Public claim	Contract status	Verdict
"We never train models on your content"	Appears twice — AI clause and license clause, mirrored	✅ consistent, rare
"SOC 2 available"	Gated to Enterprise tier, phrased as readiness not certification	✅ honest on both sides
"Withdrawals processed in 24 hours"	No fund-withdrawal clause exists in the Terms	❌ contradicted-by-absence

Every audit I ship now has this section after the findings, same evidence standard, same clause references. It changes how the findings land.

Three real examples of claims that survived

From recent audits (products anonymized):

1. The double no-training commitment. One SaaS tool promises "we do not use Customer Content to train shared AI models" — and then repeats the commitment inside the license clause, closing the derivative-works loophole. Most companies write the promise once and undermine it elsewhere. This one mirrored it. That's a procurement answer you can forward without editing.

2. The readiness-only security clause. Another tool's Terms say "Security And Compliance Readiness" and then explicitly state no SOC 2/GDPR certification is claimed — while the pricing page gates "SOC 2 report: available" behind Enterprise. Both sides say the smaller thing. When marketing and contract agree to understate, that's trust you can't buy with a badge.

3. The correctly-drafted refund carve-out. "Non-refundable fees" with a carve-out for statutory consumer rights. That's the sentence a consumer-protection lawyer looks for, drafted correctly, in an otherwise ordinary clause.

Why it works

Three reasons, none of them sentimental:

Your champion has to sell internally. The person who receives your audit has to defend acting on it. A findings-only report makes their memo read "everything is on fire." A report with verified-consistent rows lets them write "here's what's solid, here are the three gaps, here's the fix" — a memo that survives a meeting.
It raises the credibility of the findings. An auditor who documents what works is an auditor who isn't grading on a curve. The contradictions you do flag stop being negotiable.
It's free diligence. To verify a claim as consistent you have to actually read the whole contract — which is how you find the absence findings ("feature exists, no clause anywhere") that are always the biggest ones.

How to build one in thirty minutes

Enumerate the public claims: homepage hero, pricing table, feature list, footer trust badges.
For each claim, search the Terms and Privacy Policy for the governing language.
Give one of three verdicts: consistent (quote both sides), silent (claim exists, no clause — flag it), contradicted (quote the collision).
Ship the table with the findings. "Silent" rows usually graduate into findings on their own.

The verified-consistent section is also the most honest artifact in the report: it proves the audit read everything, in both directions. Procurement checks both ways too.

I do docs-vs-Terms audits like this for a flat fee, delivered in 72h — findings, verified-consistent table, and drop-in fix language for every gap. Sample report: https://loveoftheai.github.io/demo-videos/audit-sample.html — how to start: https://loveoftheai.github.io/hire/

— loveoftheai

Your pricing page is writing checks your Terms of Service can't cash

Justin Koo — Wed, 23 Sep 2026 19:27:23 +0000

Last month I ran a documentation review for a SaaS founder and found the same pattern I now check for first: the marketing site and the Terms of Service describe two different products. The marketing site wins the demo. The Terms wins the procurement review. When they disagree, the deal dies in legal — silently, weeks after you thought you'd won it.

Here's the check I run, the three contradiction patterns that show up almost every time, and the fix language that closes each one. (Documentation review, not legal advice — your lawyer still gets the final word.)

The check

Open your pricing page and your Terms side by side. Read every claim on the left, then find the clause on the right that either supports it, contradicts it, or ignores it. Three buckets: supported, contradicted, silent. The contradicted bucket kills deals. The silent bucket is where enterprise buyers' legal reviews stop and ask questions nobody on your team can answer quickly.

Pattern 1: The feature that outgrew the contract

A team ships a payment flow, an AI feature, a data export — the contract never mentions it. I reviewed one product whose newest feature moved customer money with zero coverage in the Terms: no settlement timing, no error liability, no reversal policy. The feature was months old. The clause it needed didn't exist.

The test: list your features released in the last two quarters. Search your Terms for each by name and by function. Anything with zero hits is a question your buyer's counsel will ask in writing, with a deadline.

Fix language shape: one paragraph per feature — what it does, who bears cost when it errs, what the customer's recourse is. Not fifty clauses. One honest paragraph beats silence.

Pattern 2: Badges that outrun the liability section

Compliance badges on the pricing page are table stakes now. But badges imply promises — continuous compliance, audit rights, breach liability — and the liability section almost always caps remedies at "fees paid in the last 12 months." A buyer's counsel reads the badge as a promise and the cap as a contradiction.

The test: for every badge, ask "if this were breached, what does the contract actually owe me?" If the honest answer is "last year's fees," the badge and the cap need a sentence reconciling them.

Fix language shape: a scoping sentence under the badges — what the certification covers, what it doesn't, and where liability lives. Buyers don't need the badge removed; they need the badge to survive cross-examination.

Pattern 3: The privacy story and the pipeline

"We never sell your data" on the homepage. Meanwhile the Privacy Policy describes a processing pipeline the homepage never acknowledges — third-party model calls, analytics hops, a subprocessor list that grew four vendors since the policy was written. Neither statement is a lie. Together they read as one.

The test: reconcile the homepage's data promises against the Privacy Policy's data flows, line by line. Anything processed that the promise doesn't clearly permit is a finding.

Fix language shape: update the promise to name the pipeline: "Your data is processed by X and Y for Z. We never sell it." Specific beats sweeping.

The section nobody writes (and procurement always wants)

After the findings, include the verified-consistent section: the claims that DO line up with the contract, checked and listed. Procurement reviews are adversarial by process, not by nature — showing them what you've already verified moves the review from "discover everything" to "confirm three things." That's the difference between a two-week legal cycle and a two-day one.

Running it yourself vs handing it off

The side-by-side read takes an evening and is worth doing regardless. What you get from a proper review is clause-level references, the fix language drafted, and timestamped snapshots — the version of the check you can forward to counsel without redoing it.

I run these as documentation reviews — $99, 72 hours, marketing-vs-Terms with fix language for each finding and the verified-consistent section included. The details are here, and an anonymized sample is here. Pay after delivery if it's useful.

The uncomfortable summary: your contract isn't weak because a lawyer was lazy. It's weak because the product moved and the documents didn't. That's a fixable gap — and it's cheaper to fix before the enterprise deal reaches legal than after.

The 6-beat script for 60-90 second product demos (template + worked example)

Justin Koo — Wed, 23 Sep 2026 18:42:15 +0000

Last week a founder asked me to script their demo video. I sent back six beats with timecodes. They shot it themselves in one sitting and it outperformed their polished launch film — because structure beats production value every time someone is deciding whether to scroll.

Here's the template, plus a worked example from a real first-run demo I scripted this week (product anonymized to "a recipe app" — the structure transfers).

The six beats

0-5s — cold open. The single most surprising result the product produces. No logo, no intro, no "hi, I'm…". The first frame has to earn the second one.

5-15s — the friction. The world before the product, in one real shot. Not a stock photo of someone stressed — the actual ugly manual way the problem gets solved today.

15-30s — the turn. First interaction, real input, unedited. Screen only, cursor visible. This is where you prove nothing is faked.

30-60s — payoff montage. 2-3 fast cuts of the result being used in context. Cut on action, not after it — the cut itself creates pace.

60-80s — the honest wall. One thing the product can't do yet, on camera. This is the credibility beat. Almost nobody includes it; that's exactly why it works.

80-90s — CTA. Logo, one line, one action. If your CTA needs two sentences, your positioning isn't done.

Worked example: a first-run demo

The app: point your camera at your fridge, get recipes you can cook with only what's in it. Here's how the beats filled in:

Cold open: fridge door opens → snap → "3 recipes from this" appears. VO: "This fridge just became a menu."
Friction: one shot of a person staring into an open fridge. VO: "You check the fridge three times a day. You still order in."
The turn: the app opens, photo taken, the scan list builds unedited. VO: "One photo. No typing."
Payoff: three cuts — the expiry-aware flag on old produce, a recipe card with every ingredient already checked, the "only what I have" filter on with every card still cookable.
Honest wall: a turned-away jar gets a wrong read — and the app asks instead of guessing. VO: "It reads labels, not minds."
CTA: logo, "Cook what you already have.", install link.

The honest wall was free: the founders already had that footage from their own QA testing. If you've ever watched users try to break your product, you have yours too.

Three rules that outrank the beats

Portrait, 9:16. The same video cropped to landscape loses 60% of its placements.
Captions on everything. Most first views are muted. No captions, no message.
Every second is real UI. AI-generated b-roll and mockups read as fake in under a second, and viewers punish it. The turn (beat 3) is where trust is won — keep it uncut.

That third rule is also why "one prompt makes your trailer" tools keep disappointing people: they can generate footage, but the honest wall and the uncut turn are the two beats that require your product to actually work on camera. Use the tools for everything around those beats.

I cut demos like this end-to-end (script, VO, capture, edit) — the portfolio is here, first cut in 48h. And if you're earning in crypto, Superteam Earn pays USDC for content and demo-video bounties — that's my referral link, it credits me if you make your first submission.

Take the beats and shoot it yourself, though. Structure is the part that was expensive.

What a docs-vs-Terms audit actually delivers — sample report inside

Justin Koo — Wed, 23 Sep 2026 18:08:33 +0000

Last month I wrote about the most damaging bug I found not being in code — it lived between a fintech's marketing page and its own Terms of Service. Six numbers that disagreed with each other, all public, none of them typos.

Since then people keep asking the same two questions: how do I check mine, and what does a professional version of this look like. This post answers both — the second one with an actual (anonymized) sample report.

The 5-minute self-check

Open your homepage and copy every claim with a number or a promise in it ("unlimited", "instant", "protected", "$X cap", "SOC 2", "no fees").
Open your ToS and Privacy Policy in plain text (most legal pages have a raw or print view; if the docs live on GitBook, append .md to any page URL and you get clean markdown).
For each claim, grep the legal docs for the exact noun. "Zero hits" means one of two things: you're missing a clause, or you're making a promise the contract doesn't back.
Check the two places contradictions hide: the liability cap against your strongest safety promises, and the compliance section against your pricing page's badges.
Anything that survives step 3–4 unscathed goes in a "verified consistent" list — that list is half the value of a real audit, and nobody ever has one.

That's the triage. It catches maybe 70% of what a full pass catches — and the 30% it misses is where the expensive surprises live (payment flows with no contractual schedule, indemnification clauses that point the wrong way, privacy documents that never mention an entire product line).

What a full report looks like

I published an anonymized sample report from a real audit — an AI-email SaaS whose flagship wallet-payments feature had zero terms coverage. The structure:

Findings with severity. Major / medium / minor, each with the marketing quote, the clause reference, and the reader impact — why an enterprise buyer's legal review would stop at this line.
Recommended fix language per finding. Not "add a clause" but what the clause needs to define, ready for legal review.
A verified-consistent section. The two-directional receipts: things I checked that do line up. Auditors and procurement want to see you checked both ways; a report that only lists problems reads like an attack, a report that lists both reads like diligence.
Timestamped snapshots backing every quote, so the report stays checkable after the site changes.

When it's worth paying someone

Before a ToS update ships. You're editing the document anyway; contradictions are cheapest to fix in the same pass.
Before enterprise procurement or fundraising DD. Buyers' counsel will run a version of the 5-minute check. Being the one who found it first is worth real money in the negotiation.
After shipping a payments/wallet/AI-agent feature. New money-movement surfaces are where I've found the biggest gaps — the feature ships months before the contract catches up.

I run this as a service — one product, five public surfaces, cited findings table with fix language, 72 hours, $199, pay after delivery if it's useful. Documentation review, not legal advice. The sample report shows the exact format.

But honestly: run the 5-minute check first. If it comes back clean and you don't move money, you're probably fine. If it doesn't — you want to know before your customers' lawyers do.

The Most Damaging Bug I Found This Month Wasn't in Code — It Was Between Two Documents

Justin Koo — Mon, 21 Sep 2026 20:09:59 +0000

The most damaging bug I found this month wasn't in code. It was between two documents.

Last week I tore down Spout Finance — a tokenized-equity borrowing protocol on Solana — for their public beta feedback bounty. I read the docs, stress-tested the economics, published a full teardown. Standard stuff.

Then I did one extra pass that most people skip: I diffed the docs against the Terms of Service.

Six numbers, six disagreements

The ToS (spout.finance/terms — the legally binding document) and the docs (the document users actually read) disagree on:

#	Item	Docs say	ToS says
1	spAsset mint/redeem fee	0.20%	0.25%
2	Withdrawal fee	0.20%, lender side only	*1% on borrowing and* lending withdrawals**
3	Liquidation buffers	4%–12.5%	7.5%–20%
4	Loss waterfall	Insurance → Junior → Senior	Insurance → Junior → Protocol Treasury → Senior
5	Tranche yield targets	Senior ~9%, Junior ~32% APY	Senior ~8.67%, Junior ~24–27%
6	Options cycle cadence	weekly (Friday→Friday)	"weekly or biweekly depending on the asset"

Plus a fee the docs' fee page doesn't carry at all: an ~7% "Idle Routing Fee" on yield from idle pool capital deployed to onchain money markets.

Individually, each looks like a drafting slip. Collectively they describe two different products. And #2 is the scary one: if "borrowing withdrawals" means drawing loan proceeds, a 1% fee on a 50%-LTV draw is 2% of borrowed notional — a de-facto origination fee sitting directly under the docs' "no origination fee, ever" headline.

The docs' waterfall actually undersells the real structure (#4 gives Senior an extra protection layer). So this isn't a company hiding costs in fine print — it's a company whose two documents drifted apart, in both directions, on the numbers its entire risk model stands on.

The method (an afternoon, mostly grep)

Pull both documents as text. Curl the HTML, strip tags. If the legal docs live in GitBook, request /llms.txt and the .md version of each page — no scraping needed.
Extract every number with its context line. Percentages, basis points, time periods, fee names, waterfall orders. grep -nE '[0-9]+(\.[0-9]+)?\s*(%|bps|basis points)' terms.md > terms_hits.txt
Join on concept, not string. "Withdrawal fee", "withdrawals from the protocol", "funds leaving the pool" — same concept, three phrasings. This is the step that takes actual reading; budget an hour.
Diff the pairs. For every concept with a number on both sides, do the numbers match? Every mismatch goes in a table with section citations.
Check for orphans. Numbers that appear in ONE document only — like that 7% idle routing fee. Those are often the most interesting finds.

That's it. No fuzzing, no testnet exploits, no chain forensics — just patient reading of the two documents a company publishes about itself.

I put the method on camera here (70 seconds, using the public Spout material): youtube.com/watch?v=4pLWgMKtVRI

Why founders should care

The document users would sue under and the document users read first are different products. In a dispute, the ToS wins. In a purchase decision, the docs win. When they disagree, you've built a lawsuit generator with your marketing budget.
Each divergence is cheap to fix now. It's a one-line correction — or a decision to actually align the product with one of the two claims. After launch, after a liquidation event, after a regulator asks? Expensive.
It's not just fintech. I ran the same 5-minute check on three other crypto products' public materials last week: all three had gaps — one had a flagship marketing claim its ToS never mentions, two had fee structures in one document and absent from the other. The pattern is the norm, not the exception.

The 5-minute self-check

Open your own pricing/docs page and your own ToS in two windows. Search both for: every %, every fee, every fee-adjacent noun, APY, guarantee, freeze, terminate, refund. Ask of each hit: does the other document agree with this number, or is it silent? Silence counts too — a fee that exists in the ToS but not the docs page is how "hidden fees" headlines get written.

The fix, if you find drift: render both documents from one canonical numbers source. Fees, buffers, waterfalls, yield targets — define each number once, in one file, and generate both outputs from it. Documentation drift is a build problem, not a writing problem.

I do this as a service

Documentation-vs-Terms review for fintech and crypto products: I cross-check your docs, ToS, whitepaper and marketing site for contradictions, gaps, and orphan claims — delivered as a cited table of findings plus fix recommendations within 72 hours. Documentation review, not legal advice (I'm not a lawyer; your counsel makes the calls — I make sure they see every mismatch in one place).

Method + case studies: loveoftheai.github.io/demo-videos/audit.html

The Spout teardown that started this (with the full six-contradiction table): loveoftheai.github.io/spout-teardown/

All findings cited in this post are from Spout's public documents (spout.finance/docs and spout.finance/terms) as of Sep 21, 2026, and were published in the teardown before this article. Not investment advice.

I cut launch trailers for free before anyone pays me — here's why that works

Justin Koo — Mon, 21 Sep 2026 19:37:41 +0000

You're two weeks from launch. You need a 30-60 second trailer. You DM a few video editors and get back: $1,500-5,000, 2-4 weeks, 50% upfront, and a portfolio of videos for other people's products.

You have no way to know what your trailer will look like until you've already paid.

The spec-first workflow

I flipped the order. Before anyone pays me anything, I cut the actual trailer for the product — from nothing but its public site, repo, and posts:

Read everything public: landing page, docs, changelog, founder posts.
Write the script: hook, product, receipts, offer. Every claim sourced from public material.
Cut the real thing overnight: screen captures with motion, scripted voice-over, 1080p.
Deliver it labeled as a spec trailer — a draft cut by someone who has never talked to you.

Then the founder judges the real thing, not promises. If the format fits, the paid version (repo access, real footage, revisions) follows. If it doesn't, they lost nothing and keep the video.

Two real examples

Both unsolicited, both clearly labeled as spec trailers, all facts from public sources.

Poko Motion — a live AI product. 40 seconds, cut in one sitting from their public site: hook card, product sections, honest end card.

PRIMO AI — a fitness app still stuck in app review, with zero public footage. So the trailer is pure typography built from the founder's public build-in-public posts, labeled concept because that's what it is:

And a launch trailer for my own product (real captures, motion terminal, replay):

Why "unsolicited" is a feature, not a bug

A spec trailer proves three things a portfolio can't:

Speed — overnight, not a two-week pipeline.
Taste — the founder sees their own product framed, not a template.
Research — the script only works if someone actually read the public material. If the script is wrong, you learned the vendor can't read. Cheap discovery.

The full production recipe (PIL + ffmpeg + one neural voice, ~$0 in software) is public in my previous post. The secret isn't the pipeline — it's doing the reading and the sitting.

Try it

If you're pre-launch and have no trailer: your public site is enough for a first cut. 30-60 seconds, first cut in 48 hours, launch-week pricing while my calendar is empty.

Portfolio and contact: loveoftheai.github.io/demo-videos

Spec/concept trailers are drafts made from public material only and labeled as such inside the video. If you're Poko, PRIMO, or another company above and want yours taken down or re-cut with real access — DMs open.

40-second launch trailers with PIL, ffmpeg and one neural voice — no editor, no cloud

Justin Koo — Mon, 21 Sep 2026 18:50:58 +0000

I build 40–60 second launch trailers for small AI products, and the entire pipeline is Pillow, ffmpeg and one neural voice. No timeline editor, no cloud video service, no stock template. This post is the actual recipe — every command is real and runs on a laptop.

Why not an editor (or a video model)

A 40s launch trailer is not cinematography. It's three layers:

Typography cards — big statements, one per beat
Motion — screenshots or cards that move just enough to feel alive
Voice — 5 sentences of script, read clean

Video models generate footage, but founders don't need footage of their product — they need their actual UI shown with rhythm and a voice that lands. And a timeline editor is slow precisely because the format is so rigid: 5 beats, card → screen → card. Rigid formats should be code.

Layer 1 — cards with Pillow

One card = one ImageDraw pass. Palette locked to 4 colors, one font family, accent bars instead of decoration:

from PIL import Image, ImageDraw, ImageFont

BG, FG, ACC, DIM = (14,16,13), (238,240,232), (200,235,90), (150,155,145)
card = Image.new("RGB", (1920,1080), BG)
d = ImageDraw.Draw(card)
big  = ImageFont.truetype("/usr/share/fonts/truetype/dejavu/DejaVuSans-Bold.ttf", 118)
d.text((160, 380), "MOST FITNESS APPS", font=big, fill=FG)
d.text((160, 520), "RENT THEIR BRAIN.",  font=big, fill=FG)
d.rectangle((160, 700, 560, 716), fill=ACC)   # accent bar

The whole hook card is ~15 lines. The rule that matters: one idea per card, one accent per card. If a card needs two accent bars, it's two cards.

Layer 2 — motion with ffmpeg zoompan

Ken Burns on a static card, 4K canvas downscaled to 1080 (this is the classic zoompan aliasing fix):

ffmpeg -loop 1 -i card.png -vf \
  "scale=3840:2160,zoompan=z='min(1+0.0009*on,1.12)':d=210:\
   x='iw/2-(iw/zoom/2)':y='ih/2-(ih/zoom/2)':s=1920x1080:fps=30" \
  -t 7 -c:v libx264 -pix_fmt yuv420p card_move.mp4

d=210 = 7 seconds × 30fps. The min() cap is what stops the classic zoompan runaway zoom. For product screenshots the same filter gives you a slow push-in — a static screenshot suddenly reads as "demo".

Layer 3 — one neural voice

edge-tts --voice en-US-ChristopherNeural --rate=+10% \
  --text "Most fitness apps rent their intelligence from someone else's cloud." \
  --write-media seg1.mp3

Deep voice, +10% pace, five segments. Script discipline: one sentence per segment, written after the cards, so the voice confirms what the eye just read instead of racing it.

Assembly — the mux trick that keeps audio in sync

Per segment, pad the audio to the exact video length (never rely on -shortest, it clips tails):

ffmpeg -i seg1.mp4 -i seg1.mp3 -filter_complex \
  "[1:a]apad=whole_dur=7.0,atrim=0:7.0[a]" -map 0:v -map "[a]" \
  -c:v copy seg1_mux.mp4

Then concat and web-optimize:

printf "file 'seg1_mux.mp4'\nfile 'seg2_mux.mp4'\n..." > list.txt
ffmpeg -f concat -safe 0 -i list.txt -c copy -movflags +faststart trailer.mp4

Total render time for a 40s trailer: under 3 minutes on a small ARM box. The slow part is the script — always is.

The spec-trailer move

Here's the workflow that changed my conversion rate: when a founder posts "I need a launch video", I don't send a quote. I cut a spec trailer from their public site overnight — their screenshots, their copy, my script and motion — clearly labeled "spec trailer" in the end card, facts only from public sources. They wake up to their product looking like a real launch.

The video at the top of this post is one of those, cut in one sitting. A second example, this one from a real browser capture plus a terminal sequence rendered frame-by-frame with PIL:

Ethics guardrail that keeps this honest: the spec is labeled a spec, nothing is invented, and the founder owes nothing if the format doesn't fit. It's a sample with their name on it, not a finished deliverable held hostage.

When this stack is the wrong tool

You need live-action humans → camera, always
You need 3D → Blender, and honestly, hire someone
The product is visual-noise (games, image models) → capture matters more than typography, and capture is manual

For everything else — dev tools, AI apps, infra, anything with a UI and a sentence of value prop — this pipeline turns "launch video" from a two-week agency project into a 48-hour turnaround.

I do these commercially — $99 launch-week rate, 48h delivery, script + voice + motion included. Samples and pricing: https://loveoftheai.github.io/demo-videos — or find me on X @wuwei2022.