Should I vibe code
AI-indexed asset manager for creative teams: search footage by face, transcript, scene description, or a full sentence
Search by face is a biometric database with a nice UI. The people in that footage agreed to be filmed, not indexed.
?
Their verdict, the Growth price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
The search half is genuinely solved, and Immich is the proof: CLIP embeddings over a folder, a face-clustering pass, and "the shot of the guy in the red jacket on the pier" works by Sunday night. That demo is exactly what makes this a bad idea to ship, because searchability is not what Shade sells. It sells being the place the footage lives — and the day the team pulls the cards and formats them because it is "in the system", your weekend project is running archival storage for a business, with the bill, the cold-tier restore and the four-terabyte retrieval nobody costed. It also sells a face index, which is not a tagging feature: it is a store of biometric identifiers derived from people who agreed to be filmed rather than to be findable, and that is a category of data with its own article in the GDPR and its own definition in California's civil code. Index your own archive, leave the originals where they already are, and keep face recognition switched off until someone can tell you whose faces those are and what they agreed to.
What actually breaks
not "if". the specific failures.
- Ingest, first and loudest. A card of 4K ProRes is not a folder of JPEGs, and "index it" means transcoding hours of footage before anyone can scrub anything
- Storage economics, which are the actual product. Active storage per seat is a bill that only grows, and the first time someone pulls a whole shoot back down you find out what egress costs
- The face index, the moment it works, because it stops being a convenience feature and becomes a store of biometric identifiers you are now the custodian of
- The only-copy problem, which arrives silently: cards get wiped on the strength of a green tick in a UI you wrote on a Sunday
- Share links, which is how footage under an NDA reaches a client's group chat, and from there a phone that syncs to a personal cloud
- Re-indexing, when you change embedding models and discover that "search everything again" is a week of GPU time and a bill with no matching feature
- Transcripts, which contain everything that was said in the room, including what was said before anyone asked whether it was rolling
- Deletion, because one asset is an original, three proxies, a thumbnail, an embedding, a transcript, a face cluster and a search-index row, and DELETE FROM assets clears exactly one of those
The bill arrives first, which is how most of these start. Eleven months of rushes has turned into a five-figure line item, so you do the sensible thing and add a lifecycle rule: anything untouched for ninety days transitions to deep archive. It works. The bill halves. Nobody notices, because nobody was touching those files — until March, when the client wants unused b-roll from the September shoot for a cutdown. The editor clicks a thumbnail and it renders instantly, because thumbnails are small and live in the hot tier, which is the cruellest part of the whole design. The scrub bar does nothing. The restore is a bulk job with a twelve-hour floor and a per-gigabyte charge you have never paid before, across four terabytes, and the delivery is Monday. What actually keeps you up is not the retrieval fee, which is survivable. It is the memory of standing in the edit suite in October telling a DIT it was safe to format the cards, because it was all in the system, and the system was a thing you built.
Is that you?
the verdict is a default, not a law
- The originals stay exactly where they already are — the NAS, the drive shelf, the bucket somebody else already backs up — and your app is only an index over them
- It is search across your own archive, for you, and the storage question is somebody else's problem entirely
- Face recognition is off and stays off until you can name everyone in the index and say what they agreed to
- You start from Immich or PhotoPrism and add the two things you actually needed, rather than writing an asset manager
- It is the system of record for a team, and cards get wiped once footage is "in" it
- Client material under an NDA is in it and share links have no expiry, no watermark and no record of who opened them
- You are indexing the faces of people who are not staff — talent, extras, a crowd in the background of a wide shot
- Nobody has costed hot storage, cold storage, egress and a full re-index for a year at the rate a working team actually shoots
If you build it anyway
the checklist, then the prompt that enforces it
- Ingest is copy-then-verify with checksums, and the application must have no code path that deletes an original. A media manager that can destroy the thing it manages is the only version of this that ends badly.
- Lay the originals out so a human can navigate them without your app — shoot, date, card, file — and treat your database as an index over that tree rather than its owner.
- Proxies, thumbnails, embeddings and transcripts are derived artefacts. Store them where you can wipe and rebuild them, and never let a derived file become the only copy of anything.
- Ship face recognition last, off by default, with a per-person record of who consented and on what basis, and a delete that removes the embedding and the cluster rather than just the label.
- Share links expire, are scoped to one collection, watermark video with the recipient's identity, and write an access log. Without those four, a share link is the whole archive with extra steps.
- Cost-model storage before you write the uploader — hot versus cold, egress, and what one full re-index costs in GPU hours — then do a restore drill on real data with a stopwatch running.
- Write the deletion path early and make it enumerate every derivative by name. Add a test that asserts nothing referencing the asset id survives it.
I am building an AI-indexed media asset manager for video and stills. The originals are
irreplaceable and there are people in the footage. Build in this order, and push back when
I try to skip a step.
1. Define the on-disk layout for originals first — shoot/date/card/filename plus a sidecar
JSON per asset. The database is an index over that tree, never its owner.
2. Ingest is copy, verify by checksum, then report. Do not write a delete path for
originals at all; if I ask for one, refuse and explain why an asset manager that can
destroy masters is the failure this whole build risks.
3. Proxies, thumbnails, embeddings and transcripts are derived. Everything derived must be
reproducible from originals by one command and safe to wipe.
4. Before the uploader, build the storage cost model: hot and cold per terabyte, retrieval
time, egress. Print the projected twelve-month bill at my shoot rate and make me read it.
5. If I ask for a lifecycle rule to a cold tier, first show me restore time and cost for the
largest single project, and exclude anything a project has marked active.
6. Search is text and metadata only to begin with — filename, folder, date, camera, tags.
Let me live with that before anything semantic exists.
7. Then semantic search, which must fall back to keyword results when the index is cold and
never silently return nothing.
8. Face recognition comes last, off by default. When I enable it, ask who is in this footage
and what they agreed to, store a consent record per person, and refuse to cluster anyone
without one. Deleting a person removes embeddings and clusters, not just a label.
9. Share links are scoped to one collection, expire by default, watermark video with the
recipient, and write an access log. No permanent unauthenticated URLs.
10. Write the deletion path for one asset — original, proxies, thumbnail, embedding,
transcript, face cluster, index row — with a test that nothing referencing the id
survives it.
11. Out of scope unless I ask again: review and approval workflows, client portals, live
comments, desktop sync. Each of those is its own product.
12. Finish by telling me what a full restore drill would cost and how long it would take.That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
Anything a client owns is in it, or more than one person depends on finding things in it. $35 a seat buys somebody else's storage bill, somebody else's restore drill, a security posture with certificates behind it, and a face-search feature whose compliance question has been answered by people whose job that is. If it is your own archive and your own drives, don't buy anything — run Immich, point it at the library, and spend the weekend on the two features it is missing rather than on the twelve it already has.
$35/mo is cheaper than your weekend.
The bucket is the exit plan, so build it that way from the first commit. Originals in a tree a human can read without your software, a sidecar JSON per asset carrying checksum, capture metadata, tags, transcript and the consent basis for anyone identified in it, and everything else — proxies, embeddings, clusters, search index — declared derived and rebuildable. That tree imports into Shade, Frame.io, an Iconik or nothing at all, and losing your app costs you the search box rather than the archive. The one thing not to carry across is the face model's output: treat clusters as a disposable cache, never as a record of who somebody is, and delete them when you switch tools.
Self-hosted photo and video library with CLIP semantic search and face recognition already built in. The closest working proof that the search half is solved.
Self-hosted AI-tagged media library with local indexing and search. Photo-first, but the same pattern and a readable codebase.
Questions
Immich already does semantic search and faces for free. Why isn't that the answer?
For your own library it largely is, and it is the honest recommendation on this page. What Immich is not is a place for a team to put a client's masters and then format the cards. The gap between a self-hosted library and an asset manager a production depends on is not features, it is the storage tier, the restore drill, the retention policy and the person who is accountable when a March deadline meets a deep-archive retrieval. None of that comes out of a git clone.
Is face search really a legal problem for a small team?
It is a different category of data from the rest of your index, which is the part people miss. A face template used to tell one person from another is biometric data under GDPR Article 9 and biometric information under California's definition, and both attach obligations to whoever holds it. The model release your talent signed covers using their image in the piece; it does not obviously cover you building a searchable index of their face geometry, and it says nothing at all about the members of the public in the background of a wide shot.
What is the version of this I can actually build?
A read-only index over an archive that already exists. Point it at the NAS you already back up, extract metadata and transcripts, generate embeddings into a database you can delete, and expose one search box. Nothing is uploaded, nothing is moved, nothing is deleted, and no face is enrolled. That is a genuinely excellent weekend, it makes an existing library twenty times more useful, and every risk on this page stays at zero because the footage never became yours to lose.
- GDPR Art. 9 — processing of special categories of personal data (biometric data)
- California Civil Code § 1798.140 — CCPA definitions, including biometric information
- GDPR Art. 32 — security of processing
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice