I deleted 9,191 lines of ad studio twelve days after writing about it, and four lines of .gitignore are all that is left

On 2026-09-26 I published two posts about a motion graphics library: Our ads are 28 React compositions, and the constraint is that any two must cut together and libvpx-vp9 writes the alpha_mode tag and throws your alpha away.

On 2026-10-08 I deleted it.

commit c485ff4
    Remove video studio and ad clip library

 44 files changed, 9191 deletions(-)

This post is the obituary, and it is more useful than it sounds, because the interesting thing is not the deletion. It is that nothing anywhere told me it had stopped being part of the product. I had to notice.

What it was

Notifio is a desktop app that watches rental listing searches. It is sold from a website, and a website that sells something needs material to put in front of people who have never heard of it. The studio was that material, built as code rather than in an editor.

A separate pnpm workspace at studio/, holding 28 Remotion compositions at 1080x1920: five opening hooks, thirteen scene clips, ten overlays meant to composite over other footage. A batch renderer that produced four deliverables per clip, because an H.264 convenience file, a ProRes 422 master, a ProRes 4444 master with alpha and a VP8 WebM with alpha are genuinely four different jobs:

/**
 * Everything renders at 2x (see SCALE): the compositions are 1080x1920, so the
 * output is 2160x3840. It is all vector/DOM, so 2x is genuinely resolved detail
 * rather than an upscale.
 */
const SCALE = "--scale=2";

I still think that was a good way to build ads. Every number in them came from the same tokens file, so a price change was one edit rather than a re-export, and a diff of a clip was readable.

The timeline is the whole story

2026-07-28  studio/ added
2026-08-06  "updated clips"           <- last substantive change
2026-09-26  two blog posts about it
2026-10-08  deleted, 44 files

Look at the gap in the middle. The last change to the code was 6 August. The posts were written on 26 September. I wrote just under 3,000 words about a subsystem that had not been touched in 51 days, and I did not notice while writing them, because writing about code does not require the code to be alive. It compiled. It rendered. Every claim in those posts was true.

Then it sat for another twelve days and I deleted it.

Why it was deletable in one commit

Because it was an island, in four separate ways:

1. No inbound imports. Nothing in app/ or server/ imported anything from studio/. A search across both for the word is clean apart from the English noun, as in rooms and studios.
2. Its own workspace. Its own package.json, its own pnpm-workspace.yaml, its own tsconfig.json, its own .npmrc, and a pnpm-lock.yaml of 3,030 lines. It shared no dependency resolution with anything else in the repository.
3. Its output never entered the repository. Renders went to studio/out/, which was gitignored, because a 4K ProRes master is not a thing you commit.
4. Nothing in the product depended on any of it. The deliverables were for ad platforms, which is off-site by definition.

So git rm -r studio/ and the repository is consistent. No build breaks. No types to fix. No route to redirect. 9,191 lines, one commit, and pnpm build in both remaining workspaces is unaffected.

That is the cleanest deletion I have ever done, and it is exactly the problem.

Isolation cuts both ways

The four properties that made it safe to remove are the same four that let it stop mattering without anyone noticing.

A module with inbound imports announces its own death. Delete it and the build fails; stop maintaining it and a type error eventually arrives; change the thing it depends on and a test goes red. The coupling you spend effort avoiding is also the mechanism that tells you something is still wired in.

studio/ had none of that. It had no failure mode. A renderer that nobody runs produces no error, and a workspace that nothing imports cannot break. Its state was indistinguishable from the outside: "working perfectly and used daily" and "dead since August" look identical in git status.

The signal I wanted was not "does it compile". It was "has anything consumed its output since the last change", and the repository could not answer that, because the output was gitignored on purpose and for good reason.

This generalises past video. Anything that generates artefacts outside the repository has the same hole: report generators, data exports, OG image pipelines, design token exporters, scraper fixtures, migration scripts kept "in case". If the consumer of a thing is outside your version control, your version control cannot tell you the thing is dead.

The cheap fix, which I will use next time, is to commit a manifest rather than the artefacts. Not the 4K master, just a small file listing what was produced and when. That turns "is anything using this" into a one-line git log on a file that is cheap to keep, and it would have put the answer in front of me in July.

What replaced it, and what that says

The website still needs to show what the app does. It does it with React components rendered live in the page, which I wrote about the day after the deletion in Four product demos on our home page, not one of them a video, and every loop has to be able to cancel itself. You can watch them on the home page, and the per-site pages carry the same idea in static form: the Kamernet page and the rest of the catalogue.

The difference that matters is not video against DOM. It is that those demos are in the shipping bundle. They break if the colour tokens change. They are on a page that a test asserts is reachable. They are coupled to the product, so the product tells me when they rot.

I am not claiming the studio was a mistake. I am claiming that if I build another one, it needs a thread back into something that fails.

The residue

A deletion this clean still leaves a scar, and in this case it is four lines:

studio/out/
studio/.remotion/

Those two paths, each with a comment line above it, are still in the current .gitignore. The first comment calls them large binaries and tells a future reader to regenerate them with pnpm render:all. The second calls the other one a Remotion bundle and browser cache. A script that does not exist, in a workspace that does not exist, described in the present tense. It is a tiny thing and it is the same failure as the one in Our README tells you to make a Gmail app password, and nothing in the app has read one for months: a document that outlived its subject, with nothing to make the contradiction visible.

Those four lines are going in the same commit as the README fixes.

The other residue cannot be deleted. The two posts up top describe, in detail, code that no longer exists anywhere except in git show c485ff4^. They are now the only surviving documentation of a thing I deleted, which is a strange position for a blog post to end up in, and a decent argument for writing them.

What transfers

1. A subsystem with no inbound references has no failure mode, and no failure mode means no signal.
2. If the artefacts are too big to commit, commit a manifest of them. The question you will want answered later is "when was this last used", not "what did it produce".
3. Separate workspaces are excellent for isolating dependencies and excellent at hiding abandonment. Both, at the same time, for the same reason.
4. When you write about a subsystem, check the date of its last commit first. It takes five seconds and I did not do it.