We spent three weeks building a video factory. Today we shut it off.

The header of this blog promises that what went wrong shows up here too. So far that meant individual incidents. Today it is an entire project.

We built a machine that produces short-form video for social media and publishes it on its own. It started over the summer, and the last three weeks went into it almost entirely. Not for a client, but on two channels of our own: Fennly, a nutrition and symptom app, and klimaanlagefinden.de, a comparison site we run ourselves. Two channels where we can hurt ourselves without anyone paying for it.

This morning we turned off the scheduled runs and closed both project repositories. Not paused. Closed.

What the machine could do

So it is clear that we are not burying something that never ran. The chain was complete:

• Research pulls topics and facts from primary sources into a file, every figure with its source.
• A language model writes a script bound to that fact file. A figure without a source fails the run.
• A check reads the script against a rules file: health claims, disclosure requirements, text lengths.
• Voice, avatar, edit, subtitles. Stored in object storage.
• On the health channel every run ended with a finished video and a question in Slack asking whether it could go out. On the affiliate channel the machine published by itself, because nothing there makes a claim about anyone's health.
• Before publishing, the check ran again, because the rules may have changed since the script was written, then the post went live with a cover frame and a log entry.

All of that worked. Over 1,000 automated tests green, a daily run on one channel, a weekly one on the other. The last working days went into details: which frame the cover image sits on, whether the post also appears in the feed, whether the caption breaks the character limit.

The three assumptions that were wrong

1. That production was the bottleneck

The whole machine rests on the idea that a small business does not post because producing is too much work. Remove the work and reach appears.

But the bottleneck is not volume, it is relevance. More average content does not create reach, it dilutes it. And an avatar reading out a text is the most interchangeable format there is. Interchangeability is exactly what distribution on these platforms punishes. We automated the one part that was never the bottleneck.

2. That reach on your own channel is what someone pays for

Suppose it had worked. What we would have had is a service that produces posts and gets measured on reach. That is an agency business, and a worse one than what we otherwise do: an interchangeable supplier, justified again every month, with none of it sitting inside the client's own process and all of it on a platform that can change the rules whenever it likes.

The comparison resolves quickly once you write it down. A quoting process that goes from five days to two hours is something a client can calculate. Forty extra views per post is not.

3. That quality comes from the check

This is the expensive one, because it shaped the final weeks. All the rigour in the chain tests whether a video breaks a rule. Whether a health claim goes too far, whether the disclosure is present, whether every figure is backed.

Not one line tests whether anyone wants to watch it. Nor can that be retrofitted, because there is no rule for it. A gate can stop bad content. It cannot produce good content. We spent three weeks building the first thing while believing the second came with it.

How we could have seen it sooner

The uncomfortable part. Four of these five were settled before week three began.

The fourth is the actual mistake. It holds regardless of whether the idea was any good.

On the third point, something we had not anticipated. When a tool like Claude Code turns three weeks of work into three days, it also turns three days of drifting into thirty. The speed feels like progress the entire time. Every single day produced a clean result, a green test run, a closed task. None of them pointed outward.

What we keep

Exactly one component, and it is not the video: the check before publication.

Not the specific rules, which were built for short-form video and are disposable. The mechanism. That the rules live in a file the client owns rather than in an instruction to a language model, and that a missing rule reports itself as "not checked" instead of quietly waving things through, we have described in detail elsewhere, along with the three incidents that taught it to us. Two points come out of this project on top:

• A finding names the actual value, the limit and the gap, not just yes or no. Give someone only a no and they start working around the rule instead of fixing the text.
• Before any irreversible action the check has to pass. Not after it, not alongside it. We therefore check twice, once at writing time and once immediately before publishing, because the rules can change in between.

That transfers to anything where a machine does something you cannot take back: a quote going out, a product description going live, an email reaching a customer. Same mechanism, different field.

The video technology itself, meaning voice, avatar, editing and automated publishing with a cover frame, still works. We are not offering it as a service. We just spent three weeks establishing that we do not believe in it, and selling it because it happens to be finished would be dishonest.

The rule we gave ourselves afterwards

A failure is only paid for once it changes something. For us it is two sentences that now sit in front of every project:

• Five working days, then stop. After that someone external, meaning no project of ours and nobody in the building, has to have either paid or booked a meeting. Extensions in writing only, once.
• By hand first, then automated. A workflow only gets built once it has produced a result by hand that someone confirmed. Automation multiplies a result, it does not create one.

The second sentence would never have let this project start. We would have made thirty videos by hand, watched nothing happen, and been done after four days instead of three weeks.

What you can take from this

Three things, whether or not you ever talk to us:

• Do not automate anything that has never worked by hand. The most common expensive mistake in AI projects is not the wrong technology, it is a workflow whose value was never demonstrated and that now runs faster.
• A ban in the prompt is not a brake. On our own channel an explicit ban was ignored in four runs out of five. The full measurement, with costs and blocked runs, is in the four gates.
• Write the stop condition before the first prompt. One sentence is enough. Without it, the decision later gets made by the feeling of having already invested too much.