When we started building Axiom Lab — a service that turns a founder's deck, PDFs and a short AI-host interview into a pitch video or a "Founder Card" introduction film — we decided to go the other way. A customer is charged once per delivered film that passes our QA. If a job fails QA, or fails on our side, it is free and the hold on their balance is released in full.

This post is about what that decision forced us to build. It turned out to be less a billing feature and more an architecture constraint.

Why credits felt wrong for this use case

Credits work well when users are exploring: generating twenty images to pick one is the point. Founders making a pitch video are not exploring. They want one film that explains what they do, the problem they solve and the next step they're asking for. They're often doing it the night before a meeting.

In that context, credit-burn pricing transfers all generation risk to the least-equipped party. The founder doesn't know why a render drifted off-script or why the voice mispronounced the product name. They just see their balance going down.

So the question became: if we absorb the cost of failed attempts, what has to be true about the system so that we don't go broke?

Three things, it turns out:

1. Failures must be caught before delivery, automatically, and cheaply.
2. The number of attempts per film must be bounded by design, not by hope.
3. The customer must agree to the inputs before we spend money on outputs.

Constraint 1: Freeze the plan before you render anything

The most expensive failure in AI video is not a glitchy frame. It's a technically perfect film of the wrong story. Re-rendering because the founder "actually meant something else" is a cost we can't charge for under pay-on-delivery, so we push all ambiguity to the front.

For Founder Cards, that means the AI host interview produces a script, and the founder reviews and approves the script, appearance and voice before production is confirmed. For project videos, the brief (deck, plan, PDFs, photos) is turned into a structured plan first, and plans are free: production only starts once the customer confirms the plan.

In practice the plan is a small, boring data object: beats, each with a purpose (pain, solution, advantage, call to action), the claims it makes, and which source material supports each claim. Boring is good. Once that object is frozen, everything downstream is a deterministic function of it — which means we can re-run a failed step without asking the customer anything.

brief / interview ──► structured plan ──► customer approves ──► FROZEN
                                                              │
                         render ◄── retry (our cost) ◄── QA ◄─┘
                           │
                           └──► QA pass ──► deliver ──► charge once

The practical lesson: approval gates are a cost-control mechanism, not just a UX nicety. Every decision the customer makes before render is a re-render we never have to eat.

Constraint 2: QA has to be a machine, not a mood

If charging is conditional on passing QA, QA can't be "someone watches it and it seems fine." It needs to be checkable, logged and consistent, because it's literally the trigger for a financial event.

We think about checks in three layers:

• Fidelity checks — does the narration match the approved script? Are names, product terms and numbers spoken and captioned the way the plan says? Did any claim appear that isn't backed by the source material?
• Technical checks — duration within the agreed range, audio levels, no silent gaps, subtitles in sync, correct aspect ratio and format.
• Structural checks — are all planned beats present, in order, and is the final call to action there?

Some of these are cheap deterministic checks; others need a model or a person in the loop. Whatever the mix, each check should produce a logged pass/fail with a reason, because that record is what justifies a charge, or the absence of one.

The important design property: a QA failure maps to a specific step to retry. "Subtitle drift" re-runs captioning, not the whole film. That keeps the cost of absorbing failures roughly proportional to how much actually went wrong.

Constraint 3: Holds, not charges

The billing model looks like a payment-processor pattern borrowed into a media pipeline. Customers keep a prepaid balance. Starting a job places a hold. A QA-passed delivery converts that hold into a charge; a failed job releases it. The balance and statement are always visible in the customer's account.

This sounds trivial, but it has a useful side effect: every job has an unambiguous financial end state. A job that sits in "rendering" forever is not just a bug, it's money held from a customer, so stuck-job alerts stop being a nice-to-have. The same logic covers jobs waiting on the customer: in our case, a job that waits on customer input for 7 days expires and its hold goes back to the balance.

Implementation notes worth getting right early:

• Make job state transitions idempotent. Webhooks and workers retry; a duplicate "delivered" event must never charge twice.
• Store the plan version on the job. If a customer edits and re-approves, that's a new job, not a mutation of the old one.
• Record why a job failed QA. It's your best roadmap input: the top failure reason is almost always the next thing to fix upstream.

What the AI host interview is really for

People assume the interview exists because it's a fun demo. It's actually there to improve input quality, which is the cheapest lever we have on QA pass rate.

Founders are bad at writing about themselves and good at answering questions. A blank script box gets you "We are a passionate team leveraging AI to disrupt…". A host asking "Who was the first customer, and what changed for them?" gets you a sentence you can actually put in a film. The Founder Card structure is deliberately small — identity, service value, experience and proof, contact — so the interview has a clear finish line.

Better inputs mean fewer plan revisions, fewer fidelity failures, and fewer retries we pay for. The interview is a QA feature that happens to look like onboarding.

Trade-offs we accepted

Pay-on-delivery isn't free lunch. Honest list:

• We can't publish a simple unit price yet. Cost depends heavily on video type, length, formats, materials and voice, so pricing is quoted individually. That adds friction for self-serve buyers, and we know it.
• We're slower to say "yes" to edge cases. If a request doesn't fit a workflow we can QA reliably, we'd rather not take it than deliver something we can't stand behind.
• Invite-only beta. Bounding the number of customers is part of bounding our failure costs while the checks mature.
• Unit economics depend on pass rate. Each film has a fixed price that doesn't change with how many attempts it took, so every retry comes out of our margin. That is exactly the pressure we wanted, but it means QA and input quality have to keep improving.

If you're building something similar

A short checklist from our experience:

1. Put a human approval step on the cheapest artifact (script/plan), never on the most expensive one (the render).
2. Make the plan a versioned, frozen data object. Everything downstream should be reproducible from it.
3. Write QA checks that map to retryable steps, and log every failure reason.
4. Model billing as holds and captures, with idempotent transitions.
5. Treat "stuck" as a financial incident, not a cosmetic one.

You don't need a pay-on-delivery model to benefit from these — they make any generative pipeline more predictable. But if you do want to stand behind your output, they're the minimum.

If you're curious how this looks from the customer side, the Founder Card and project video workflows (plus a full demo) are on axiomlab.online. And if you've solved generation-risk pricing differently, I'd genuinely like to hear how — that's still the part we're iterating on most.

— The Axiom Lab team