In development

Brief in.Video out.

Describe what you want. It writes the script, plans the scenes, renders the cut, and publishes to your own channel — never without your approval.

Scroll
The surface

One project, carried from a sentence to a published video — and stopped at every gate you set.

video / Q3 product explainer Interface preview
✓Idea
✓Script · v3
✓Template
✓Plan · 9 nodes
Render
Approve
Publish
Scenes · 1080×1920 · 30fps
Render · node 6 of 962%
Budget reserved before the paid call₹41 of ₹120
Cache reuse from the last run4 of 9 nodes
Waiting for you to approve this render for  @yourchannel WatchApprove & publish

A preview of the working surface. The product is in development.

How it works
  1. Bring what you already have

    Point it at your own sources and it keeps a normalised corpus of them, so ideas come from your material rather than from nothing.

  2. Write the brief, keep the script

    A sentence or a page becomes a script you can edit. Every version is kept, and one script version can feed many independent videos without them affecting each other.

  3. Compile a plan, not a prompt

    A template compiles into one explicit plan and the graph of work behind it. The same template and inputs compile to the same plan every time, so a video is reproducible rather than a lucky roll.

  4. Render, with the expensive steps remembered

    Each step is checkpointed and content-addressed. Kill the machine mid-render and it resumes; change one scene and only that scene is paid for again.

  5. Approve, then publish

    Nothing reaches YouTube until you approve that render, for that channel. There is no setting that removes this step.

What is underneath

Templates, not one-off prompts

A declarative template compiles to a plan and its execution graph. Compilation is deterministic and proved byte-identical across repeated runs, so the same brief does not quietly become a different video tomorrow.

A render you can interrupt

Work runs as a durable graph with leases, fencing tokens and append-only attempts, tested against killed and restarted workers. Finished nodes are cached by content, so a retry never re-pays for work already done.

Money reserved before it is spent

A budget reservation is taken before any paid call and reconciled after, with the provenance of each charge recorded. A runaway job hits its own ceiling rather than your card.

Portrait first, and swappable

Defaults to 1080×1920 at 30fps, overridable per template. The generator behind it is configuration, not code — a strategy can be replaced without touching the pipeline that calls it.

Model output is checked before use

Structured output is validated against a frozen schema before any consumer sees it, with repair bounded to a single round. Malformed output fails loudly instead of flowing downstream as plausible nonsense.

Your tokens, encrypted and separate

YouTube authorisation is a different thing from signing in, stored encrypted under a managed key, and resolved in production only through the deployment secret boundary.

Where it actually is
01

The foundation is built and testedSign-in, workspaces, the frozen API contract, durable operations, object storage, budgets, the template compiler, the timeline renderer and the YouTube upload path all exist and run.

02

The generator in place today is a stubIt returns a fixed file. It is not part of the product and will be removed when the real capability pipeline lands. This page will say so when that changes.

03

It will not post without youApproval is per render and per channel. Signing in with Google grants no access to YouTube at all — connecting a channel is a separate step you take later, and can decline.

Elsewhere